You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ulrich Stärk <ul...@spielviel.de> on 2009/01/19 11:27:05 UTC
Hibernate relations in BeanEditForm
Hi All,
tapestry-hibernate in combination with the BeanEditForm is great, as it
allows for simple CRUD applications to be written in no time.
Unfortunately it takes quite some manual work to represent relations
like OneToMany, ManyToOne and ManyToMany in your application because
Tapestry doesn't know how to display a given object and how to map this
object to an id.
I suggest to add the following behaviour to Tapestry: When editing an
object with the BeanEditForm that is a Hibernate entity and there is a
reference to another object that is also a Hibernate entity, look for
the type of the relation. If it's OneToMany or ManyToMany, render a
Palette. If it's ManyToOne or OneToOne, render a Select. Then look at
the class of the object at the other end of the relation. It will
already have a an id, use this for the SelectModel/ValueEncoder. For the
display at the user side, use a method that has a special annotation
(this will have to be added) or if the class lacks it, use toString().
What do you think? Am I mispercepting the effort needed to make
Hibernate relations work with the BeanEditForm and is the effort needed
to build the proposed logic thus disproportional? I'm just wondering
because to me this seems to be needed quite frequently but I couldn't
find a JIRA issue for this.
Cheers,
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate relations in BeanEditForm
Posted by Ulrich Stärk <ul...@spielviel.de>.
We can always query the HibernateSessionSource service for the
Configuration and get a PersistentClass from it. From there I believe we
can get all the information we need.
Cheers,
Uli
Alejandro Scandroli schrieb:
> I think this would be quite difficult to implement in
> tapestry-hibernate without parsing hibernate's metadata and storing it
> in some kind of metadata container, which is what Trails is doing.
>
> Alejandro.
>
> On Tue, Jan 20, 2009 at 12:33 AM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> Em Mon, 19 Jan 2009 16:14:01 -0300, Kevin Monceaux <Ke...@rawfeddogs.net>
>> escreveu:
>>
>>> On Wed, 21 Nov 2007, Francois Armand wrote:
>>>
>>>> For now, BeanEditor (or BeanEditForm) is not really aware of collection
>>>> as a property. I think it's in the todo list (T5 still alpha, etc ;)
>> Tapestry 5.0.18 is not alpha nor beta: it's the first stable,
>> ready-for-production release. (at least it's what is written in
>> tapestry.apache.org)
>>
>> Regarding collections, Java generics don't help, as they lose the
>> parameter's info in runtime (erasure). That's why the encoder parameter of
>> the Select component is not required and the same parameter of Palette is
>> required.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> http://www.arsmachina.com.br/thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate relations in BeanEditForm
Posted by Alejandro Scandroli <al...@gmail.com>.
I think this would be quite difficult to implement in
tapestry-hibernate without parsing hibernate's metadata and storing it
in some kind of metadata container, which is what Trails is doing.
Alejandro.
On Tue, Jan 20, 2009 at 12:33 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Mon, 19 Jan 2009 16:14:01 -0300, Kevin Monceaux <Ke...@rawfeddogs.net>
> escreveu:
>
>> On Wed, 21 Nov 2007, Francois Armand wrote:
>>
>>> For now, BeanEditor (or BeanEditForm) is not really aware of collection
>>> as a property. I think it's in the todo list (T5 still alpha, etc ;)
>
> Tapestry 5.0.18 is not alpha nor beta: it's the first stable,
> ready-for-production release. (at least it's what is written in
> tapestry.apache.org)
>
> Regarding collections, Java generics don't help, as they lose the
> parameter's info in runtime (erasure). That's why the encoder parameter of
> the Select component is not required and the same parameter of Palette is
> required.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate relations in BeanEditForm
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 19 Jan 2009 16:14:01 -0300, Kevin Monceaux <Ke...@rawfeddogs.net>
escreveu:
> On Wed, 21 Nov 2007, Francois Armand wrote:
>
>> For now, BeanEditor (or BeanEditForm) is not really aware of collection
>> as a property. I think it's in the todo list (T5 still alpha, etc ;)
Tapestry 5.0.18 is not alpha nor beta: it's the first stable,
ready-for-production release. (at least it's what is written in
tapestry.apache.org)
Regarding collections, Java generics don't help, as they lose the
parameter's info in runtime (erasure). That's why the encoder parameter of
the Select component is not required and the same parameter of Palette is
required.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate relations in BeanEditForm
Posted by Kevin Monceaux <Ke...@RawFedDogs.net>.
On Mon, 19 Jan 2009, Ulrich Stärk wrote:
> I'd still love to see this feature in the Tapestry core.
I'll second that motion. I found a post in 2007 suggesting it was on the
todo list:
On Wed, 21 Nov 2007, Francois Armand wrote:
> For now, BeanEditor (or BeanEditForm) is not really aware of collection
> as a property. I think it's in the todo list (T5 still alpha, etc ;)
It is still on the todo list or has it perhaps been implemented but not
documented?
Kevin
http://www.RawFedDogs.net
http://www.WacoAgilityGroup.org
Bruceville, TX
Si hoc legere scis nimium eruditionis habes.
Longum iter est per praecepta, breve et efficax per exempla!!!
Re: Hibernate relations in BeanEditForm
Posted by Ulrich Stärk <ul...@spielviel.de>.
I'd still love to see this feature in the Tapestry core.
Cheers,
Uli
Kalle Korhonen schrieb:
> This (representing entity relations) is one of the main features of Trails (
> http://www.trailsframework.org/); Trails 2 for T5 is currently in
> development.
>
> Kalle
>
>
> On Mon, Jan 19, 2009 at 2:27 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
>
>> Hi All,
>>
>> tapestry-hibernate in combination with the BeanEditForm is great, as it
>> allows for simple CRUD applications to be written in no time. Unfortunately
>> it takes quite some manual work to represent relations like OneToMany,
>> ManyToOne and ManyToMany in your application because Tapestry doesn't know
>> how to display a given object and how to map this object to an id.
>> I suggest to add the following behaviour to Tapestry: When editing an
>> object with the BeanEditForm that is a Hibernate entity and there is a
>> reference to another object that is also a Hibernate entity, look for the
>> type of the relation. If it's OneToMany or ManyToMany, render a Palette. If
>> it's ManyToOne or OneToOne, render a Select. Then look at the class of the
>> object at the other end of the relation. It will already have a an id, use
>> this for the SelectModel/ValueEncoder. For the display at the user side, use
>> a method that has a special annotation (this will have to be added) or if
>> the class lacks it, use toString().
>>
>> What do you think? Am I mispercepting the effort needed to make Hibernate
>> relations work with the BeanEditForm and is the effort needed to build the
>> proposed logic thus disproportional? I'm just wondering because to me this
>> seems to be needed quite frequently but I couldn't find a JIRA issue for
>> this.
>>
>> Cheers,
>>
>> Uli
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate relations in BeanEditForm
Posted by Kalle Korhonen <ka...@gmail.com>.
This (representing entity relations) is one of the main features of Trails (
http://www.trailsframework.org/); Trails 2 for T5 is currently in
development.
Kalle
On Mon, Jan 19, 2009 at 2:27 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> Hi All,
>
> tapestry-hibernate in combination with the BeanEditForm is great, as it
> allows for simple CRUD applications to be written in no time. Unfortunately
> it takes quite some manual work to represent relations like OneToMany,
> ManyToOne and ManyToMany in your application because Tapestry doesn't know
> how to display a given object and how to map this object to an id.
> I suggest to add the following behaviour to Tapestry: When editing an
> object with the BeanEditForm that is a Hibernate entity and there is a
> reference to another object that is also a Hibernate entity, look for the
> type of the relation. If it's OneToMany or ManyToMany, render a Palette. If
> it's ManyToOne or OneToOne, render a Select. Then look at the class of the
> object at the other end of the relation. It will already have a an id, use
> this for the SelectModel/ValueEncoder. For the display at the user side, use
> a method that has a special annotation (this will have to be added) or if
> the class lacks it, use toString().
>
> What do you think? Am I mispercepting the effort needed to make Hibernate
> relations work with the BeanEditForm and is the effort needed to build the
> proposed logic thus disproportional? I'm just wondering because to me this
> seems to be needed quite frequently but I couldn't find a JIRA issue for
> this.
>
> Cheers,
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>