О выводе меток, начало на старой площадке (форуме)

Вот, например, как можно сделать навигацию.

www.zeit.raum-bayern.net/index.php/mein-...er-alle-aktivitaeten

Достаточно удобно

Вообще идеально приблизиться по функциональности к карте на probok.net. И то считаю что там сейчас разарботчики перемудрили, слишком часто перезагружается вся страница целиком для просмотра меток.
Что полезного есть:
1. Просмотр и редактирование меток в одном месте, даже если для редактирования необходимо нажать отдельную кнопку, которая есть только у обладателя соответсвующих прав, как то админ или автор. Кстати есть возможность выводить имя автора.
2. Описание не обязательно в балуне.
3. Комментирование каждой метки
4. Доступ к описанию каждой метки по спец URL (к сожалению сдесь сделано так, что при переходе к другой метке надо обязательно перегружать страницу, что считаю недостатком, т.к. приходится на нетбуке долго ждать пока карта переинициализируется).
5. Автоматическия группировка меток, как уже реализовано в плагине гугла, при изменении маштаба. Странно правда они как-то группируются.
6. Есть возможность на админской стороне объединять (не удалять похожие, а именно объединять) в одну метку, но выводить их на отдельных закладках.
7. Альтернативные описания меток на закладках.
Вообще суть сайта probok.net - это система help-desk, т.е. каждая метка - это обращене пользователя, а сотрудники центра Пробок.НЕТ устраняют данные обращениея. Механизм с разными стадиями. Но это уже другая система, т.е. отвлекся немного

