Pull to refresh
4
Игорь Степин@IgorStepin

Архитектор, разработчик

20
Subscribers
Send message
Про ООо непонятно, а вот в 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
А почему у нас будет хуже? Места на рынке же больше?
вроде как статическая сборка с патченным qt не тащит
Интересно как он картинки обрабатывает: для экрана достаточно 72/90dpi, а на печать от 300dpi. Собственно, можно ли там использовать картинки с высоким dpi или он все равно при отрисовки и сохранении в файл проставит 72dpi?
Это именно как Session-Per-Request делается в Спринге. Согласен, что это не очень хорошее архитектурное решение и сам не использую, но вполне представляю, что в некоторых случаях может пригодиться.
У Spring для этого есть готовое решение: www.docjar.org/docs/api/org/springframework/orm/hibernate3/support/OpenSessionInViewFilter.html

По сути передает сессию hibernate и во view, так что можно подгружать необходимые lazy-поля.
Скоро сделаем рассылку со ссылкой на пригласительный билет. Там будет расписана вся необходимая информация (кто, что, где, когда и как добраться). Распечатка пригласительного необязательна, т.к. у нас, как местами в РЖД, действует электронная регистрация и списки будут :).
Думаю, можно и без куки:

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 такое не особо позволяет. Вот логика выбора вариантов (без отдельного варианта для «нет сообщений», но тут это не так уж и важно):

    public static String items(int n, String one, String few, String many, String other) {
        int n_10 = n % 10;
        int n_100 = n % 100;

        if (n_10 == 1 && n_100 != 11) {
            return one;
        }

        if ((n_10 == 2 || n_10 == 3 || n_10 == 4) && !(n_100 == 12 || n_100 == 13 || n_100 == 14)) {
            return few;
        }

        if (n % 10 == 0
                || (n_10 == 5 || n_10 == 6 || n_10 == 7 || n_10 == 8 || n_10 == 9)
                || (n_100 == 11 || n_100 == 12 || n_100 == 13 || n_100 == 14)) {
            return many;
        } else {
            return other;
        }
    }


Т.к. задача стандартная, то хотелось бы увидеть как это будет выглядеть в xslt.
15 сайтов на UMI — это, думаю, больше, чем у 50% (а то и 80%) процентов партнеров UMI. Все-таки, такой опыт достаточен для суждений о системе. Естественно «гуру», которые систему и разрабатывали многое могут сделать и лучше, но вряд ли стоит рассчитывать на это с большинством партнеров…
Я это и имел в виду (udata — тоже протокол), когда говорил, что придется делать свой модуль (если в апи такой функции еще нет). Так уже получаются достаточно страшные (нечитаемые) конструкции (число 4 — это же не будет на реальном сайте константой, а откуда-то берется и еще нужно указать 4 формы (нет сообщений, %s сообщение, %s сообщения, %s сообщений). Ваш пример слишком упрощен, поэтому выглядит более-менее прилично.

PS. На сайте help-dev.umi-cms.ru/ не нашел макроса %content formatNumber%, но вполне верю, что такой может появиться в след. версии (или есть, но не документированный).

Information

Rating
Does not participate
Location
Самара, Самарская обл., Россия
Registered
Activity