Re: [T5] Something like GORM for Tapestry?
I'm not a big fan of DAO's either and when I saw this it got me
thinking so I tried the following. The methods/queries are not as
dynamic since it requires an Interface but Eclipse will write that for
you and after that you get code completion, type checking etc.
The parser is about as dumb as it gets and only supports query by all
or narrow by 1 property name. That could be improved. There is not
much error checking either.
public interface Query {
public List all(Class clazz);
public List name(Class clazz, String name);
}
public class QueryProxyHibernate implements InvocationHandler {
Logger log;
Session session;
public QueryProxyHibernate(Logger serviceLog, Session session) {
this.log = serviceLog;
this.session = session;
}
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
log.debug(method.getName());
if ( method.getName().equals("all")) {
return session.createCriteria((Class) args[0]).list();
}
return session.createCriteria((Class) args[0])
.add( Restrictions.eq(method.getName(), args[1]))
.list();
}
}
In my appModule
public static Query buildQuery(Logger serviceLog, Session session)
{
Class[] proxyInterfaces = new Class[] { Query.class };
Query query = (Query)
Proxy.newProxyInstance(Query.class.getClassLoader(),
proxyInterfaces,
new QueryProxyHibernate(serviceLog,session));
return query;
}
To use
@Inject
private Query query;
public List getPeople() {
return query.name(Person.class, "Barry");
}
public List getProducts() {
return query.all(Product.class);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Something like GORM for Tapestry?
> I usually code against DAOs configured in Spring. GORMs main advantage IMO > is the uncluttered and quickly readable configuration of the domain classes > and relations. The dynamic finders are definitely helpful for smaller scale > admin type apps and for quick testing. For more complex apps there is > usually no way to avoid a dedicated business/service layer or at least > complex DAOs. Of course if you take only GORM part out of Grails that is all you get DAO that is simple to use. Grails however has services that are could and should be used to do the access (never mind the controllers filled with DA code - although it demonstrates the possibility no sane person, I hope, would do it for a production ready application) > Using Hibernate sessions directly in the page-code is IMO also more a thing > of prototyping and proof of concept. Especially if you don't know in advance > if there will be a change of data-access technology in the future, e.g. to > TopLink, Ibatis or maybe even to an object database like db4o. In these > cases GORM is of course no help either as long as it's tightly tied to > Hibernate. GORM itself is not tied to Hibernate (except maybe for queries which are HQL and H stands for Hibernate). The problem there is that the only implementation provided is done with Hibernate and probably will be for at least a while. And that kind of sucks and I think Grails team knows about it :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Something like GORM for Tapestry?
Thanks for your helpful answers.
I usually code against DAOs configured in Spring. GORMs main advantage IMO
is the uncluttered and quickly readable configuration of the domain classes
and relations. The dynamic finders are definitely helpful for smaller scale
admin type apps and for quick testing. For more complex apps there is
usually no way to avoid a dedicated business/service layer or at least
complex DAOs.
Using Hibernate sessions directly in the page-code is IMO also more a thing
of prototyping and proof of concept. Especially if you don't know in advance
if there will be a change of data-access technology in the future, e.g. to
TopLink, Ibatis or maybe even to an object database like db4o. In these
cases GORM is of course no help either as long as it's tightly tied to
Hibernate.
In short: I obviously did a quick shot at a distant dream of easy
data-access and failed :)
Regards,
Otho
2008/11/11 Alex Kotchnev <[EMAIL PROTECTED]>
> Otho,
> Indeed, as Alex mentioned my attempt at Tapestry & Grails integration
> never went much further than he pointed out. Also, it must be noted that at
> the time I was trying to use Tapestry 4.1, so most of what you'll see on
> that blog post doesn't apply to T5.
>
> The bottom line on that attempt was that there is way too much overlap
> between Tapestry and Grails in order for them to make a good marriage. My
> motivation was exactly as Otho mentioned : I very much preferred Tapestry
> as
> the front end and I was completely enchanted by GORM on the back end.
> However, especially w/ T5 both Grails and T5 provide :
> * a nice and integrated way of creating UIs
> * An IoC / DI container
> * Integration w/ Hibernate back end.
>
> Now, if you decide to replace the default Grails controllers w/ T5, you
> would lose all the nice integration that both Grails provide and you'll
> have
> to do a whole bunch of work to make T5+Grails work just as good as either
> just Grails or just T5. Additionally, if replace the Grails controllers w/
> T5, you'll lose ALL nice frontend integration (e.g. plugins, etc).
>
> A potentially better approach would be to plug the GORM back end into T5
> (which is partially reverse to what I did there). That approach could still
> be viable, if the Grails project does separate GORM (as they've mentioned
> that they have plans to do).
>
> On the flip side, after working on a couple of Grails projects for the
> last year, after you get beyond the basic UI that you can quickly set up w/
> Grails, as nice as GORM is it really doesn't help you all that much. The
> equivalent of Foo.findAllByBarAndBaz('bar','baz') is just marginally
> shorter
> than session.createQuery("from Foo f where f.bar=:bar and
> f.baz=:baz").setParameter('bar','bar').setParameter('baz','baz').list() ,
> and gives you pretty much the same deal (if you really dislike DAOs). For
> the simple queries the Grails approach is nice; however, I often found
> myself just going back to HQL quite often (which pretty much obliterates
> any
> advantage of dynamic methods) as in Foo.query("from Foo f where f.bar=:bar
> and f.baz=:baz", [bar:'bar',baz:'baz']).
>
> I do recall a while back Howard blogged about using Groovy classes as the
> page or component classes, which after compilation end up as Java classes.
> Now, if / when standalone GORM releases, that might be the best way to go
> (although, the last time I saw it, it still required Grails like directory
> layout, which would just be a bitch to integrate into T5).
>
> Cheers,
>
> Alex Kotchnev
>
> On Fri, Nov 7, 2008 at 8:51 AM, Alex Shneyderman <[EMAIL PROTECTED]
> >wrote:
>
> > On Fri, Nov 7, 2008 at 1:35 PM, Otho <[EMAIL PROTECTED]> wrote:
> > > Yes of course, but Tapestry and Groovy integrate quite well.
> >
> > yes I recall an attempt I do not know if anything beyond basic page
> > was ever implemented.
> >
> >
> >
> http://www.troymaxventures.com/2007/08/grails-tapestry-grapestry-part-1-of-n.html
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
Re: [T5] Something like GORM for Tapestry?
Otho,
Indeed, as Alex mentioned my attempt at Tapestry & Grails integration
never went much further than he pointed out. Also, it must be noted that at
the time I was trying to use Tapestry 4.1, so most of what you'll see on
that blog post doesn't apply to T5.
The bottom line on that attempt was that there is way too much overlap
between Tapestry and Grails in order for them to make a good marriage. My
motivation was exactly as Otho mentioned : I very much preferred Tapestry as
the front end and I was completely enchanted by GORM on the back end.
However, especially w/ T5 both Grails and T5 provide :
* a nice and integrated way of creating UIs
* An IoC / DI container
* Integration w/ Hibernate back end.
Now, if you decide to replace the default Grails controllers w/ T5, you
would lose all the nice integration that both Grails provide and you'll have
to do a whole bunch of work to make T5+Grails work just as good as either
just Grails or just T5. Additionally, if replace the Grails controllers w/
T5, you'll lose ALL nice frontend integration (e.g. plugins, etc).
A potentially better approach would be to plug the GORM back end into T5
(which is partially reverse to what I did there). That approach could still
be viable, if the Grails project does separate GORM (as they've mentioned
that they have plans to do).
On the flip side, after working on a couple of Grails projects for the
last year, after you get beyond the basic UI that you can quickly set up w/
Grails, as nice as GORM is it really doesn't help you all that much. The
equivalent of Foo.findAllByBarAndBaz('bar','baz') is just marginally shorter
than session.createQuery("from Foo f where f.bar=:bar and
f.baz=:baz").setParameter('bar','bar').setParameter('baz','baz').list() ,
and gives you pretty much the same deal (if you really dislike DAOs). For
the simple queries the Grails approach is nice; however, I often found
myself just going back to HQL quite often (which pretty much obliterates any
advantage of dynamic methods) as in Foo.query("from Foo f where f.bar=:bar
and f.baz=:baz", [bar:'bar',baz:'baz']).
I do recall a while back Howard blogged about using Groovy classes as the
page or component classes, which after compilation end up as Java classes.
Now, if / when standalone GORM releases, that might be the best way to go
(although, the last time I saw it, it still required Grails like directory
layout, which would just be a bitch to integrate into T5).
Cheers,
Alex Kotchnev
On Fri, Nov 7, 2008 at 8:51 AM, Alex Shneyderman <[EMAIL PROTECTED]>wrote:
> On Fri, Nov 7, 2008 at 1:35 PM, Otho <[EMAIL PROTECTED]> wrote:
> > Yes of course, but Tapestry and Groovy integrate quite well.
>
> yes I recall an attempt I do not know if anything beyond basic page
> was ever implemented.
>
>
> http://www.troymaxventures.com/2007/08/grails-tapestry-grapestry-part-1-of-n.html
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: [T5] Something like GORM for Tapestry?
On Fri, Nov 7, 2008 at 1:35 PM, Otho <[EMAIL PROTECTED]> wrote: > Yes of course, but Tapestry and Groovy integrate quite well. yes I recall an attempt I do not know if anything beyond basic page was ever implemented. http://www.troymaxventures.com/2007/08/grails-tapestry-grapestry-part-1-of-n.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Something like GORM for Tapestry?
Yes of course, but Tapestry and Groovy integrate quite well. You don't have to use all Java for everything. 2008/11/7 Alex Shneyderman <[EMAIL PROTECTED]> > > That is not the same, since you don't only have the AND operator at hand. > > > > def books = Book.findAllByPublisheddateBetween(lastyear, today) > > You do realize that what you are asking is not possible given that impl > language is Java (for Tapestry based projects)? > > So DAO's your friend. If you like GORM write a generator that will > pre-generate > most of those nifty dynamic methods GORM has with your DAO. > > Alex. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [T5] Something like GORM for Tapestry?
> That is not the same, since you don't only have the AND operator at hand. > > def books = Book.findAllByPublisheddateBetween(lastyear, today) You do realize that what you are asking is not possible given that impl language is Java (for Tapestry based projects)? So DAO's your friend. If you like GORM write a generator that will pre-generate most of those nifty dynamic methods GORM has with your DAO. Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Something like GORM for Tapestry?
Yes, that would be a nice option, but realistically my skill-level just isn't high enough and my time too sparse to do an integration myself and keep it up to date with Tapestry releases. Regards, Otho
Re: [T5] Something like GORM for Tapestry?
Otho, don't forget that Grails allows you to use alternative view rendering
technologies on top of GORM. So, maybe you should be looking for some kind
of Tapestry - Grails integration.
On Fri, Nov 7, 2008 at 8:50 AM, Otho <[EMAIL PROTECTED]> wrote:
> That is not the same, since you don't only have the AND operator at hand.
>
> def books = Book.findAllByPublisheddateBetween(lastyear, today)
>
> with lastyear and today being Date instances is also possible and a lot
> more.
>
> Sure it is possible to construct queries from arbitrary length method
> calls.
> But in the above example there would be much to do in analyzing and it
> doesn't help readybility either.
>
> But of course, something like this in Java is probably out of the way.
>
> Maybe something along the lines of
>
> GenericDao bookDao = new GenericDao(Book.class).
>
> List books = dao.findAllBy("publishedDate").between(Date.class,
> lastYear, today);
>
> would be possible.
>
> Regards,
> Otho
>
Re: [T5] Something like GORM for Tapestry?
That is not the same, since you don't only have the AND operator at hand.
def books = Book.findAllByPublisheddateBetween(lastyear, today)
with lastyear and today being Date instances is also possible and a lot
more.
Sure it is possible to construct queries from arbitrary length method calls.
But in the above example there would be much to do in analyzing and it
doesn't help readybility either.
But of course, something like this in Java is probably out of the way.
Maybe something along the lines of
GenericDao bookDao = new GenericDao(Book.class).
List books = dao.findAllBy("publishedDate").between(Date.class,
lastYear, today);
would be possible.
Regards,
Otho
Re: [T5] Something like GORM for Tapestry?
sorry no. But we use JDO/JPA and we have helper methods that look much
like that, but not as concise.. but really easy to create a HQL, JDOQL,
JPQL from a method like this:
List books = dao.findByFields( Book.class, "firstname", "Howard
Lewis", "lastname", "Ship" );
Otho wrote:
Hi all,
I am just in the process of deciding which framework to use for an internal
business app.
The choices are spring rcp, tap5 and grails. The latter mainly because of
the really nifty ORM. Especially the dynamic finders are neat, since they
are readable and make daos redundant in most cases. The UI part is - for my
personal taste - much better in Tap5.
With hibernate integrarion already there. Is there something in the pipeline
which would resemble dynamic finders in GORM?
In case the concept is unknown: Entity classes in grails (groovy) are
dynamically instrumented so that I could for example just write:
def books = Book.findByAuthorFirstnameAndLastname("Howard Lewis", "Ship")
and would get the List of books with a backing sql along the lines of
Select * from book key join author where author.firstname ="Howard Lewis"
and author.lastname="Ship"<<
Regards,
Otho
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[T5] Something like GORM for Tapestry?
Hi all,
I am just in the process of deciding which framework to use for an internal
business app.
The choices are spring rcp, tap5 and grails. The latter mainly because of
the really nifty ORM. Especially the dynamic finders are neat, since they
are readable and make daos redundant in most cases. The UI part is - for my
personal taste - much better in Tap5.
With hibernate integrarion already there. Is there something in the pipeline
which would resemble dynamic finders in GORM?
In case the concept is unknown: Entity classes in grails (groovy) are
dynamically instrumented so that I could for example just write:
def books = Book.findByAuthorFirstnameAndLastname("Howard Lewis", "Ship")
and would get the List of books with a backing sql along the lines of
>>Select * from book key join author where author.firstname ="Howard Lewis"
and author.lastname="Ship"<<
Regards,
Otho
