Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Eu preciso montar uma lista de coisas ruims no WW, funcionalidades que podem ser melhoradas ou adicionadas.
A lista será enviada para o Patrick da Opensymphony, vocês podem ajudar a fazer a lista por favor?
- O que vcs não gostam no WW?
- O que o WW poderia melhorar?
- Que funcionalidades vc gostaria que ver no WW?
Tem a questão da injeção de parâmetros em cascata. Tipo, se você quer acessar um objeto de negócio a partir da view, você cria um getObjeto(), para obter seus dados e montar o html. Mas, se este objeto já existir (o get retornar alguma coisa) na hora da recepção da requisição (se ele for null, e setado apenas durante a execução da action não tem problema), alguém pode passar uma URL com um parâmetro do tipo &objeto.atrbuto=x e alterar o valor do atributo do objeto. É um equivalente ao SQL injection, só que orientado a objetos...
Uma feature legal seria um jeito de especificar, *opcionalmente*, quais as propriedades da classe que são parâmetros e quais são objetos para serem expostos aos templates, para a renderização da visualização, talvez usando annotations. Mas isso se for possível fazer isso como um módulo independente, para não comprometer a compatibilidade. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Realmente, essa SQL Injection Orientada a Objetos que o Ronald falou encomoda um bocado. Principalmente se estiver usando os objetos de negócio do Prevayler nas views.
Talvez algum módulo "ou conjunto de interceptors" que cuidem da segurança de aplicações, algo como "autenticação e autorização", um módulo talvez ligado ao xwork para que seja criado um sistema mais seguro do que os tradicionais interceptors que testam se a sessão está != null...
Precisaria elaborar melhor esta questão, mas a minha primeira sugestão seria justamente trabalhar nisso Ps: O Acegi seria uma solução a ser usada como espelho, porém algo mais simples e de fácil configuração, bem o oposto do acegi _________________Sugestão de Livros
é acegi _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Field injection é complicado mesmo, mas se for parar configura-los acho que isso deve algo por action e não por class. Assim, actions apontando para o mesmo metodo poderiam decidir de maneira diferente que campos não podem ser adicionados. Agora, como o WW usa OGNL para realizar esse tipo de operação, talvez eles precisem extender o suporte a OGNL para fazer algumas dessas coisas.
Uma coisa que sempre me preocupa é a ordem dos interceptors. Lembro que boa parte dos problemas que tive com o WW estava relacionado a ordem dos interceptors, especialmente quando eu lidei com modeldriven. Apesar de achar a abordagem atual boa, talvez isso pudesse ser revisado e especialmente melhor documentado para explicitar a dependencia entre os interceptors, etc. No começo eu tambem tinha problemas de layout com as ui tags, tive que alterar boa parte dos templates para evitar a criação de tabelas. Isso não chega a ser um problema, mas a documentação é pessima nesse ponto.
Editado: se for usar algum mecanismo de autenticação, melhor se ele puder ser plugado sem muitas broncas. Acho que dá para fazer isso no proprio XWork ou no webwor.properties, basta aplicar algumas restrições no componente que realiza a autenticação. A configuração desse componente vai depender dele proprio e o WW proveria algumas implementações out-of-the-box.
Alguns interceptors bastante uteis poderiam ser usados tambem, como um para "copiar" os dados da stack para algum contexto (request, session, etc) e facilitar o acesso as propriedades dentro da view.
Uma coisa que sempre me preocupa é a ordem dos interceptors. Lembro que boa parte dos problemas que tive com o WW estava relacionado a ordem dos interceptors, especialmente quando eu lidei com modeldriven. Apesar de achar a abordagem atual boa, talvez isso pudesse ser revisado e especialmente melhor documentado para explicitar a dependencia entre os interceptors
Sim... a ordem é um problema... até pegar o jeito da coisa demora...
jack_-_ganzha
Alguns interceptors bastante uteis poderiam ser usados tambem, como um para "copiar" os dados da stack para algum contexto (request, session, etc) e facilitar o acesso as propriedades dentro da view.
Seria interessante poder popular coleções tipadas a partir de uma requisição tambem:
Já precisei fazer isso em um use case "pouco sensato". Como com generics vc pode descobrir que tipo de dado a coleção trata, dava para fazer esse tipo de coisa. Tipar algumas interfaces (como ModelDriven) seria legal tambem. Eu sinceramente não gostaria de anotações para as actions porque, para o WebWork, elas poderiam ficar muito verboragicas.
Claro que um package-info poderia funcionar como uma alternativa, mas aí, qual seria o ganho em relação a xml? Especialmente, não sei como funcionaria o esquema (muito util) de includes tambem. Alguma ideia?
Ricardo, com certeza um melhor suporte ao JasperReports seria bem vindo, coisas simples como a possibilidade de setar qual será o delimitador dos arquivos .csv de vírgula para ponto-e-vírgula. A possibilidade de forçar o download do pdf gerado. A posssibilidade de trabalhar com um Connection...
O Struts tem as tags do XDoclet que já implementam algo parecido. Apesar da idéia do Marcos ser fantástica, não teríamos grandes novidades para quem está vindo do Struts.
Ricardo, com certeza um melhor suporte ao JasperReports seria bem vindo, coisas simples como a possibilidade de setar qual será o delimitador dos arquivos .csv de vírgula para ponto-e-vírgula. A possibilidade de forçar o download do pdf gerado. A posssibilidade de trabalhar com um Connection...
Eu citei um exemplo mais completo para vcs verem como nesse caso fica complicado adotar annotations. Mas, acho que para boa parte dos casos, dava para aproveitar valores default e fazer a coisa mais ou menos assim:
As configurações como stack, global results ficam em um package-info. Bem mais simples, mas, ainda acho verboragico demais.
Se eu entendi bem o que vc disse atualmente isto já é possível.... meio chato mas é. No WW2.1.7 tinha um exemplo: "indexedProperties.jsp".
Uma vez eu adaptei para uma Collection de pessoas e funcionou..
Hum, para popular a coleção durante o submit? Deve ser meio chato mesmo, só consigo imaginar uma maneira de fazer isso com um interceptor meio que forçando a barra. O exemplo está no download do WW? Senão, onde posso dar uma olhada, Ricardo?
Sim, uma para paginação. A maioria das aplicações com algum tipo de busca/listagem precisa de paginação dos dados. Seria legal poder usar isso no WW. Pode até integrar alguma já pronta, mas o ideal seria não precisar buscar "fora" um esquema de paginação. Outra coisa interessante seria colocar uma condição na tag iterator mais ou menos assim:
Ricardo LechetaPosts:91
Olá,
Eu preciso montar uma lista de coisas ruims no WW, funcionalidades que podem ser melhoradas ou adicionadas.
A lista será enviada para o Patrick da Opensymphony, vocês podem ajudar a fazer a lista por favor?
- O que vcs não gostam no WW?
- O que o WW poderia melhorar?
- Que funcionalidades vc gostaria que ver no WW?
obrigado
ronaldtmPosts:2317
Tem a questão da injeção de parâmetros em cascata. Tipo, se você quer acessar um objeto de negócio a partir da view, você cria um getObjeto(), para obter seus dados e montar o html. Mas, se este objeto já existir (o get retornar alguma coisa) na hora da recepção da requisição (se ele for null, e setado apenas durante a execução da action não tem problema), alguém pode passar uma URL com um parâmetro do tipo &objeto.atrbuto=x e alterar o valor do atributo do objeto. É um equivalente ao SQL injection, só que orientado a objetos...
Uma feature legal seria um jeito de especificar, *opcionalmente*, quais as propriedades da classe que são parâmetros e quais são objetos para serem expostos aos templates, para a renderização da visualização, talvez usando annotations. Mas isso se for possível fazer isso como um módulo independente, para não comprometer a compatibilidade.
_________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
vfpampPosts:6098
Realmente, essa SQL Injection Orientada a Objetos que o Ronald falou encomoda um bocado. Principalmente se estiver usando os objetos de negócio do Prevayler nas views.
_________________Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
Ricardo LechetaPosts:91
hum.. legal.
já foi notificado algo similar no JIRA:
http://jira.opensymphony.com/browse/XW-236;jsessionid=CGDCBHCNOOKK?page=history
http://jira.opensymphony.com/browse/XW-231
daltoncamargoPosts:8899
Talvez algum módulo "ou conjunto de interceptors" que cuidem da segurança de aplicações, algo como "autenticação e autorização", um módulo talvez ligado ao xwork para que seja criado um sistema mais seguro do que os tradicionais interceptors que testam se a sessão está != null...
-- 
-- 
Precisaria elaborar melhor esta questão, mas a minha primeira sugestão seria justamente trabalhar nisso
Ps: O Acegi seria uma solução a ser usada como espelho, porém algo mais simples e de fácil configuração, bem o oposto do acegi
_________________Sugestão de Livros
ronaldtmPosts:2317
é acegi
_________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
jack_-_ganzhaPosts:4191
Field injection é complicado mesmo, mas se for parar configura-los acho que isso deve algo por action e não por class. Assim, actions apontando para o mesmo metodo poderiam decidir de maneira diferente que campos não podem ser adicionados. Agora, como o WW usa OGNL para realizar esse tipo de operação, talvez eles precisem extender o suporte a OGNL para fazer algumas dessas coisas.
Uma coisa que sempre me preocupa é a ordem dos interceptors. Lembro que boa parte dos problemas que tive com o WW estava relacionado a ordem dos interceptors, especialmente quando eu lidei com modeldriven. Apesar de achar a abordagem atual boa, talvez isso pudesse ser revisado e especialmente melhor documentado para explicitar a dependencia entre os interceptors, etc. No começo eu tambem tinha problemas de layout com as ui tags, tive que alterar boa parte dos templates para evitar a criação de tabelas. Isso não chega a ser um problema, mas a documentação é pessima nesse ponto.
Editado: se for usar algum mecanismo de autenticação, melhor se ele puder ser plugado sem muitas broncas. Acho que dá para fazer isso no proprio XWork ou no webwor.properties, basta aplicar algumas restrições no componente que realiza a autenticação. A configuração desse componente vai depender dele proprio e o WW proveria algumas implementações out-of-the-box.
Alguns interceptors bastante uteis poderiam ser usados tambem, como um para "copiar" os dados da stack para algum contexto (request, session, etc) e facilitar o acesso as propriedades dentro da view.
valeuz...
_________________Marcos Silva Pereira
Ricardo LechetaPosts:91