> I wrote that because of the @PersistenceContext. That's the only thing, > AFAIK, that would be different from tapestry-hibernate.
>From a users perspective, its a matter of injecting EntityManager instead of hibernate's Session. In the module itself there are more changes. > 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. Nope, that is the error message only. What I would like to define is where the message should be rendered.. and control the markup ;-) Right now, the client-side validation is kind of a "blackbox". It renders its bubbles with the messages... but if you don't want to have these bubbles but your own markup, you need to do things like override services you never heard about. As said before, need to look at the ValidationDecorator again, but my feeling still is that this is not as easy as it should be. I really want to be able to define where my client-side error messages should appear inside the template (very important: how the markup should look like) > I really dislike container-based authentication. I think it should be > implemented by the application. I don't like it as well - but tapestry should provide an alternative. Maybe the question is if tapestry wants to be a full-stack framework or just deliver some building blocks. For being a full-stack framework, there is not enough functionality available. To just provide building blocks, it dictates too much (javascript library, markup, and so on). Of course this is just my feeling. And don't get me wrong: I really like tapestry and hava already built some projects with it. My reason for all this complaining is just to make it even better :-) > 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. Different ORM frameworks do share much more in common: see JPA2 for what is standardized between them. For other persistence solutions (like OODBMs, Google BigTable, HBase and so on) it gets more difficult... but JDO tries to provide a standard for all persistence needings. tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-) Piero --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
