Agahov's blog - Последние комментарии http://riapriority.com/blogs/agahov.php?disp=comments ru-RU http://backend.userland.com/rss 60 В ответ на: Flex mojos 3.1 released Sat, 16 Jan 2010 12:00:09 +0000 fzn7 [Посетитель] c4197@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/30dc435029559d495892a718536eb861.png" alt="" title="" class="leftmargin vg2" />UPD: Вышел flexmojos 3.5, где добавился sign-air goal UPD: Вышел flexmojos 3.5, где добавился sign-air goal]]> http://riapriority.com/blogs/agahov.php/2009/04/14/flex-mojos-3-1-released#c4197 В ответ на: Flex mojos 3.1 released Mon, 11 Jan 2010 10:35:40 +0000 fzn7 [Посетитель] c4194@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/30dc435029559d495892a718536eb861.png" alt="" title="" class="leftmargin vg2" />Все еще не добавили нормальную поддержку AIR, хотя она и заявляется. Для паковки приходится писать в ант стиле из-за закрытой лицензии.<br /> <br /> Что-бы добавить в проект поддержку mojos не нужно править settingx.xml Лучше прописать путь до него в самом pom.xml, что-бы проект собирался без хитрых манипуляций с настройками. Все еще не добавили нормальную поддержку AIR, хотя она и заявляется. Для паковки приходится писать в ант стиле из-за закрытой лицензии.

Что-бы добавить в проект поддержку mojos не нужно править settingx.xml Лучше прописать путь до него в самом pom.xml, что-бы проект собирался без хитрых манипуляций с настройками.]]> http://riapriority.com/blogs/agahov.php/2009/04/14/flex-mojos-3-1-released#c4194 В ответ на: Package organization Fri, 21 Aug 2009 08:41:58 +0000 Racer242 [Посетитель] c4124@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/33fadb1ee225dd252dd492c62c8defac.png" alt="" title="" class="leftmargin vg2" />> Mate+Flex-модули<br /> <br /> Ничего конкретного, просто активно использую модули, но без Mate, и т.к. сталкивался с разного рода проблемами, прощупываю почву. Нет проблем - и отлично <img src="http://riapriority.com/blogs/rsc/smilies/icon_smile.gif" alt="&#58;&#41;" class="middle" />.<br /> <br /> <br /> > Mate+Flex-модули

Ничего конкретного, просто активно использую модули, но без Mate, и т.к. сталкивался с разного рода проблемами, прощупываю почву. Нет проблем - и отлично :).


]]> http://riapriority.com/blogs/agahov.php/2009/08/14/package-organization#c4124 В ответ на: Package organization Tue, 18 Aug 2009 09:12:06 +0000 agahov [Учаснег] c4123@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/e7cfbc5684851911ffca0d89622f7e88.png" alt="" title="" class="leftmargin vg2" />Спасибо за обратную связь.<br /> <blockquote>Действительно, такой подход актуален для крупных проектов, но все же, для малых, я бы не советовал отказываться от пакетной структуризации, даже для демок. Ибо, как кто-то сказал, оно ум в порядок приводит . <br /> </blockquote><br /> Я рекомендовал как раз не структурировать маленький проект формально по типам. И пока он реально соответствует домену, в котором находиться не создавать лишних пакетов. Как только он усложниться пакеты сами напрашиваются.<br /> <br /> <br /> <blockquote>Кстати, я наоборот, с появлением в моей практике Mate, перешел на организацию vo/events/business/. И правда, модульность нарушается - разные по смыслу, хотя и однородные классы складируются в один пакет, что не есть хорошо. Но с другой стороны, в этом тоже есть плюсы. Возможно, для крупных проектов, есть смысл делать такие структуры как rootpackage. accessmanagment.vo/events/views, получая что-то типа суб-приложений и сохраняя принципы Mate/Cairngorm?<br /> </blockquote><br /> Думаю что если использовать Mate+Cairngorm, наверное нормально создавать пакеты по типам. Сам же Mate, не задает определенной структуры. <br /> Я в своей практике пришел к разбиению по предметной области. Пакет views (events) с моей точки зрения имеет смысл если вы разрабатываете визуальную библиотеку или он находиться с пакете common и используется другими пакетами, на том же уровне иерархии. <br /> <br /> <blockquote>Кстати, хотел спросить - не встречались проблемы с работой Mate+Flex-модули?<br /> </blockquote><br /> Мне требуется уточнение какие именно проблемы, у меня есть приложение которое построено именно так, но возможно я что- то упустил. Модуль там использует LocalEventMap. Часть внутренних событий модуля останавливается, что бы их не ловило главное приложение. <br /> <br /> Спасибо за обратную связь.
Действительно, такой подход актуален для крупных проектов, но все же, для малых, я бы не советовал отказываться от пакетной структуризации, даже для демок. Ибо, как кто-то сказал, оно ум в порядок приводит .

