Web, Notes View и другие животные

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#1
Всем привет! ;)
хочу расширить свой кругозор по разработке видов для domino-приложений...
нагло прошу ссылки на примеры по которым можно научится красиво делать виды с использованием html, xml, js, css...
а не использовать стандартный механизм генерации html'а для видов...

Заранее спасибо! :(
 
O

oshmianski

#2
Akupaka
тут целый фрэймворк. правда тормозючий... страх. думаю, имеет смысл использовать только в интранет.
мои изыскания по этому поводу (только посмотреть).
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#4
вопрос в догонку, кто-то сравнивал разницу в производительности при формировании вида стандартным механизмом и агентом, который перебирает вид и "рисует" свой код страницы? большая разница?
 
K

K-Fire

#5
вопрос в догонку, кто-то сравнивал разницу в производительности при формировании вида стандартным механизмом и агентом, который перебирает вид и "рисует" свой код страницы? большая разница?
Я проводил тесты. Во вью было ~800 документов, отображался весь вью целиком, с категоризацией на ява-скрипте.
WQO агент рисовал хтмл, собирая его в строковую переменную, которая потом засовывалась в поле.

Время обработки агентом было 5 секунд. После того как все операции конкатенации строк заменил за использование StringBuffer, время упало в 10 раз, т.е. до 0.5 секунд. Естественно общее время (т.е. получения данных браузером, пост-обработка яваскриптом) было побольше, ну может 1 секунда максимум. А, да, эти тесты проводились локально, в интранете. Но и 800 документов это был экстрим для той задачи.

Все это можно было еще более оптимизировать, выводя JSON-данные, но уже не было никакой разницы, работало шустро и так.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#6
мои изыскания по этому поводу
шикарненько, а инфа внутри еще больше заинтересовала ))

что я хотел бы сделать у себя иначе, так это одноразовую подгрузку данных в категории, похоже (по поведению браузера), что у тебя она постоянно подгружается, при развертывании. или это имеет какое-то основание?..

можно было еще более оптимизировать, выводя JSON-данные
а как с помощью JSON оптимизировать подобную задачу? на сколько я понимаю, эта нотация позволяет создавать объекты, задавая им значения свойств, с пом строковой конструкции. как использовать это преимущество для оптимизации?
 
K

K-Fire

#7
а как с помощью JSON оптимизировать подобную задачу? на сколько я понимаю, эта нотация позволяет создавать объекты, задавая им значения свойств, с пом строковой конструкции. как использовать это преимущество для оптимизации?
JSON помимо всех других его плюсов, довольно таки компактный формат данных. Т.е. по сравнению с html-таблицей, или не дай бог XML, одни и те же данные могут занимать в 2-3 раза меньше места.

Плюс без "трансляции" напрямую понимается яваскриптом как объект/массив объектов.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#8
спасибо, я предполагал, что дело именно в размере
 
O

oshmianski

#9
Akupaka
да, значения категории подгружаются каждый раз при развертывании.
обоснование - загрузка свежих данных всегда.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#10
обоснование - загрузка свежих данных всегда
мне кажется, что для этого было бы лучше сделать какую-то отдельную возможность, ведь не все приложения генерят данные быстро и много... ну то такое ;)
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 599
277
#11
в приведеных, выше, примерах юзаются две библиотеки (различные)
ExtJS и jQuery
в первом случае, грид (в кот все сделано) - стандартный элемен ФреймВорка
сам фрэймворк очень удобен и гибок, есть один "недостаток" - мин. 500К будет загружаться (на клиента первый раз)
в jQuery придется часть "писать руками" (что и было во втором примере)...
библиотека поменьше
в первом ФВ можно (в 3-ей версии) обойтись core элементами (как управление данными), но рисовать тогда придется самому
я делал, на ЭкстЖС, тестовую базку, с выгрузкой XML (мини магазин), ФВ остался доволен, проверял на разных платформах и браузерах:
УЁ 6+ - виндя
УЁ 6 - кроссовер в линухах (64бит)
ФФ, Опера, Хром - линух 64бит
Сафари, ФФ, Опера - MacOSX PPC G5 (на интеле тоже)
везде получил практич. одинаковое поведение и отображение
 

NetWood

Lotus team
17.04.2008
374
20
#12
Вот потренируйтесь на кошках в начале. Этой базулине сто лет в обед. За одно и поиграете. Быки и коровы помните?
извольте...
 

Вложения

  • 127 КБ Просмотры: 34

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#13
игрой заинтригован! понравилась очень! :D раньше не встречал такой...

а вот по теме, мне этого мало :) кроме красивой верстки, меня еще интересует примеры формирования кода вида для его более удобной загрузки.
стандартно, сервер формирует таблицу, причем не всегда удобную; с категориями работать не удобно, т.к. только одна в момент времени отображена, постоянные перегрузки страницы; выбор документов не удобно, особенно, если их много; ну и т.п.
но спасибо! :)
 
Y

Yakov

