"Yuri A. Karpenko" <yuraka_at_yahoo.com> wrote in message news:<a8c5j0$p5t$1_at_alice.infopulse.kiev.ua>...
> 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
This looks like the wrong place to write heiroglyphics or if it is me
who is in the wrong place then bye
Michael Tubuo Ngong (Sr DBA)
> >
Received on Tue Apr 02 2002 - 10:28:52 CST
