- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
/**
* @param loginName
* @return
* This method is create a LoginName as Input data
*/
public String getLoginName(String loginName)
{
String userQuery="select u.LoginName from User u";
Recordset rs_user=null;
rs_user = CustomExternalServiceImplUtil.getInstance().executeQuery(userQuery);
List<String> userList = new ArrayList<String>();
while(rs_user.moveNext()){
userList.add(rs_user.valueFromIndex(0).toString());
}
int i=1;
String result = loginName;
for(int j=0; j < userList.size(); j++){
if(userList.get(j).equals(result))
{
result = loginName+i++;
j=0;
}
}
return result;
}
Рефаткоринг чужого кода. Минут пять втуплял, что же тут вообще делается. Еще столько же придумывал, как же это привести в божеский вид с сохранением прежней функциональности.
Follow us!
2. использовать уточнение where
Странно, что не CustomExternalServiceImplUtilFactoryProv ider.getInstance().getCustomExternalServ iceImplUtilFactory().createCustomExterna lServiceImplUtil()
Вообще, конечно, мне непонятно, зачем использовать Recordset, когда в JPA есть удобные getResultList и getSingleResult.
А ещё лучше использовать QueryDSL и не хранить запросы строками.
String userQuery="select u.LoginName from User u";
Это что, не JPQL?
В JPA 2 есть Criteria API, хотя критерии Hibernate мне кажутся более простыми
QueryDSL значительно удобнее. И естественным синтаксисом, и отделением параметров запроса от реализации.
Очень надо такое счастье. Guice + Guice-Persist наше всё.
1.1. поэтому можно писать класс как угодно, наследовать от чего угодно, и использовать повторно, тестировать без поднятия фреймворка, нет конфликтов имен через наследуемые классы и интерфейсы
1.2. Dependency Injection через аннотации вместо явного управления
1.3. если что-то поменялось, ничего не надо переименовывать - достаточно изменить аннотацию
2. идеология компонентов (компонент=1 класс + 1 шаблон)
2.1 возможность держать всё, относящееся к компоненту (класс, шаблон, ресурсы) в одной папке, а не разворачивать всю глубину соседнего дерева templates, resources или assets
2.2. запросто локализуемые ресурсы (достаточно добавить префикс локали к имени)
2.3. инстанс класса на сессию (для каждого пользователя свои поля класса)
2.4. в режиме разработки нет необходимости перезапускать аппликацию, изменения применяются сразу же
3. язык шаблонов: шаблон представляет из себя xml-файл без строгой схемы, фреймворк реагирует только на теги и аттрибуты в собственном неймспейсе, а точнее - каждый такой тег представляет собой компонент со своими событиями; аттрибуты приходят в обработчик после байндинга как параметры метода.
3.1. поэтому шаблоны выглядят очень просто, шаблон не устрашает всякими проверками
3.2. шаблон пассивен (код не включишь)
3.3. шаблон можно отдать даже посредственному верстуну, не слыша его ворчаний по поводу непонятного кода в шаблонах
3.4. даже в визуалках нет такой каши, как в Smarty-подобных шаблонах
4. нативная интеграция JPA, Hibernate, Spring, Acegi и др.
5. сборка через Maven
6. Дока в порядке, фреймворк учится за 5 минут, хорошее сообщество
может, кое-что и упустил, но это важные свойства для меня, как разработчика.
На работе суровый JSF 1.2 =(
разве же ResourceBundle сам понимает, что, если мы указали файл flag.jpg, то, если текущий язык русский, то сначала искать flag_ru_RU.jpg, потом flag_ru.jpg, потом flag_en.jpg, а потом уж flag.jpg? кажется, нужно этот механизм писать самому - в тапестри это поведение по умолчанию
кстати, в альфа-версии 5.3 там уже появилось еще одно измерение ресурсов, называемое skin или theme - c той же лёгкостью можно для тех же компонентов создать мобильную версию, например, не дублируя код.
Правда, есть опасность, что, если тапестри понравился, потом начинаешь плеваться от всех других фреймов =(
1. раньше тапестри был довольно прожорлив (128М котенку не хватало, нужно было 300-400). Это было в версии 5.0, ща вроде бы получше с этим
2. в режиме разработки раньше котенок очень часто падал с OutOfMemoryError: PermGen space - это пофиксили в версии 5.2
3. не нашел никакой CMS на тапестри, только фреймворк
4. АБСОЛЮТНО НИКАКОЙ кодогенерации, всё пишем исключительно ручками :( даже в Playframework это есть...
5. хорошая поддержка IDE Idea и Netbeans, практически из коробки, а вот мой любимый Eclipse обошли - первоначальная настройка похожа на танцы с бубном - поэтому для новых проектов клонирую самодельный helloworld
1. в Tapestry javascript придётся писать самому, нет его генерации на основе кода Java. Зато благодаря стандартным компонентам, это придётся делать не так часто
2. шаблоны - строго XML, а не HTML
3. нет понятия наследования разметки
3. не надо расширять стандартные базовые компоненты (хотя - можно), вся логика работы строится по аннотациям, либо по соглашениям именования
4. Tapestry IoC есть предлагает и свои, и возможность создавать т.н. сервисы - невизуальные компоненты, к которым можно обращаться из любого места
5. Tapestry много заимствовал из AOP - есть декораторы (теперь рекомендуются к использованию т.н. "советчики"), с помощью которых можно расширить или заместить, а точнее, обернуть, любой метод или сервис. В Wicket я такого не нашел
6. Помимо компонентов, есть возможность создавать т.н. "примеси"(mixins) - фичи, которые могут быть использованы в любом компоненте - например, что бы при нажатии на ссылку или кнопку выдавалось подтверждение. Есть ли миксины в Викете? не слышал
7. Склейка жабаскриптов и стилей в один файл, хотя на каждый компонент может быть привязаны свои маленькие кусочки через аннотации.
8. Ах да, к недостаткам Tapestry: он для клиентской части использует Prototype+Scriptalicious, поэтому на данный момент JQuery можно использовать только в режиме noConflict. Однако, Говард обещал сделать абстрактный слой, который будет работать с любым js-фреймворком - и действительно, в SVN появились таковые наработки, они будут в стабильной 5.3 версии
вообще, пишут вот что: https://cwiki.apache.org/WICKET/for-tapestry-users.html
1. шаблонизатор там только Smarty-подобный
2. stateless-идеология напоминает скорее PHP, нет удобства связаннного в постоянном кручении процесса аппликации...
Фиксед?