Реально плохие моменты:
1. Когда пользователь зарегистрирован и видит только свои метки, а чтобы увидеть все необходимо или переходить на другую страницу или выйти из системы. При добавлении новой метки хорошо видеть какие метки уже установлены, чтобы их не дублировать.
2. Необходимость перезагружать страницу целиком для совершения некоторых действий. Когда страница легкая, то это ничего, а карта долго грузится и ресурсоемко инициализируется. В современном динамическом HTML достаточно легко на ajax`е перезагружаются лишь необходимые части, тем более что в API карт уже реализованы необходимы вызовы событий.

Полезно также иметь:
1. Отдельный виджет для просмотра меток в текстовом виде с ссылками на карту.
2. Иметь различные уровни доступа: Например обычный пользователь может добавлять только метки в группу 1, модератор в группу 1 и 2, супер пользователь куда угодно. А видить, ну пусть видят все и все (например). По сути необходимо просто создать функцию, которая будет генерить список меток в зависимости от прав пользователя с соответсвующими параметрами (например может еще и редактировать), а все виджеты просто из нее забирают инфу для отображения.
3. API управления картой и метками, что и должно лежать в основе компонента. Тогда легко будет настраиваться внешний вид (дизайн).

Похоже меня уже занесло
Могу предложить посильную помощь, все-равно в одном танке, главное верно скоординироваться. Может еще желающие найдуться? Одному делать тяжело, а делать все-равно надо.

Доброе утро.

Вы хотите слишком многого.

На самом деле, с такими запросами Вам надо писать систему с нуля, и затачивать все механизмы как хотите.

Поймите меня правильно. Я решаю задачу в общем случае. Это помогает реализовывать приблизительно 90-95% всего, что хочется.

Работа с ACL, Ajax и прочее я планирую добавить, но не ранее лета, так как я и так почти каждый день вношу различные изменения в расширения, и нет времени даже дочитать книжку не то что по Ajax, а про JavaScript.

Мои расширения - это изучение технологий, получения практических навыков как по картам (Яндекс и Гугл), так и по JavaScript и CSS, которые я хочу все-таки изучить.

п2 - а где оно должно быть. Не хотите его - не выводите, это компонент может.

п3 - как Вы себе это представляете, это должна быть интеграция с чем-то. Если K2 это позволяет, то плагин работает там в их статьях.

п4 - это можно сделать вызвав плагин по ид-метки

п5:
Хотите кластеризацию - да пожалуйста, возьмите мой гугловский компонент (Zh GoogleMap) и там это и еще масса всего есть.
В Яндекс.Картах нет ни встроенного кластеризатора, ни расширенных библиотек (например, у гугла помимо своего клстеризатора, есть еще написанный, как и InfoBubble и т.п.), добавляется и рисование, и еще всякие вкусности.
Да, клуб яндекс карт отсылает к переделанной из гугла библиотеки кластеризатора. НО! Даже у гугла периодически патчатся проблемы с ним. А как здесь быть, писать тому, кто сделал эту переделку

п6 - какие закладки?
п7 - см. п6, и что такое альтернативное описание.


Реально плохие моменты

п2 - где перегрузка. Сейчас это только при создании метки. Остальное работает без перегрузки. Ajax - см выше.

Полезно также иметь

п1 - это есть в планах - вызов плагина
п2 - ACL - см. выше
п3 - не понял какое АПИ Вы хотите, API к компоненту . Используйте стили (CSS), у меня все мои объекты имеют идентификаторы и классы.

Что касается разработки. Я разрабатываю один, я знаю что, где и когда делаю. Мне легко найти и исправить то, где могут быть проблемы. Поскольку я - профессиональный разработчик промышленных баз данных, и интерфейсов к ним, и имея достаточно большой опыт совместной работы, мое слово - НЕТ

На счет

Могу предложить посильную помощь, все-равно в одном танке, главное верно скоординироваться. Может еще желающие найдуться? Одному делать тяжело, а делать все-равно надо.

Не согласен. Мои расширения - это не коммерческий проект.
Координироваться ради разработки под Вашу задачу - не, мне это не интересно, т.к. времени отнимет много, а у меня есть работа, дом, семья...
Если и делать - так это надо коммерческий проект, продуманный, и который будет потенциально востребован с нормальной отдачей.

Пункты 1.х Взяты из уже реализованного проекта probok.net в качестве примера.
1.2 Вывод вне балуна. В отдельном div`е на странице.
1.3 Комментарии. Тоже что и 1.2 в отдельном div`е на странице. Вешается на событие BalloonOpen. Подгружается контент с помощью httpRequest темже Ajax или в нашем случае его аналогом MooTools. Хранятся в отдельной таблице. Выгружаются отдельным виджетом по ссылке site.ru/component/imyacomponenta/?view=i...djeta&tmpl=component
1.5 Группировка. Но ведь возможно.
1.6-1.7 Это просто красивость, которая уже есть на реализованном чужом проекте.
2.1 Сейчас в текущей реализации Zh YandexMap, авотризованный пользователь должен редактировать метки на одной странице, а смотреть на другой. Разве это не перезагрузка всей страници в целом? По 1.4 (метка по прямой ссылке) Загрузиться только конкретная метка, а чтобы посмотреть всё необходимо опять идти на другую страницу.
3.3. Под API я подразумеваю как расширение движка CMS. Например при создании нового Template, я могу переопределить файлы шаблона поместив их в папку my_template/html/imyacomponenta/imyavidjeta/ как default.php (По умолчанию) или как альтернативное отображение. А вот в этом файле я могу использовать некое API компонента, как например получение списка меток (автоматически учитывающее права доступа) Списка групп/категорий. Генерация блоков для вывода коментариев или альтернативных описаний. Придумать можно много всего.

Кстати, в описании Кто писал, что принимаются пожелания? Вот излагаю идеи.

Мои расширения - это не коммерческий проект.

А я и не претендую на комерческие проекты. Между прочем приведенный мной пример probok.net - это НЕ коммерческий продукт, хотя да, над созданием портала трудились на коммерческой основе, просто организация общественная.
Мне реально нужно только работающие уровни доступа и комментарии, причем комментарии делаются на коленке за несколько часов. Только чтобы это сделать грамотно нужно повозиться.
Отдавать готовый компонент пользователю, сделанный на коленке не хочется, а хочется его оформить грамотно, на что уже времени не хватает, у меня также работа, дом, семья.

имея достаточно большой опыт совместной работы, мое слово - НЕТ

Разумно при плохой координации. Работал совместно, когда несколько человек отвечали каждый за разработку своего класса или независимой функции или утилиты - вполне успешно.
Пример НЕкоммерческой CMS разработанной группой разработчиков в германии Typo3, проект развивается уже более 10 лет.
А бесплатных компонент сделанных действительно хорошо очень мало. Ваша одна из лучших, так лучше ее развивать, причем одну единственную, вместо того чтобы плодить ответвления.
Как я писал, те же комментарии я все-равно буду делать и грех не отдать результат на общее благо. Только или, за нехваткой времени, зажму результат или пойдет отдельной веткой.

1.5 Группировка. Но ведь возможно.

Это надо продумывать и аккуратно реализовывать. Тем более, что такое рядом? Оно - понятие очень хитрое.

1.6-1.7 Это просто красивость, которая уже есть на реализованном чужом проекте.

InfoBubble от Google. Смотрите возможности моего компонента там.

п.3.3 - Это проще и разумнее реализовывать плагином с определенным набором параметров, под каждую задачу.

PS - я принимаю пожелания, естественно.

Мне реально нужно только работающие уровни доступа и комментарии, причем комментарии делаются на коленке за несколько часов.

C ACL мне надо сначала разобраться, посмотреть как лежит, как работает, как используется и вызывается.
На коленке - такой и результат будет.

Только чтобы это сделать грамотно нужно повозиться.

Естественно, и для этого нужно время, чтобы делать. Плюс работать, чтобы кормить семью, и уделять семье время тоже.

Разумно при плохой координации. Работал совместно, когда несколько человек отвечали каждый за разработку своего класса или независимой функции или утилиты - вполне успешно.

Я являюсь и руководителем проектов тоже, и имею достаточный опыт как командной разработки, так и управлением. Хочу Вас заверить, даже если Вы определите стандарты разработки, опишите как НАДО, и как НЕ НАДО, все равно наступите на грабли. Поверьте, иногда приходится переписать заново, чем вылечить. Или дать другое задание или ВООБЩЕ не давать, только чтобы не лез куда не надо.
Тут все упирается в адекватность самого разработчика, его ответственность, компетентность и т.п. Хотите обсудить - создайте ветку, я Вам с десяток примеров могу привести, если не больше. Только в этом нет смысла.
Однако все мои утилиты, написанные как основа для разработки наших проектов работают как часы.
И в моей конторе были "разработчики", которые тоже - да что тут, ща, за 5 минут сделаю. Да делается. Но это работает с горем пополам, не переносимо, не универсально и т.п.

Как я писал, те же комментарии я все-равно буду делать и грех не отдать результат на общее благо. Только или, за нехваткой времени, зажму результат или пойдет отдельной веткой.

Все упирается во время, и желания. У вас - они одни. У меня - планы свои.
Хотите зажимайте, хотите предлагайте. Мне честно все равно. У меня есть план развития своих расширений, я его придерживаюсь. Хотите делать отдельные ветки, да без проблем, только что ж Вы не написали свое расширение как появилась 1.6 и следующие релизы, раз Вам прикрутить комменты - раз плюнуть, и значит веб-разработка - ваш конек.

иногда приходится переписать заново, чем вылечить

Переписывал чужие проекты неоднократно, знаем, проходили. Редко, свои проекты. Когда нет времени, приходится использовать, то что есть или когда проект уже огромный, и находится в эксплуатации, приходится опять работать с тем что есть, меняя лишь некоторые части, уделяя много времени совместимости.

Но это работает с горем пополам, не переносимо, не универсально и т.п.

Потому и предлагаю помощь, чтобы было как надо. "Лучше день потерять, зато потом за 5 минут долететь".
Без моего участия, но с моим проектом: 1 проект отправили на конкурс - занял первое место по навигаци по сайту (в Перьми. Тоже старался сделать хорошо, на века.). По 2 проектам сделали патенты (распознавание образов).

да что тут, ща, за 5 минут сделаю

Я про 5 минут не говорю. Собственно оценил уровень работ аналогично.
У меня есть на свой проект где-то неделя. Сделаю все за это время чуть лучше чем "на коленке", но по прежнему останется скорее всего не переносимо и не универсально, т.е. только под меня. И потом, как-нибудь, может быть, доработаю до ума. ИЛИ делаю часть в рамках чужого проекта, но переносимо и универсально. За это время кто-то сделает другую часть, которая по стечению обстоятельств также нужна мне, а в результате за то же время получается готовый продукт, который можно отдавать на растерзание всем.
С работой ACL, например, я уже частично покапался, но согласен, что придется переделывать большую часть компонента, вернее даже не совсем переделывать, а просто местами заменять куски кода на вызовы готовых нескольких функций (по сути заменить почти все обращения к базе в /components/com_zhyandexmap/views/zhyandexmap/tmpl/default.php. Собственно мое предложение в этом файле оставить практически только шаблон, как и должно быть согласно концепции joomla, а основные подключения к БД и т.п. загнать в то самое "мифическое" API.

Ну в общем мое дело предложить - Ваше отказаться. Считаю разговор исчерпаным. Но пожелания, если придумаю, все-равно выложу