#14
Akupaka
По теме. Сам веб в лотусах не пользую, но видел такое: клиент (браузер) получает вью в виде XML и применяет к нему XSL-преобразование. См. в справке URL commands for opening servers, databases, and views: ReadViewEntries.
Еще можно погуглить ReadDesign URL command. Вот здесь, к примеру, показано как вьюху во флешке отобразить.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#15
Yakov, спасибо! это мне известно :) занимательно, хотя имеет свои проблемы, тот же размер загружаемых данных, да и с преобразованиями не все так просто... хотя, может за год что-то изменилось - я давно не пробовал...
как вариант, можно само преобразование на сервере еще выполнять, но это доп нагрузка.
я склоняюсь к html + js + css пока что...
 
13.03.2009
625
1
#16
Yakov, спасибо! это мне известно :) занимательно, хотя имеет свои проблемы, тот же размер загружаемых данных, да и с преобразованиями не все так просто... хотя, может за год что-то изменилось - я давно не пробовал...
гм. размер данных в этом варианте - оптимальный. на клиент передаеца необходимый минимум. все рюшечки применяются на стороне клиента. не отдавать всю вьюху целиком можно( и нужно) пользуя ajax. подгрузка тех же категорий реализуеца на раз...
грамотный xslt с ключами сводит время обработки данных на клиенте к нулю.
т.е. если упор делаеца на производительность - то именно так: сервер отдает дату в xml. клиент ее юзает согласно хотелкам.
как вариант, можно само преобразование на сервере еще выполнять, но это доп нагрузка.
а вот делать преобразование на сервере - нонсенс. современная рабочая станция в состоянии решать вычислительные задачи. Любая станция, на которой может стартовать winxp, с легкостью применит шаблон. За время, уступающее времени получения самого XML и шаблона по сети. ( терминальный доступ - те же аргументы )
я склоняюсь к html + js + css пока что...
и это правильно. только оно должно быть создано на клиенте. задача сервера - отдать данные и, в лучшем случае, шаблон (xslt page). гонять по сети html разметку - нерационально, если можно передать клиенту инструкцию по ее созданию.

И, в догонку. еще одна ссылка: http://www.codestore.net/store.nsf/unid/BLOG-20090305
Не совсем вьюха, но тоже под веб. красота необыкновенная.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#17
чесгря, когда я использовал преобразования на клинете, то мне что-то не нравилось, но я уже не помню, что именно. я только учился его применять.
как минимум было сложно отлаживать - я передавал чистый xml + xsl, и браузер уже корячился как умел. не помню, но мне кажется, что без использования js на то время только IE умел преобразовывать данные по правилам.
мне кажется, что красиво оформленный xml + xsl будет занимать больше в объеме, чем html + css, но я не спец в xml.
а флеш - красиво, конечно, но почему-то раздражает ))
 
13.03.2009
625
1
#18
не помню, но мне кажется, что без использования js на то время только IE умел преобразовывать данные по правилам.
Немного путаешь понятия. Дом-модель в браузерах разная. А процессор xslt - везде работает одинаково. Любой XSLT процессор( apache , xalan , msxml , notesxslttransformer ) возвращает одинаковый результат ( и щаз, и пять лет назад) на заданных ( и валидных ) XML и XSLT.
JS к этому процессу тем более никакого отношения не имеет.

мне кажется, что красиво оформленный xml + xsl будет занимать больше в объеме, чем html + css, но я не спец в xml.
если видишь преимущество css + html над html , то должен разглядеть преимущество xml + xsl над html
в обоих случаях разделяются данные и их представление. и в обоих случаях устраняется ненужное дублирование разметки. т.е. эволюция статичной веб страницы шла так: html(данные, разметка. стиль) -> html(данные, разметка) + css(стиль) -> xml (данные)+ xsl(разметка, стиль)
а флеш - красиво, конечно, но почему-то раздражает ))
угу. флэш - красиво аж жуть. :) но времени разобраца как всегда нет. :-(
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#19
нет, я не путаю :) я помню, что в IE страница открывалась и преобразовывалась в соотв с правилом, а в лисе отображался текст xml
и для отображения данных корректно, нужно было создавать js-объект, который получал xml и преобразовывал его в соотв. с правилом... к сожалению, я не вспомню какая версия лисы тогда была...

ты знаешь, я после подумал, что при правильном преобразовании, и если отображается большой объем данных схожим образом, то конечно xml (с краткими тегами) будет менее объемным.
вероятно, тут многое будет решать опыт...
 
13.03.2009
625
1
#20
нет, я не путаю :) я помню, что в IE страница открывалась и преобразовывалась в соотв с правилом, а в лисе отображался текст xml
статья 4-хлетней давности: ( Published 20 Sep 2005 ): http://www.ibm.com/developerworks/xml/library/x-ffox15.html
You can embed portable xml:stylesheet processing instructions in the XML to instruct Firefox to load a CSS stylesheet or XSLT transform (both are discussed in a moment) and automatically display the result to the user instead of the original XML.

ключевое слово - валидные xml и xsl. ( ie, как известно, закрывает глаза на многие вещи, обязательные с точки зрения стандарта.)
первое что приходит в голову - проблемы могли быть связаны с некорректно объявлеными namespace.
ты знаешь, я после подумал, что при правильном преобразовании, и если отображается большой объем данных схожим образом, то конечно xml (с краткими тегами) будет менее объемным.
вероятно, тут многое будет решать опыт...
imho: правильно мыслишь! ;-)