Про ООо непонятно, а вот в Jenkins ушло ядро разработки вместе с основателем, так что Hudson остался без команды, а значит будет тихо гнить или получится другой проект со временем (новая команда и новый лидер команды).
Ну и особого смысла делать так, а не с помощью кодогенерации нет (затраты на реализацию примерно одинаковы). Просто сомнительное с архитектурной точки зрения решение.
Вот вариант с использованием кастомного генератора RooProxyConstructor для Roo (вместо написания ProxyFactory и проверки для анта):
@RooJavaBean
@RooProxyConstructor(Person.class)
public class PersonView {
private long id;
private String firstName;
private String lastName;
private List<PersonView> children;
}
Мне кажется, что это учитывает все ваши плюсы + генерация кода во время компиляции, а не во время выполнения (строго там не генерация кода, но нечто подобное).
Проще (вместо ProxyFactory) было бы написать аннотацию для Roo, которая бы создавала подобный конструктор (если руками по какой-то причине не хочется писать). Что-то вроде @RooProxyConstructor(Person.class). Не очень понятно какие проверки в ант-билдере, возможно он бы и не понадобился (или его достаточно просто адаптировать). Плюс Roo в том, что он срабатывает в момент компиляции, а не выполнения (как рефлексии).
На первый взгляд красиво (интерфейс, магический класс), но писать POJO с нужными полями и конструктором от Person ничем не хуже, а даже немного лучше за счет производительности (без рефлексии), простоты кода (особенно, если геттеры и сеттеры генерируются Roo) и прямолинейности использования (передается параметр в конструктор, а не неочевидный класс для получения IPerson).
Что-то вроде:
@RooJavaBean
public class PersonView {
private long id;
private String firstName;
private String lastName;
private List<PersonView> children;
public PersonView(Person p){
id = p.getId();
firstName = p.getFirstName();
lastName = p.getLastName();
//считаем, что children != null или добавляем проверки
children = new ArrayList<PesonView>(p.getChildren().size());
//for
}
}
Т.е. относительно интерфейса добавляется только конструктор, зато не нужно использовать сторонние классы. В IDE такой конструктор так же полуавтоматически создается.
Немного по руби коду:
1) в times не нужно вручную менять i, а когда i не нужно, можно ее не писать:
10.times { |i| puts i }; 5.times { puts :hello; }
2) при объявлении method_missing лучше так же объявлять respond_to? с той же регуляркой (чтобы проверки на наличие метода срабатывали, если кто-то захочет проверить, подробнее www.dcmanges.com/blog/30; понятно, что код в статье на поиграться, но все же):
def respond_to?(method_name)
/^(.*)_(.*)_from_(.*)$/.match(method_name.to_s) || super
end
Интересно как он картинки обрабатывает: для экрана достаточно 72/90dpi, а на печать от 300dpi. Собственно, можно ли там использовать картинки с высоким dpi или он все равно при отрисовки и сохранении в файл проставит 72dpi?
Это именно как Session-Per-Request делается в Спринге. Согласен, что это не очень хорошее архитектурное решение и сам не использую, но вполне представляю, что в некоторых случаях может пригодиться.
Скоро сделаем рассылку со ссылкой на пригласительный билет. Там будет расписана вся необходимая информация (кто, что, где, когда и как добраться). Распечатка пригласительного необязательна, т.к. у нас, как местами в РЖД, действует электронная регистрация и списки будут :).
1) автоматический редирект только для / (корня)
2) на каждой странице мобильного сайта (или только на первой) снизу ссылка «Полная версия» на /full
3) /full на основном сайте — это копия / (корня), в robots.txt прописывается, чтобы не индексировалась
4) на каждой странице основного сайта (или только на первой) ссылка на «Мобильная версия» (на / мобильного сайта, если для этой страницы нет соответствия на мобильном сайте)
5) на мобильном сайте автоматического редиректа на основной нет
Тогда не понял о чем мы тут говорим. Я начал с того, что это нужно делать через свою функцию, к функции и пришли. Каждый «чих» через протокол не кажется оптимальным вариантом. То, что можно задавать параметр через xsl:param понятно, но там где бы потребовалась 1 строчка в xslt нужно несколько. Больше строчек — сложнее разбираться и больше вероятных ошибок.
PS. Локализация в 99% российских сайтов не нужна, можно было и не вспоминать (на других платформах так же адекватно делается).
Да, именно интересно посмотреть на полный пример на xslt (в частности работа с остатком от деления), т.е. именно полный аналог. Думаю, это не только мне будет полезно увидеть, если адекватных размеров получится шаблон (и вообще получится).
Вопрос не в усложнении, а в реальности примера. А, т.е. «content/formatNumber» собственная функция, тогда действительно можно строки внутрь функции положить. Только в этом случае название должно быть не formatNumber, а formatMessages (т.к. подходит только для сообщений, а для других слов нужно писать другие функции или задавать параметры в урле (не самое удобное представление параметров, особенно строковых).
Я нигде не писал, что php «любимый», не нужно передергивать. Просто xslt заставляет писать весьма громоздкие конструкции, а плюсы непонятны (то, что архитектурно заставляет разделять код и представление — не плюс, т.к. решается административными мерами у нас).
Согласен, что это относится к оформлению. Обычно это делается разными способами кода в шаблоне (фильтры смарти, хелперы в rails, теги в java). В umi представляется это делать с помощью протоколов (как aprusov и советовал), Xslt такое не особо позволяет. Вот логика выбора вариантов (без отдельного варианта для «нет сообщений», но тут это не так уж и важно):
15 сайтов на UMI — это, думаю, больше, чем у 50% (а то и 80%) процентов партнеров UMI. Все-таки, такой опыт достаточен для суждений о системе. Естественно «гуру», которые систему и разрабатывали многое могут сделать и лучше, но вряд ли стоит рассчитывать на это с большинством партнеров…
Я это и имел в виду (udata — тоже протокол), когда говорил, что придется делать свой модуль (если в апи такой функции еще нет). Так уже получаются достаточно страшные (нечитаемые) конструкции (число 4 — это же не будет на реальном сайте константой, а откуда-то берется и еще нужно указать 4 формы (нет сообщений, %s сообщение, %s сообщения, %s сообщений). Ваш пример слишком упрощен, поэтому выглядит более-менее прилично.
PS. На сайте help-dev.umi-cms.ru/ не нашел макроса %content formatNumber%, но вполне верю, что такой может появиться в след. версии (или есть, но не документированный).
RooProxyConstructorдля Roo (вместо написанияProxyFactoryи проверки для анта):Мне кажется, что это учитывает все ваши плюсы + генерация кода во время компиляции, а не во время выполнения (строго там не генерация кода, но нечто подобное).
ProxyFactory) было бы написать аннотацию для Roo, которая бы создавала подобный конструктор (если руками по какой-то причине не хочется писать). Что-то вроде@RooProxyConstructor(Person.class). Не очень понятно какие проверки в ант-билдере, возможно он бы и не понадобился (или его достаточно просто адаптировать). Плюс Roo в том, что он срабатывает в момент компиляции, а не выполнения (как рефлексии).Что-то вроде:
Т.е. относительно интерфейса добавляется только конструктор, зато не нужно использовать сторонние классы. В IDE такой конструктор так же полуавтоматически создается.
Немного по руби коду:
1) в times не нужно вручную менять i, а когда i не нужно, можно ее не писать:
2) при объявлении method_missing лучше так же объявлять respond_to? с той же регуляркой (чтобы проверки на наличие метода срабатывали, если кто-то захочет проверить, подробнее www.dcmanges.com/blog/30; понятно, что код в статье на поиграться, но все же):
По сути передает сессию hibernate и во view, так что можно подгружать необходимые lazy-поля.
1) автоматический редирект только для / (корня)
2) на каждой странице мобильного сайта (или только на первой) снизу ссылка «Полная версия» на /full
3) /full на основном сайте — это копия / (корня), в robots.txt прописывается, чтобы не индексировалась
4) на каждой странице основного сайта (или только на первой) ссылка на «Мобильная версия» (на / мобильного сайта, если для этой страницы нет соответствия на мобильном сайте)
5) на мобильном сайте автоматического редиректа на основной нет
PS. Локализация в 99% российских сайтов не нужна, можно было и не вспоминать (на других платформах так же адекватно делается).
Я нигде не писал, что php «любимый», не нужно передергивать. Просто xslt заставляет писать весьма громоздкие конструкции, а плюсы непонятны (то, что архитектурно заставляет разделять код и представление — не плюс, т.к. решается административными мерами у нас).
Т.к. задача стандартная, то хотелось бы увидеть как это будет выглядеть в xslt.
PS. На сайте help-dev.umi-cms.ru/ не нашел макроса %content formatNumber%, но вполне верю, что такой может появиться в след. версии (или есть, но не документированный).