Forward письма, некоторые упорно продолжают писать письма мимо кассы...
> -----Original Message-----
> From: sergiy shchuruk [mailto:sergiy.shchuruk_at_infopulse.com.ua]
> Sent: Tuesday, April 02, 2002 2:05 PM
> To: Igor Fomin
> Cc: Igor Geyfman; Alexandr Gleb; Eugene Ostroukhov; 'Igor
> Makarenko'; 'Yuri A. Karpenko'; mike.sikalo_at_kyriba.kiev.ua;
> 'Alexey Sigov'; 'Andrey Anissimov'; 'Alexander Abramov';
> 'Eugene Ostroukhoff'; 'Oleg Kaytanovskyy'; 'Sergey Shchuruk';
> 'Maxim Kussul'
> Subject: Re[2]: Результаты ревью JFW
>
>
> Dear Igor,
>
> Несколько наблюдений по поводу прочитанного:
>
> 1. Продолжаются попытки доказать что JFW никуда не годится на том
> основании что он не использует теорию "бизнес документов".
>
> Действительно, данная "теория" была отвергнута сознательно, ибо задача
> ставилась совершенно иная чем гибкость (которая в основном
> ассоциируется
> уже только с цветом глаз), а именно: поддержка максимально возможного
> количества SQL серверов и того же числа серверов приложений для
> платформы J2EE.
>
> 2. Наибольшую критику вызывают те решения, которые лишь в деталях (а
> не концептуально), отличаются одно от другого.
> (Примеры:
> 1. В МБТ используется SupportLibrary - враппер над ADO. В
> JFW Persistency - враппер над JDBC. Оба подхода по задачам
> неразличимы совершенно.
> 2. Content Managers обоих видов работают совершенно одинаково.
> Разница только в том что одному на вход нужно два файла а второму
> три.
> 3. Локализация на веб-уровне в первом и втором случае
> одинакова по причине
> копирования ее из МБТ без изменений.
> )
>
> Соответсвенно, дабы не продолжать дискуссию, в стиле "какой фреймворк
> более фреймворк?" предложение:
>
> Составить список необходимых компонентов либо взять готовый outline из
> JFW Vision и уточнив требования к системе определиться к конкретными
> вариантами реализации. Тогда и будет видно что сделано и как и чего не
> хватает. Это позволит скорректировать направление движения и что самое
> главное объеденить усилия.
>
>
> Tuesday,02 April, 2002, 10:53:56, you wrote:
>
> > В дополнение к письму Игоря Г:
> > в беседе о JFW Content manager мы выяснили следующие недостатки:
> > 1. невозможность локализации пользовательских настроек
> (разделители разрядов
> > и т.д.)
> > 2. многоязычность превращается в переписывание страничек
> (т.е. сколько
> > языков - столько сайтов)
> > 3. задачей 3х уровневой модели является не "отделить дизайн
> страницы от
> > данных" а "обработку от презентации". IMHO задача JFW
> Content manager не
> > сходна с задачей MBT CM (динамическое построение
> презентации на основе
> > ИЗМЕНЯЕМЫХ данных).
>
> > что касается представленной нам модели Персистанси:
> > 1. идеи какие то позавчерашние IMHO, особенно мне нравится
> XML-storage - ни
> > что иное как директории на диске (file-storage) тока файлов
> в формате XML.
> > ну и т.д.
> > 2. XML descriptor - сущность не представленная в документе и т.п.
> > неописанные фичи и подробности
> > 3. форматы данных в коде и неизменны без переписывания всех
> слоев (от
> > сторадж до презенташин).
> > 4. Идея Репортов = идее Content manager т.е. простое
> отображение данных. А
> > как вы эти данные получаете ??? ответ "пишем код".
> Интересненький репортинг
> > получается - гибкий, мощьный, переносымый...
>
> > общие замечания:
> > 1. (самое важное) - отсутствие процесса разработки. Нет детальных
> > требований, нет модели анализа, нет дизайна. (должно быть в такой
> > последовательности).
> > 2. в комманде нет другого мнения кроме мнения МИШИ Сикало.
> Знания от него
> > передаются устно или на пальцах.
>
> > PS. Насколько я понял XRT им нужны гибкие, быстро изменяемы
> приложения а не
> > переписываемые с самого начала.
>
> > Дали буде !!!!
> > Игорь
>
> >> -----Original Message-----
> >> From: Igor Geyfman [mailto:Igor.Geyfman_at_infopulse.kiev.ua]
> >> Sent: Monday, April 01, 2002 6:28 PM
> >> To: Alexandr Gleb; Eugene Ostroukhov; 'Igor Makarenko'; 'Yuri A.
> >> Karpenko'
> >> Cc: mike.sikalo_at_kyriba.kiev.ua;
> igor.fomin_at_infopulse.kiev.ua; 'Alexey
> >> Sigov'; 'Andrey Anissimov'; 'Alexander Abramov'; 'Eugene
> Ostroukhoff';
> >> 'Oleg Kaytanovskyy'; 'Sergey Shchuruk'; 'Maxim Kussul'
> >> Subject: Результаты ревью JFW
> >>
> >>
> >> Вот то, что уже видно из представленной информации по JFW.
> >>
> >> 1. Ошибочное мнение что в JFW используется MVC design pattern.
> >> Французы к счастью (или к сожалению для некоторых :))
> понимают что это
> >> такое. Это было ясно из презентации ХРТ, как и то что они захотят
> >> использования MVC в архитектуре проекта.
> >> Дело в том что в представленной архитектуре говориться что
> в она построена
> >> на базе MVC. Если использование Java классов (хотя это должны быть
> >> JavaBeans) в качестве Model части не вызывает вопросов, то
> все остальное -
> >> какая-то гремучая смесь технологий. Использование в качестве
> >> Controller JSP
> >> да еще и с custom tags слегка противоречит как правилам
> >> использования такого
> >> компонента J2EE как JSP (который предназначен только для
> презентации), так
> >> правилам реализации Controller части MVC. Контроллер должен
> >> содержать только
> >> программную логику обработки HTTP запроса и выбора следующего
> >> View, а также
> >> быть независимым от презентации (иначе мы имеем смесь
> презентации с бизнес
> >> логикой за которую и борется MVC design pattern). Если
> говорить о View
> >> части, то в JFW Vision написано что она представлена xHTML
> >> файлом. На самом
> >> деле за View отвечают почти все части с-мы(JSP со своими
> тегами, xHTML,
> >> xml-mapping file). Где же здесь разделение презентации от
> логики? Также по
> >> правилам MVC Controller изменяет Model а View использует Model для
> >> презентации. Это слегка непривычно для понимания для классического
> >> программиста, но в настоящее время все веб-ориентированные с-мы
> >> строятся на
> >> этом подходе. Прежде чем декларировать использование MVC,
> >> необходимо глуюже
> >> разобраться в вопросе. Если французы лохи - их можно будет
> укатать на что
> >> угодно, как я понимаю это и происходило в предидущих
> проектах. Если в их
> >> команде хоть один грамотный архитектор - думаю это сильно
> повлияет на
> >> репутацию компании.
> >> В МБТ ситуация несколько иная. На платформе Микрософт нет соотв.
> >> инструментов для полной реализации MVC. Поэтому мы и
> выбрали решение,
> >> которое оптимально именно для этой платформы. Его конечно можно
> >> перенести на
> >> Джаву без изменений, а можно просто использовать некоторые его
> >> отработанные
> >> части в правильной реализации веб лейера на J2EE платформе, что и
> >> предлагается. В JFW получилось, что из нашего контент
> менеджера взяли
> >> некоторые идеи, не всегда лучшие, и добавили некоторую
> функциональность,
> >> которая не подпадает ни под какие принятые в архитектуре
> design patterns.
> >>
> >> 2. Для того чтобы реализовывать Веб лейер не обязательно писать
> >> свой контент
> >> менеджер.
> >> Для построения веб лейера существует множество
> имплементаций MVC design
> >> pattern. Взяться за собственное решение может только
> команда, имеющая
> >> большой опыт в веб приложениях и четкое понимание сути
> предмета. Судя по
> >> пункту 1 это не совсем так. В такой ситуации правильнее было бы
> >> использовать
> >> готовые решения, адаптировав их к нашему проекту. Я так
> понял что была
> >> предпринята попытка посмотреть на Struts, но судя по
> предлагаемому решению
> >> его архитектура не была понята. Использование описанной и
> реализованной
> >> архитектуры (при желании в ней разобраться конечно)
> >> гарантированно исключит
> >> возможность не построить с-му из-за ошибок во фреймворке,
> т.к. имеющиеся
> >> решения много раз проверены на практике и доказали свою
> пригодность. Даже
> >> Sun в своих рекомендациях рекомендует использовать готовое
> >> решение для MVC,
> >> такое как Struts.
> >>
> >> 3. В общем вреймворке невозможно определить визуальные елементы.
> >> Написание Custom Tags, которые в MVC используются для определения
> >> визуальных
> >> элементов, начинается тогда, когда четко известны
> визуальные элементы
> >> системы. Определить их на нынешней стадии невозможно, т.к. нет
> >> требований к
> >> GUI.
> >>
> >> 4. Писать собстенные Custom Tags надо когда недостает имеющихся.
> >> Существует множество Custom Tag Libraries которые
> проверены во множестве
> >> проектов. Кому будет интересно - где их искать и какие из
> них стабильные
> >> сообщу дополнительно :). Практически все визуальные
> елементы, описанные в
> >> JFW уже давно реализованы в этих библиотеках в разных
> интерпретациях.
> >> Гараздо проще выбрать готовую библиотеку и использовать
> ее. Это сокращает
> >> срок разработки и исключает ошибки.
> >>
> >> 5. Написание собственных Custom Tags возможно только при высокой
> >> квалификации программистов.
> >> Без коментариев... Они тяжелы как в отладке, так и при
> переделке в случае
> >> необходимости. Ведь на них завязана вся презентация.
> >>
> >> 6. Реализация своего Persistent лейера сложна даже для
> крупных компаний.
> >> Реализация persistensy занимает 25-30% обьема проекта.
> Применение своего
> >> решения в этом вопросе очень ответственный момент. В любом случае
> >> он должен
> >> поддерживать гибкость при работе с данными. Пока из представленных
> >> документов и модели не ясна даже концепция этого модуля.
> >>
> >> 7. Security (Authorization and Authentication). Опять
> доморощенное :(
> >> Во фреймворке уже начали закладываться какие-то механизмы Security.
> >> Интересно на сколько они соответствую уже
> стандартизованной модели JAAS,
> >> принятой в J2EE. Французы говорили об использовании стандартов и
> >> спецификаций J2EE. А я тут шо-то не заметил и намеков на
> >> использование JAAS
> >> спецификации в реализации этого сервиса, хотя она для этого и
> >> предназначена.
> >> Конечно свое решение возможно наваять проще, чем разбираться в
> >> каких-то там
> >> спецификациях. Вопрос - удовлетворит ли это французов. И опять же
> >> любое свое
> >> решение надо отлаживать и тестировать. И быть увереным что оно
> >> концептуально
> >> правильное. Надеюсь спецификация JAAS концептуально правильная
> >> :). А подход
> >> JFW ???
> >>
> >> Вот, собственно, такие замечания к тому что я смог увидеть. При
> >> поступлении
> >> дополнительных документов и разьяснений, возможно будут
> дополнительные
> >> замечания.
> >>
> >> Выводы я бы сделал такие: Нежелание ознакомится с существующими на
> >> сегодняшний день стандартами, спецификациями,
> архитектурными решениями,
> >> design patterns и реализациями конечно облегчает жизнь (не
> надо что-то
> >> читать и изучать сегодня). Но сможем ли мы с таким
> подходом написать
> >> конкурентоспособную с-му завтра? И дойдет ли вообще до
> реализации если у
> >> французов есть грамотный архитектор, который почитав и
> посмотрев на наши
> >> решения примет свое, и не в нашу пользу.
> >> Мы (2 Игоря) пришли в этот проект чтобы все-таки, несмотря на
> >> сопротивление
> >> отдельных кругов :), сделать рабочую с-му, а не заниматься
> тренировками на
> >> клиентах. Используя подход, который мы видим в JFW, я считаю это
> >> нереальным.
> >> Заранее извиняюсь если кого-то обидел.
> >>
> >> Спасибо за внимание. Апплодисменты не надо :)))
> >>
> >> Copyright 2002 Igor Geyfman
>
>
>
>
> Best regards,
> sergiy
> mailto:sergiy.shchuruk_at_infopulse.com.ua
>
Received on Tue Apr 02 2002 - 05:44:42 CST
