Em Wed, 23 Dec 2009 16:22:49 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
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.
I don't know Tapestry-IoC from the inside (yet!), so I don't know how
difficult it would be to provide an injection for @PersistenceContext. It
would be straightforward for @Inject.
Nope, that is the error message only. What I would like to define is
where the message should be rendered.. and control the markup ;-)
This is done by ValidationDecorator. You can implement your own one and
overrid the "DefaultValidationDecorator" contribution to the
MarkupRenderer service. I have not tested yet, though.
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.
Or disable client-side validation entirely. Agreed with the rest.
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)
More freedom, more control, more complex. Quite hard to avoid that.
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.
I cannot speak for the project, but I think Tapestry tries to be a Web
framework, not a full stack. At least not yet. ;)
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 :-)
:)
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.
I was talking about a really generic tapestry-tx that could be used with
any persistence technology, being it backed by relational database or not.
IMHO, using JPA or JDO over a non-relational database loses some of the
benefits of it. I plan to write some projects to run on Google Application
Engine and I'm going to use the low-level API.
tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-)
That's my plan. ;)
--
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
