-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Как делают это опытные люди ? Форматирование текста, теги и т.д
- Автор темы Сенсей
- Дата начала
IBSN
Новичок
neko
ага сразу на Java пиши...
Скорость приличная для админа если учесть что админы являются клиентами, которые как правило тормозят покруче JS...
А на счет поведения, это как и любая другая программа сравнимо с годовалым ребенком, ребенка надо научить, чтобы он вел себя как надо...
ага сразу на Java пиши...
Скорость приличная для админа если учесть что админы являются клиентами, которые как правило тормозят покруче JS...
А на счет поведения, это как и любая другая программа сравнимо с годовалым ребенком, ребенка надо научить, чтобы он вел себя как надо...
neko
tеam neko
эта фраза что, должна характеризовать бессмысленность моего скромного желания?
жизнь несложилась?
очень рад за тебя и твои годовалые программы
для непонятливых поясню:
есть такая вещь -- зависимости
как бы там скурпулезно производители браузеров не реализовывали DOM, html, JS и вообще что угодно, зависимости от этого не пропадают.
в com зависимости понятно какие?
если незнаешь спроси, не стесняйся.
neko
tеam neko
com то независим
только вот в применительно к вопросу о WYSIWYG придется делать ole/activex который уже независимым быть неможет
-~{}~ 06.06.04 20:04:
то что сейчас есть в COM начинало изобретать именно когда делали OLE 1.0
-~{}~ 06.06.04 20:13:
гм, да я неправильно выразился
зависимости com, несколько иные, нежеле ole/activex
то, что я там выше написал про ie3 это применимо к ole1, а не com'у вообще
только вот в применительно к вопросу о WYSIWYG придется делать ole/activex который уже независимым быть неможет
-~{}~ 06.06.04 20:04:
а я говорил что является?
то что сейчас есть в COM начинало изобретать именно когда делали OLE 1.0
-~{}~ 06.06.04 20:13:
гм, да я неправильно выразился
зависимости com, несколько иные, нежеле ole/activex
то, что я там выше написал про ie3 это применимо к ole1, а не com'у вообще
lucas
Guest
Надеюсь, месье не станет спорить, что в последних IE, Mozilla и Opera спецификация DOM реализована в (почти) полной мере.
Например, у меня Spaw (как и описано в документации) работал только под IE, тогда как HTMLArea (за что я его и люблю) и в Mozilla.
Хотя, с другой стороны, большинство "секретарш" сидят под Виндой с IE (5-6), так что проблемы переносимости в этой части несколько надуманны.
Кстати, "тормоза" таких редакторов тоже не всегда сильно отличаются от понятия "миф". На моем откровенно слабом комьютере (PIII 600 MGhz, S3 Savage4 16Mb, DIMM 128 Mb) при работе с HTMLArea никаких "тормозов не было замечено в принципе (еще один повод для любви
).neko
tеam neko
спорить не буду
только дело не в мере, а в существовании зависимости от чужого софта
если иметь в виду общие тенденции в мире этого самого софта (браузеров), то становится совсем грустно
при нормальной функциональности, тормозов там небыть неможет в принципе.
spaw вот этот у меня весьма ощутимо подтормаживает
-~{}~ 06.06.04 20:25:
то о чем я говорю, полагается только на одну функцию браузера: умение вставлять в документы ole/activex
но тут слава богу все стандартизированно донельзя
-~{}~ 06.06.04 20:26:
ладно, это оффтопик полный.
только дело не в мере, а в существовании зависимости от чужого софта
если иметь в виду общие тенденции в мире этого самого софта (браузеров), то становится совсем грустно
при нормальной функциональности, тормозов там небыть неможет в принципе.
spaw вот этот у меня весьма ощутимо подтормаживает
-~{}~ 06.06.04 20:25:
то о чем я говорю, полагается только на одну функцию браузера: умение вставлять в документы ole/activex
но тут слава богу все стандартизированно донельзя
-~{}~ 06.06.04 20:26:
ладно, это оффтопик полный.
Three Daws
Guest
neko IMHO, внедрение COM и других объектов не самый удачный вариант.
Если Вы потребитель продукта, то должны боятся внедряемых объектов еще более чем javascript. Их уровень общения с системой потенциально более опасен.
Второй момент - ориентируясь на COM Объекты мы сужаем круг браузеров и платформ потребителя нашей системы.
Ок, на уровне "администрирования" это еще можно объяснить и пропихнуть, хотя... Мне было довольно неудобно отлаживать подобную среду управления сайтом сидя под ASP-Linux'ом с полным отсутствием IE (кто сказал, что рабочее место разработчика всегда Windows? ;-)
Но, кроме применения в управлении сайтом, WYSWYG интерфейсы используются на форумах, блогах и т.п. способах организации интерактивного взаимодействия с посетителем сайта. Внешняя, доступная посетителю сайта часть не должна (на этот раз - IMCO) позволять себе роскошь потери удобства и привлекательности не только для 50, но и для 10% посетителей.
Если Вы потребитель продукта, то должны боятся внедряемых объектов еще более чем javascript. Их уровень общения с системой потенциально более опасен.
Второй момент - ориентируясь на COM Объекты мы сужаем круг браузеров и платформ потребителя нашей системы.
Ок, на уровне "администрирования" это еще можно объяснить и пропихнуть, хотя... Мне было довольно неудобно отлаживать подобную среду управления сайтом сидя под ASP-Linux'ом с полным отсутствием IE (кто сказал, что рабочее место разработчика всегда Windows? ;-)
Но, кроме применения в управлении сайтом, WYSWYG интерфейсы используются на форумах, блогах и т.п. способах организации интерактивного взаимодействия с посетителем сайта. Внешняя, доступная посетителю сайта часть не должна (на этот раз - IMCO) позволять себе роскошь потери удобства и привлекательности не только для 50, но и для 10% посетителей.
neko
tеam neko
это все верно
я такую вещь хочу, как инструмент продаваемый вместе с этим новомодным словом CMS
речь идет о том, что одним из постоянно заказываемых пунктов являются так называемые "административные части". ничто не мешает к ней приложить диск с этим компонентом.
ну, а то что win это стандарт для офиса, наверное уже всем ясно
заметь о посетитле сайта речи нет.
нормальный посетитель не будет пользоваться сайтом, который отказывает работать, зато предлает что-то немедленно скачать и установить
я такую вещь хочу, как инструмент продаваемый вместе с этим новомодным словом CMS
речь идет о том, что одним из постоянно заказываемых пунктов являются так называемые "административные части". ничто не мешает к ней приложить диск с этим компонентом.
ну, а то что win это стандарт для офиса, наверное уже всем ясно
заметь о посетитле сайта речи нет.
нормальный посетитель не будет пользоваться сайтом, который отказывает работать, зато предлает что-то немедленно скачать и установить
Three Daws
Guest
Offtopic
========
neko ну сейчас более новомодными стали слова "SRM" (Управление внешними отношениями поставщика услуг) и "ERP" (Управление ресурсами предприятия), куда там бедной Системе управления содержанием
Но меня все равно смущает сочетание PHP с внедренными Windows-ориентированными объектами. Если Вы разрабатываете сайт и его бэrгруанд на PHP, как-то инородно тут смотряться внедряемые Windows-Объекты. Такое чаще встретишь у ASP и .NET разработчиков (как и открытие дочерних окон на javascript в виде window.showModalDialog(...).
Если в команде есть сообветствующий специалист (согласитесь, что нанимать его отдельно - глупо) это еще допустимо, хотя... Если так тянет в эту сторону, осторожнее! Так можно захотеть и сменить платформу разработки ;-)
========
neko ну сейчас более новомодными стали слова "SRM" (Управление внешними отношениями поставщика услуг) и "ERP" (Управление ресурсами предприятия), куда там бедной Системе управления содержанием
Но меня все равно смущает сочетание PHP с внедренными Windows-ориентированными объектами. Если Вы разрабатываете сайт и его бэrгруанд на PHP, как-то инородно тут смотряться внедряемые Windows-Объекты. Такое чаще встретишь у ASP и .NET разработчиков (как и открытие дочерних окон на javascript в виде window.showModalDialog(...)
.Если в команде есть сообветствующий специалист (согласитесь, что нанимать его отдельно - глупо) это еще допустимо, хотя... Если так тянет в эту сторону, осторожнее! Так можно захотеть и сменить платформу разработки ;-)
neko
tеam neko
если говорить про лично мое мнение, то аббревиатура CMS мне не нравится.
какой-то уж очень у нее статейно/новостной оттенок.
если упросить:
то что мы разрабатываем чаще всего это какие-то системы для работы с данными (например о товарах), которых (данных) может быть очень много.
часть этих данных например экспортируется на сайт где можно посмотреть каталог товаров
часть в какую-нибудь финансовую программу.
это CMS? я бы так не сказал.
возвращаясь к ole/activex и этому "редактору html"
сделав один раз (и поддерживая постоянно) такой объект, его можно использовать где угодно и php как ты понимаешь тут не при чем. это вообще собственно говоря с серверной частью никак не связанно.
специалистов у нас к сожалению мало :-(
какой-то уж очень у нее статейно/новостной оттенок.
если упросить:
то что мы разрабатываем чаще всего это какие-то системы для работы с данными (например о товарах), которых (данных) может быть очень много.
часть этих данных например экспортируется на сайт где можно посмотреть каталог товаров
часть в какую-нибудь финансовую программу.
это CMS? я бы так не сказал.
возвращаясь к ole/activex и этому "редактору html"
сделав один раз (и поддерживая постоянно) такой объект, его можно использовать где угодно и php как ты понимаешь тут не при чем.
это вообще собственно говоря с серверной частью никак не связанно.специалистов у нас к сожалению мало :-(
Three Daws
Guest
Offtopic
========
neko, тут все зависит от подхода к этому самому "редактору HTML". Если целью ставить набор стандартных инструментов форматирования - то да, можно и один раз, пожалуй...
несколько подводных камней на уровне "а что делать, если в новом проекте потребуется несколько разных стилей оформления списков, цитат, таблиц и т.п., которые надо предоставить редактору" могу придумать сразу, но ... Хочется сказать даже не об этом.
Если говорить именно об административной части, то конечным потребителем становится ведущий рубрики, раздела сайта.
В идеале, было бы неплохо наделить его возможностью включать в текст страниц некоторые специально созданные вставки. Пусть даже не на том уровне свободы, который предоставляет интерфейс того же http://my.yandex.ru, а на уровне:
- вставить специально оформленный блок-примечание;
- добавить в текст страницы анонс тематического мероприятия;
Вы мне можете сходу возразить типичным "мы сделаем это на уровне разных типов страниц и предопределенных шаблонов". Но у меня тоже есть возражение: специально оформленная вставка-врезка иногда нужнее в строго определенном месте статьи, а не там, где ее предусмотрел заранее шаблон.
Думал привести как пример обрамление характеристик товара описательным текстом (понятно, что можно сделать специальный тип страницы, и вставлять, к примеру, таблицу характеристик после первого абзаца текстового описания), но пример со вставкой примечаний-врезок в статью мне нравится больше.
Я не стал бы зарекаться, что смогу предусмотреть все возможные элементы, которые я захочу дать в руки конечного пользователя и сделать объект-редактор на все случаи жизни. Значит - придется его модифицировать от проекта к проекту ;-)
Ну или сделать классный внедряемый объект, который раз и навсегда втиснет нашего потребителя в ограниченный набор возможностей. Фи! ;-)
========
блин! Жуткий офф-топик. Прошу прощения.Автор оригинала: neko
...возвращаясь к ole/activex и этому "редактору html"
сделав один раз (и поддерживая постоянно) такой объект, его можно использовать где угодно и php как ты понимаешь тут не при чем.
neko, тут все зависит от подхода к этому самому "редактору HTML". Если целью ставить набор стандартных инструментов форматирования - то да, можно и один раз, пожалуй...
несколько подводных камней на уровне "а что делать, если в новом проекте потребуется несколько разных стилей оформления списков, цитат, таблиц и т.п., которые надо предоставить редактору" могу придумать сразу, но ... Хочется сказать даже не об этом.
Если говорить именно об административной части, то конечным потребителем становится ведущий рубрики, раздела сайта.
В идеале, было бы неплохо наделить его возможностью включать в текст страниц некоторые специально созданные вставки. Пусть даже не на том уровне свободы, который предоставляет интерфейс того же http://my.yandex.ru, а на уровне:
- вставить специально оформленный блок-примечание;
- добавить в текст страницы анонс тематического мероприятия;
Вы мне можете сходу возразить типичным "мы сделаем это на уровне разных типов страниц и предопределенных шаблонов". Но у меня тоже есть возражение: специально оформленная вставка-врезка иногда нужнее в строго определенном месте статьи, а не там, где ее предусмотрел заранее шаблон.
Думал привести как пример обрамление характеристик товара описательным текстом (понятно, что можно сделать специальный тип страницы, и вставлять, к примеру, таблицу характеристик после первого абзаца текстового описания), но пример со вставкой примечаний-врезок в статью мне нравится больше.
Я не стал бы зарекаться, что смогу предусмотреть все возможные элементы, которые я захочу дать в руки конечного пользователя и сделать объект-редактор на все случаи жизни. Значит - придется его модифицировать от проекта к проекту ;-)
Ну или сделать классный внедряемый объект, который раз и навсегда втиснет нашего потребителя в ограниченный набор возможностей. Фи! ;-)
neko
tеam neko
Three Daws
нет, так я не потребителя втисну, а прежде всего себя самого
идеальная реализация тут такая, по моему мнению:
объекту передается:
- данные (например xml)
- описание интерфейса по которое говорит о том какие xml тэги можно вставить (и как выглядят те "кнопки" которые за их вставку отвечают)
- описание представления этих тэгов в самом редакторе (xslt?)
в результате:
- получаем опять xml
с которым можно что угодно дальше делать.
тут важно понять одну вещь.
wysiwyg для сложного контента вещь невозможная. возможно лишь некое дружелюбное для пользователя представление.
простой пример:
часть сайта реализована на flash. меню какое-нибудь там или неважно что. представить такое меню "как оно будет" в процессе правки невозможно.
нет, так я не потребителя втисну, а прежде всего себя самого
идеальная реализация тут такая, по моему мнению:
объекту передается:
- данные (например xml)
- описание интерфейса по которое говорит о том какие xml тэги можно вставить (и как выглядят те "кнопки" которые за их вставку отвечают)
- описание представления этих тэгов в самом редакторе (xslt?)
в результате:
- получаем опять xml
с которым можно что угодно дальше делать.
тут важно понять одну вещь.
wysiwyg для сложного контента вещь невозможная. возможно лишь некое дружелюбное для пользователя представление.
простой пример:
часть сайта реализована на flash. меню какое-нибудь там или неважно что. представить такое меню "как оно будет" в процессе правки невозможно.
_RVK_
Новичок
Можно тоже чуток пофлеймить?
Так вот. Если речь идет только о БакЕнде то у меня давно уже есть идея (и как обычно нет времени) написать все на Delphi. Вот тут уже никаких зависимостей от браузера, полная свобода в выборе средств, отсутствие тормозов. Можно потом на Kilix перевести... И тут сразу возникает вопрос. Зачем тогда АктивИкс? Только ради того что бы превычно было, те как и раньше в окне браузера?
Так вот. Если речь идет только о БакЕнде то у меня давно уже есть идея (и как обычно нет времени) написать все на Delphi. Вот тут уже никаких зависимостей от браузера, полная свобода в выборе средств, отсутствие тормозов. Можно потом на Kilix перевести... И тут сразу возникает вопрос. Зачем тогда АктивИкс? Только ради того что бы превычно было, те как и раньше в окне браузера?