> Select models out of beans could be improved. My Tapestry CRUD package has a > solution for that.
I know... but your CRUD package is not tapestry. > You're talking about a snapshot. This behaviour was changed and now > everything in the context is allowed. Hey.. this was no complain, you asked where documentation could be improved ;-) >> In the backend, it gets more complicated: contributing services, >> decorating services, overriding services... > > I don't think they're complicated. That's your oppinion... my feeling is the opposite. On its own, these things are simple - but in context of a complex framework like tapestry, its hard to get the "big picture". >> You should know I've tried ;-) BTW the libraries are spread all over >> the web (google code, kenai, github, tap360..). > > There are links to them in http://tapestry.apache.org/. The problem is that tapestry.apache.org is static. It can be edited by the commiters only. My feeling is that this forces the community to a single place: the mailing lists. I am not sure if this is enough to build an opensource community around a framework like tapestry. Of course there is the wiki - but it is "hidden" behind lots of menu entries. > CDI and JPA were released few weeks ago and they were mostly written to be > used inside an EJB container. Implementing CDI is not a piece of cake. JPA is available since over 3 years. And I disagree: it is not mainly written to be used inside an EJB container. JPA2 is new.. but maybe you know that there is a half-finnished module available. > All it does is to provide Spring beans as Tapestry services. :) Not the other way as well(tapestry services as spring beans?) .. ? > You're changing the output generated by some. Try to do the same in another > framework. ;) The documentation could mention it, of course. In other frameworks the output is not that static... and such basic things like where to add the error messages is easy to change. Take Struts2 for an example: <s:error for="fieldName">Error message for Field</s:error> > There are many ways of modeling and implementing authentication and > authorization, so I think it's not a Tapestry responsibility. I think it is - security is something needed by the majority of webapps. Tapestry wants to be my web framework - so why doesn't it help me? Using container based authentication is not possible. Its hard for newbies to get around this. Not more and not less. > Besides the proxy issue, you're wrong: it wouldn't be difficult to integrate > with Tapestry-Hibernate now it would be hard to something that would work > with other > persistence options. I was not aware of the proxy issue, but I was right that it can't be too easy. Anyway, IMHO we should need to think about a more general way of handling persistence. ORMs (aka JPA and Hibernate) are just one part of the persistence arena.. > I strongly suggest you to not make bold statements about frameworks you > don't know very well. ;) It makes you sound like an uninformed troll, but I > know you're not one, as you made some very good points in this discussion. If I sound like an uninformed troll, that is because I did not manage to understand everything good enough. One possibility is that I am just too dumb, the other one would be that tapestry is quite complex (what is my whole point above)... (please resist to answer this question ;-) Piero --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
