On Tue, Jun 18, 2013 at 9:11 AM, Nomen Nomanum <getibi...@outlook.com>wrote:
> Great proposal, @Lava! :) > But for that method MappedConfiguration.override(...) I will have to > include TypeCoercion so that Tapestry exactly knows how to handle with the > following String --> long ( my entity Article has it's @Id positioned on id > field, so HibernateModule.contributeValueEncoderSource() > catches itself on that field ). Any comment on this flow? > The fact you're changing MappedConfiguration.add() to override() doesn't create any additional requirements. I don't think you'll need to include a TypeCoercion for String -> long, because it's probably there already, I just couldn't check. > > > Date: Tue, 18 Jun 2013 10:01:05 +0100 > > Subject: RE: Resolving PersistentClass instances mapping to the same > entity > > From: lance.j...@googlemail.com > > To: users@tapestry.apache.org > > > > Can you guarantee that name is unique and will never change? > > > > If not, you might want to concatenate name and id in your ValueEncoder > and > > ignore the name in the lookup so that old bookmarks and duplicate names > are > > not broken. > > > > As Thiago suggested, use MappedConfiguration.override(...) to override > the > > default encoder contributed by tapestry-hibernate. > > -- Thiago