Я рекомендовал как раз не структурировать маленький проект формально по типам. И пока он реально соответствует домену, в котором находиться не создавать лишних пакетов. Как только он усложниться пакеты сами напрашиваются.


Кстати, я наоборот, с появлением в моей практике Mate, перешел на организацию vo/events/business/. И правда, модульность нарушается - разные по смыслу, хотя и однородные классы складируются в один пакет, что не есть хорошо. Но с другой стороны, в этом тоже есть плюсы. Возможно, для крупных проектов, есть смысл делать такие структуры как rootpackage. accessmanagment.vo/events/views, получая что-то типа суб-приложений и сохраняя принципы Mate/Cairngorm?

Думаю что если использовать Mate+Cairngorm, наверное нормально создавать пакеты по типам. Сам же Mate, не задает определенной структуры.
Я в своей практике пришел к разбиению по предметной области. Пакет views (events) с моей точки зрения имеет смысл если вы разрабатываете визуальную библиотеку или он находиться с пакете common и используется другими пакетами, на том же уровне иерархии.

Кстати, хотел спросить - не встречались проблемы с работой Mate+Flex-модули?

Мне требуется уточнение какие именно проблемы, у меня есть приложение которое построено именно так, но возможно я что- то упустил. Модуль там использует LocalEventMap. Часть внутренних событий модуля останавливается, что бы их не ловило главное приложение.

]]> http://riapriority.com/blogs/agahov.php/2009/08/14/package-organization#c4123 В ответ на: Package organization Tue, 18 Aug 2009 06:53:36 +0000 Racer242 [Посетитель] c4122@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/33fadb1ee225dd252dd492c62c8defac.png" alt="" title="" class="leftmargin vg2" />Отличная статья, обожаю эстетствовать с пакетами и классами. <br /> Действительно, такой подход актуален для крупных проектов, но все же, для малых, я бы не советовал отказываться от пакетной структуризации, даже для демок. Ибо, как кто-то сказал, оно ум в порядок приводит <img src="http://riapriority.com/blogs/rsc/smilies/icon_smile.gif" alt="&#58;&#41;" class="middle" />. <br /> Кстати, я наоборот, с появлением в моей практике Mate, перешел на организацию vo/events/business/. И правда, модульность нарушается - разные по смыслу, хотя и однородные классы складируются в один пакет, что не есть хорошо. Но с другой стороны, в этом тоже есть плюсы. Возможно, для крупных проектов, есть смысл делать такие структуры как <em>rootpackage. accessmanagment.vo/events/views</em>, получая что-то типа суб-приложений и сохраняя принципы Mate/Cairngorm?<br /> <br /> Кстати, хотел спросить - не встречались проблемы с работой Mate+Flex-модули?<br /> <br /> ЗЫ: соверую перед публикацией копипастнуть пост в word, а то перлы типа "предметной обсласти" радуют глаз <img src="http://riapriority.com/blogs/rsc/smilies/icon_smile.gif" alt="&#58;&#41;" class="middle" /> Отличная статья, обожаю эстетствовать с пакетами и классами.
Действительно, такой подход актуален для крупных проектов, но все же, для малых, я бы не советовал отказываться от пакетной структуризации, даже для демок. Ибо, как кто-то сказал, оно ум в порядок приводит :).
Кстати, я наоборот, с появлением в моей практике Mate, перешел на организацию vo/events/business/. И правда, модульность нарушается - разные по смыслу, хотя и однородные классы складируются в один пакет, что не есть хорошо. Но с другой стороны, в этом тоже есть плюсы. Возможно, для крупных проектов, есть смысл делать такие структуры как rootpackage. accessmanagment.vo/events/views, получая что-то типа суб-приложений и сохраняя принципы Mate/Cairngorm?

Кстати, хотел спросить - не встречались проблемы с работой Mate+Flex-модули?

