Autor |
Mensagem |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 10/09/2007 19:46:18
|
valdecijunior
Equipe
Membro desde: 23/06/2007 11:56:42
Mensagens: 24
Localização: Vitoria da Conquista - Ba
Offline
|
Fala Pedro... vou inaugurar o fórum hehehe...
Seguinte, gostaria de discutir contigo a possibilidade de fazer algumas melhorias no código do Neo de modo a facilitar a manutenção e principalmente a extensão do código, tornando mais fácil, inclusive, a implementação do NeoRIA.
Já vi alguns pontos onde, na minha opinião, poderia haver alterações... mas como estou alterando diretamente o código para im0plementar algumas Widgets (acredito que igor tenha te falado) um ponto que sempre me incomoda é a classe InputTag. Porque?
1. A classe é muito grande. Só o método doComponent() possui mais de 350 linhas. A manutenção fica muito difícil...
2. Existem tantos if's quanto linhas. A legibilidade fica extremamente prejudicada.
3. Excesso de responsabilidade. Na minha opinião o problema central da classe (vou explicar porque...)
Como disse acredito que essa classe faz mais do que deveria... eu acho que a responsabilidade de criar/inicializar cada tipo de input deveria ser realizada por classes auxiliares. A InputTag ficaria responsável apenas para identificar qual o tipo de Input a ser renderizado e delegaria a responsabilidade de criá-lo a uma classe específica. Tem uma série de recursos de OO que poderiam ser utilizados para fazer isso. Melhorando esse ponto, conseqüentemente todos os outros problemas seriam resolvidos visto que a maior parte do código seria movido pra essas classes.
Durante a implementação das Widgets eu cai num problema parecido. Todos os widgets da mootools necessitam de um código JS especifico para inicializá-lo além disso alguns como o datePicker precisa que seja inicializado já com os id's dos elementos on de ele será aplicado. Imagine aí adicionar todo o código de inicialização de um widget na InputTag!!! Não demoraria e teríamos 5000 linhas de código (rsrs)!!!
Pra resolver o problema fiz o seguinte:
Adicionei um pacote ao Neo (br.com.linkcom.neo.view.widgets[que deve existir apenas no NeoRia]) onde criei uma classe abstrata Widget conforme abaixo:
Code:
public abstract class Widget {
protected List<Object> widgets = new ArrayList<Object>();
public abstract boolean register(Object object);
public abstract String initialize();
}
Aí para cada widget a ser adicioando ao Neo é criada uma classe que o descreve. Veja como ficou o DatePicker:
Code:
public class DatePicker extends Widget {
@Override
public String initialize() {
StringBuilder sb = new StringBuilder("");
if (widgets.size() > 0) {
sb.append("<script language='javascript'>\n");
sb.append(" datePickerController.create();\n");
sb.append(" datePickerController.datePickers[\""+ datePickersToString() +"\"];\n");
sb.append("</script>");
}
return sb.toString();
}
@Override
public boolean register(Object object) {
return widgets.add(object.toString());
}
private String datePickersToString() {
StringBuilder sb = new StringBuilder("");
for (Object obj : widgets) {
sb.append(obj.toString());
sb.append(" ");
}
return sb.deleteCharAt(sb.length()-1).toString();
}
}
Por fim criei uma classe RegisterWidgetsTag conforme abaixo:
Code:
public class RegisterWidgetsTag extends BaseTag implements LogicalTag {
private static Map<Object, Widget> widgets = new HashMap<Object, Widget>();
public static void registerWidget(Object object, Class widgetClass) throws IllegalAccessException, InstantiationException {
Widget widget;
if (!widgets.containsKey(object)) {
widget = getRegistredWidget(widgetClass);
if ( widget != null) {
widget.register(object);
return;
}
widget = (Widget) widgetClass.newInstance();
widgets.put(object, widget);
widget.register(object);
}
}
@Override
protected void doComponent() throws Exception {
Set<Object> keySet = widgets.keySet();
for (Object key : keySet) {
getOut().println(widgets.get(key).initialize());
}
widgets.clear();
}
private static Widget getRegistredWidget(Class widgetClass) {
Collection<Widget> widgetList = widgets.values();
for (Widget widget : widgetList) {
if (widget.getClass() == widgetClass)
return widget;
}
return null;
}
}
e o código que eu utilizo na InputTag para registrar o datePicker é apenas Code:
RegisterWidgetsTag.registerWidget(name, DatePicker.class);
Observe que da forma como implementei (qualquer semelhança com o PropertyEditor não é mera coincidência rsrsrs) um widget só é registrado uma única vez, mesmo que exista mais de um na página (dois datePicker's por exemplo). Foi uma solução simples, que inclusive pode ser melhorada, mas que já traz um benefício significativo.
Gostaria de sua opinião, pois estou disposto modificar a InputTag reimplementando-a numa abordagem "mais OO". Nessa alteração poderíamos já fazer alguma coisa que facilitasse a extensão das Tags pelo NeoRia (o método includeJspTemplate() por exemplo).
Então é isso... desculpe pelo tópico imenso!!! Fique à vontade pra me corrigir caso esteja equivocado....
vlw
|
Valdeci Junior
MasterSoft Sistemas Ltda.
 |
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 10/09/2007 19:52:58
|
Igor.Costa
MultiAction
Membro desde: 22/06/2007 15:13:22
Mensagens: 79
Localização: Vitória da Conquista - BA
Offline
|
eu gostei do eskema de valdeci ai, principalmente para o caso onde se tem mais de um widget do mesmo tipo numa página. O código gerado fica mais limpo.
|
Igor Costa
MasterSoft Sistemas Ltda.
 |
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 10/09/2007 23:23:37
|
pedro.goncalves
Equipe
Membro desde: 17/04/2007 16:12:20
Mensagens: 539
Localização: Belo Horizonte - MG
Offline
|
Eu gostei!! e por minha parte está aprovado!!!
Valdeci.. a input tag é um sério problema a um tempo bacana já.
Vou conversar com o rógel, e vamos melhorar ela, e fazer com que fique mais fácil de implementar outros tipos. só que temos medo, pois como você disse possui muitas coisas.. e muitas funcionalidades ao mesmo tempo.
Amanhã te dou um retorno no que posso fazer.. qualquer coisa você me ajuda...
até!
|
Pedro Gonçalves
http://pedrogoncalves.com.br
 |
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 11/09/2007 21:38:31
|
rogel.garcia
Xiita
Membro desde: 17/04/2007 16:35:03
Mensagens: 275
Offline
|
Muito bom valdeci.. era justamente esse tipo de reestruturação que eu falei em outro tópico ser necessária antes de qualquer upgrade do framework...
Junto com a reestruturação do InputTag, também tem a reestruturaçao do PropertyTag (o template acaba ficando muito grande)..
E a reestruturaçao da renderizaçao do dataGrid pra utilizar mais templates. (o código dos TDs hoje é gerado dentro da tag)
Acho que são os pontos principais a serem modificados (primariamente)
Tem que dar umas refatorações 'EXTRACT METHOD' no InputTag mesmo...
Mais futuramente a tag BaseTag também precisará de uma organização.. tem mil métodos dentro dela...
Muito bom trabalho valdeci!!!
|
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 12/09/2007 17:36:01
|
valdecijunior
Equipe
Membro desde: 23/06/2007 11:56:42
Mensagens: 24
Localização: Vitoria da Conquista - Ba
Offline
|
vlw pessoal.. obrigado!!!
como disse, se vocês precisarem, estou disposto a colaborar nessa reestruturação...
vlw t+
|
Valdeci Junior
MasterSoft Sistemas Ltda.
 |
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 13/09/2007 08:05:55
|
pedro.goncalves
Equipe
Membro desde: 17/04/2007 16:12:20
Mensagens: 539
Localização: Belo Horizonte - MG
Offline
|
Valdeci.. se tiver como, hoje a noite vamos começar esta reestruturação, você pode?
até!
|
Pedro Gonçalves
http://pedrogoncalves.com.br
 |
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 13/09/2007 13:38:59
|
valdecijunior
Equipe
Membro desde: 23/06/2007 11:56:42
Mensagens: 24
Localização: Vitoria da Conquista - Ba
Offline
|
Hoje a noite eu tenho um compromisso.... Só se for bem mais tarde!!!! Mas faz o seguinte... defina as tarefas no JIRA que eu vou dando uma olhada e aí podemos discutir depois...
vlw
|
Valdeci Junior
MasterSoft Sistemas Ltda.
 |
|
 |
|