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

Тема в разделе "Lotus - Программирование", создана пользователем Akupaka, 22 июн 2009.

  1. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Всем привет! ;)
    хочу расширить свой кругозор по разработке видов для domino-приложений...
    нагло прошу ссылки на примеры по которым можно научится красиво делать виды с использованием html, xml, js, css...
    а не использовать стандартный механизм генерации html'а для видов...

    Заранее спасибо! :(
     
  2. oshmianski

    oshmianski Гость

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

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
  4. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    вопрос в догонку, кто-то сравнивал разницу в производительности при формировании вида стандартным механизмом и агентом, который перебирает вид и "рисует" свой код страницы? большая разница?
     
  5. K-Fire

    K-Fire Гость

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

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

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    шикарненько, а инфа внутри еще больше заинтересовала ))

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

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

    K-Fire Гость

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

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    спасибо, я предполагал, что дело именно в размере
     
  9. oshmianski

    oshmianski Гость

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    мне кажется, что для этого было бы лучше сделать какую-то отдельную возможность, ведь не все приложения генерят данные быстро и много... ну то такое ;)
     
  11. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.073
    Симпатии:
    299
    в приведеных, выше, примерах юзаются две библиотеки (различные)
    ExtJS и jQuery
    в первом случае, грид (в кот все сделано) - стандартный элемен ФреймВорка
    сам фрэймворк очень удобен и гибок, есть один "недостаток" - мин. 500К будет загружаться (на клиента первый раз)
    в jQuery придется часть "писать руками" (что и было во втором примере)...
    библиотека поменьше
    в первом ФВ можно (в 3-ей версии) обойтись core элементами (как управление данными), но рисовать тогда придется самому
    я делал, на ЭкстЖС, тестовую базку, с выгрузкой XML (мини магазин), ФВ остался доволен, проверял на разных платформах и браузерах:
    УЁ 6+ - виндя
    УЁ 6 - кроссовер в линухах (64бит)
    ФФ, Опера, Хром - линух 64бит
    Сафари, ФФ, Опера - MacOSX PPC G5 (на интеле тоже)
    везде получил практич. одинаковое поведение и отображение
     
  12. NetWood

    NetWood Lotus team
    Lotus team

    Регистрация:
    17 апр 2008
    Сообщения:
    308
    Симпатии:
    0
    Вот потренируйтесь на кошках в начале. Этой базулине сто лет в обед. За одно и поиграете. Быки и коровы помните?
    извольте...
     

    Вложения:

    • game.zip
      Размер файла:
      127 КБ
      Просмотров:
      34
  13. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    игрой заинтригован! понравилась очень! :D раньше не встречал такой...

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

    Yakov Гость

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Yakov, спасибо! это мне известно :) занимательно, хотя имеет свои проблемы, тот же размер загружаемых данных, да и с преобразованиями не все так просто... хотя, может за год что-то изменилось - я давно не пробовал...
    как вариант, можно само преобразование на сервере еще выполнять, но это доп нагрузка.
    я склоняюсь к html + js + css пока что...
     
  16. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    гм. размер данных в этом варианте - оптимальный. на клиент передаеца необходимый минимум. все рюшечки применяются на стороне клиента. не отдавать всю вьюху целиком можно( и нужно) пользуя ajax. подгрузка тех же категорий реализуеца на раз...
    грамотный xslt с ключами сводит время обработки данных на клиенте к нулю.
    т.е. если упор делаеца на производительность - то именно так: сервер отдает дату в xml. клиент ее юзает согласно хотелкам.
    а вот делать преобразование на сервере - нонсенс. современная рабочая станция в состоянии решать вычислительные задачи. Любая станция, на которой может стартовать winxp, с легкостью применит шаблон. За время, уступающее времени получения самого XML и шаблона по сети. ( терминальный доступ - те же аргументы )
    и это правильно. только оно должно быть создано на клиенте. задача сервера - отдать данные и, в лучшем случае, шаблон (xslt page). гонять по сети html разметку - нерационально, если можно передать клиенту инструкцию по ее созданию.

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    чесгря, когда я использовал преобразования на клинете, то мне что-то не нравилось, но я уже не помню, что именно. я только учился его применять.
    как минимум было сложно отлаживать - я передавал чистый xml + xsl, и браузер уже корячился как умел. не помню, но мне кажется, что без использования js на то время только IE умел преобразовывать данные по правилам.
    мне кажется, что красиво оформленный xml + xsl будет занимать больше в объеме, чем html + css, но я не спец в xml.
    а флеш - красиво, конечно, но почему-то раздражает ))
     
  18. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    Немного путаешь понятия. Дом-модель в браузерах разная. А процессор xslt - везде работает одинаково. Любой XSLT процессор( apache , xalan , msxml , notesxslttransformer ) возвращает одинаковый результат ( и щаз, и пять лет назад) на заданных ( и валидных ) XML и XSLT.
    JS к этому процессу тем более никакого отношения не имеет.

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    нет, я не путаю :) я помню, что в IE страница открывалась и преобразовывалась в соотв с правилом, а в лисе отображался текст xml
    и для отображения данных корректно, нужно было создавать js-объект, который получал xml и преобразовывал его в соотв. с правилом... к сожалению, я не вспомню какая версия лисы тогда была...

    ты знаешь, я после подумал, что при правильном преобразовании, и если отображается большой объем данных схожим образом, то конечно xml (с краткими тегами) будет менее объемным.
    вероятно, тут многое будет решать опыт...
     
  20. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    статья 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.
    imho: правильно мыслишь! ;-)
     
Загрузка...

Поделиться этой страницей