ЗЫ: соверую перед публикацией копипастнуть пост в word, а то перлы типа "предметной обсласти" радуют глаз :)]]> http://riapriority.com/blogs/agahov.php/2009/08/14/package-organization#c4122 В ответ на: Flex-Mojos. Пример сборки flex modules. Sat, 30 May 2009 05:36:43 +0000 Андрей [Посетитель] c4094@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/20bc8fa372d426a40ee5f8aa9a72282d.png" alt="" title="" class="leftmargin vg2" />ну я сразу использовал самую новую версию плагина(org.sonatype.flexmojos:flexmojos-maven-plugin:3.2)<br /> генерировал линк рипорт для апликейшена и модуля - LayoutContainer включается в апликейшн и исключается (экстернал) для модуля, что логично. пробывал принудительно включить клас LayoutContainer в модуль (через ) но ноль эффекта.. я уже начал думать на безопасность но ошибка была бы другая да и все свифки локал-трастед... <br /> в общем попробую делать так как флексбилдер - компилировать модуль с конфигурацией исключающей все классы фреймворка - конечно не совсем читый подход так как свои классы таки будут повторяться... ну я сразу использовал самую новую версию плагина(org.sonatype.flexmojos:flexmojos-maven-plugin:3.2)
генерировал линк рипорт для апликейшена и модуля - LayoutContainer включается в апликейшн и исключается (экстернал) для модуля, что логично. пробывал принудительно включить клас LayoutContainer в модуль (через ) но ноль эффекта.. я уже начал думать на безопасность но ошибка была бы другая да и все свифки локал-трастед...
в общем попробую делать так как флексбилдер - компилировать модуль с конфигурацией исключающей все классы фреймворка - конечно не совсем читый подход так как свои классы таки будут повторяться...]]> http://riapriority.com/blogs/agahov.php/2008/08/13/flex-mojos-flex-modules#c4094 В ответ на: Flex-Mojos. Пример сборки flex modules. Thu, 28 May 2009 21:43:41 +0000 agahov [Учаснег] c4093@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/e7cfbc5684851911ffca0d89622f7e88.png" alt="" title="" class="leftmargin vg2" />рекомендую использовать новый flex-mojos. вот тут я описал отличия<br /> http://riapriority.com/blogs/agahov.php/2009/04/14/flex-mojos-3-1-released<br /> Потому как много воды утекло, а разбираться почему перестала рабтать устаревшая версия смысла нет.<br /> <br /> возможно что проблема в том, что классы не попали не в основное приложение ни в модуль. Flex компилятор не включает в код классы которые не используются в приложении. Следовательно нужно указывать компилятору какие доп. классы включать, или по простому завести переменную искомого класса(для пробы).<br /> <br /> <br /> <br /> <br /> рекомендую использовать новый flex-mojos. вот тут я описал отличия
http://riapriority.com/blogs/agahov.php/2009/04/14/flex-mojos-3-1-released
Потому как много воды утекло, а разбираться почему перестала рабтать устаревшая версия смысла нет.

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




]]> http://riapriority.com/blogs/agahov.php/2008/08/13/flex-mojos-flex-modules#c4093 В ответ на: Flex-Mojos. Пример сборки flex modules. Wed, 27 May 2009 16:48:16 +0000 Андрей [Посетитель] c4092@http://riapriority.com/blogs/ <img src="http://riapriority.com/blogs/plugins/visiglyph_plugin/visiglyphs/20bc8fa372d426a40ee5f8aa9a72282d.png" alt="" title="" class="leftmargin vg2" />попробывал пример но скомпилированый результат ругается VerifyError: Error #1014: Class mx.core::LayoutContainer could not be found. причем если билдить флексбилдером те же файлы (простейшие апликейшн и модуль)то там все ок но размер модуля немножко больше. очевидно что флексбилдер компилирует как-то по особенному. небольшое расследование показало что флексбилдер не использует стандартный механихм с link-report файлом а спаивает компилятор конфигом где указаны какие классы надо исключить - я так понимаю таким образом модули можно компилировать отдельно и вначале. и что наиболее обыдно, по-другому пути(обычному, через линк-репорт) не получается скомпилировать нормально запускающийся модуль. <br /> буду признателен за идеи как же все-таки можно заставить закомпилить модули с флексмоджосами )<br /> <br /> попробывал пример но скомпилированый результат ругается VerifyError: Error #1014: Class mx.core::LayoutContainer could not be found. причем если билдить флексбилдером те же файлы (простейшие апликейшн и модуль)то там все ок но размер модуля немножко больше. очевидно что флексбилдер компилирует как-то по особенному. небольшое расследование показало что флексбилдер не использует стандартный механихм с link-report файлом а спаивает компилятор конфигом где указаны какие классы надо исключить - я так понимаю таким образом модули можно компилировать отдельно и вначале. и что наиболее обыдно, по-другому пути(обычному, через линк-репорт) не получается скомпилировать нормально запускающийся модуль.
буду признателен за идеи как же все-таки можно заставить закомпилить модули с флексмоджосами )

]]> http://riapriority.com/blogs/agahov.php/2008/08/13/flex-mojos-flex-modules#c4092