[Logo] Neo Framework Forum
  [Search] Busca   [Recent Topics] Tópicos Recentes   [Members]  Lista de Usuários   [Groups] De volta para a página principal 
[Register] Registrar / 
[Login] Entrar 
Algumas Possíveis Melhorias....  XML
Índice dos Fóruns -> NEO RIA
Autor Mensagem
valdecijunior
Equipe
[Avatar]
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.
[Email] [Yahoo!] [MSN]
Igor.Costa
MultiAction
[Avatar]
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.


[Email] [WWW] [Yahoo!] [MSN]
pedro.goncalves
Equipe
[Avatar]
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
[Email] [WWW] [MSN]
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!!!
valdecijunior
Equipe
[Avatar]
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.
[Email] [Yahoo!] [MSN]
pedro.goncalves
Equipe
[Avatar]
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
[Email] [WWW] [MSN]
valdecijunior
Equipe
[Avatar]
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.
[Email] [Yahoo!] [MSN]
 
Índice dos Fóruns -> NEO RIA
Ir para:   
Powered by JForum 2.1.7 © JForum Team