Em Wed, 23 Dec 2009 15:42:20 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
I know... but your CRUD package is not tapestry.
It's a Tapestry extension that I plan to contribute to Tapestry itself
when is good enough (a.k.a. it has unit tests).
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".
If it's possible and easy to do what you want but you don't know how, then
I think we have an issue with the documentation, not with the framework
itself.
The problem is that tapestry.apache.org is static. It can be edited by
the commiters only.
Just post a JIRA and it's added there.
Of course, a more dynamic page would be a nicer solution.
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.
I wrote that because of the @PersistenceContext. That's the only thing,
AFAIK, that would be different from tapestry-hibernate.
JPA2 is new.. but maybe you know that there is a half-finnished module
available.
Yes, I know. :)
All it does is to provide Spring beans as Tapestry services. :)
Not the other way as well(tapestry services as spring beans?) .. ?
Tapestry-Spring supports both.
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>
You can do this in Tapestry too, but not in the template. It goes in
app.properties. From
http://tapestry.apache.org/tapestry5.1/guide/validation.html
The first key checked is formId-fieldId-validatorName-message.
formId: the local component id of the Form component
fieldId: the local component id of the field (TextField, etc.)
validatorName: the name of the validator, i.e., "required" or "minlength"
If there is not message for that key, a second check is made, for
fieldId-validatorName-message.
If that does not match a message, then the built-in default validation
message is used.
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.
I really dislike container-based authentication. I think it should be
implemented by the application.
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..
The only part I can think that can be the same across different ORM
frameworks is transaction handling. And a tapestry-tx package is a dream
of mine.
If I sound like an uninformed troll,
You just sounded like a troll when you made several about why we don't
have more integrations in Tapestry-IoC without writing one. The rest is a
nice discussion. :)
that is because I did not manage
to understand everything good enough. One possibility is that I am
just too dumb,
I guess not. :)
the other one would be that tapestry is quite complex
(what is my whole point above)... (please resist to answer this
question ;-)
Different points of view, different minds, different opinions. Sorry, I
answered your question. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
