I've struggled with many internal classes to see how generic
components could be achieved,
but after failing to find simple way to pass generic declaration to component.
I found a way to do it from inside the component,
but it works only for components, not for pages...
I'm still looking is there a real bebefit from this...
If this is helpful for you,
I can give you the snippet ...
Davor Hrg
On Wed, Feb 27, 2008 at 1:48 PM, Angelo Chen <[EMAIL PROTECTED]> wrote:
>
> Hi Howard,
>
> This is a very nice feature, in my app, I have many small tables, say 30, so
> to edit those 30 objects I have to create 30 page classes without template,
> that's a big saving. I'd like to save further, is there a way that we can
> create a generic page class that can be called from other pages? if this is
> possible then we save another 30 page classes. if this is not possbile I am
> thinking of 'embedding' the edit class in a main page class, say:
>
> // main page class for applicants
>
> public class AdminApplicant {
>
> // nested page class for the AdminApplicant.tml to call edit objects
>
> public class Edit extends EditPage<Applicant> {
> };
> }
>
> but the "embedded" Edit class is not visible in the AdminApplicant.tml, is
> there a way to make this works?
>
> Thanks,,
>
> A.C.
>
>
>
>
> Howard Lewis Ship wrote:
> >
> > To be more specified,
> >
> > you can define a base class:
> >
> > package com.myapp.base;
> >
> > public class EditPage<T> {
> >
> > @Persist private T _object;
> >
> > public T getObject() { return _object; }
> >
> > public void setObject(T object) { _object = object; }
> >
> > . . .
> > }
> >
> > So you can create a page that can edit an arbitrary object. EditPage
> > will have its own Tapestry template containing, say, a BeanEditForm.
> >
> > Now, you can define a new class:
> >
> > package com.myapp.pages;
> >
> > public class EditAccount extends EditPage<Account>
> > {
> > }
> >
> > EditAccount will inherit logic and template from EditPage.
> >
> > Further, the getObject() and setObject() properties will be bound to
> > the type Account. This takes some doing, as the type of property
> > object of class EditPage is nominally java.lang.Object (due to type
> > erasure). However, Tapestry does a bit of work with reflection to
> > deduce the effective type of the property (Account).
> >
> > This is a very, very high level of reuse ... and once again, we are
> > leveraging Java's type system to help us, rather than traditional Java
> > coding where we spend our time "appeasing" the type system.
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/T5%3A-5.0.10-new-features-tp15528824p15712557.html
>
>
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
