You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bill Holloway <bi...@gmail.com> on 2007/06/26 04:14:21 UTC
T5: Generic page classes with beaneditform
I have a Widget base entity extended by several concrete product
entities. I have
public class <T extends Widget> EditWidgetPage
{
...
@Persist
public Long _someWidgetId;
public T _someWidget;
// normal setters / getters
void onActivate (long id)
{
_someWidgetId = id;
_someWidget = _dao.get (id); // gets right subtype of Widget.
Generics. Tested.
}
// onPassivate as per usual pattern.
void onActionFromEditForm ()
{
_dao.saveOrUpdate (_someWidget);
}
}
The page for this just uses a bean edit form, nothing else:
object="someWidget". The saveOrUpdate call complains that someWidget
is of type Widget rather than the subclass it's instantiated to be.
Any thoughts?
bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Generic page classes with beaneditform
Posted by Jun Tsai <ju...@gmail.com>.
wish Jesse to fix the bug in T5.
Jun Tsai
2007/6/26, Jesse Kuhnert <jk...@gmail.com>:
>
> I don't know if this helps or not, but I got generics working in a very
> limited way with 4.1.x in that I do all the type lookup work
> manually...(this probably won't work for this use case but thought I'd
> throw
> it out just in case it does, even this breaks down in many places)
>
>
> http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/enhance/GenericsMethodSignatureImpl.java?view=markup
>
> http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/enhance/GenericsClassInspectorImpl.java?view=markup
>
> On 6/26/07, Francois Armand <fa...@linagora.com> wrote:
> >
> > Francois Armand wrote:
> > > Actually, it's not really an acceptable solution, but the sole
> > > workaround I know (if somebody as another idea, I would be glad to use
> > > it).
> > Well, this sentence is not true.
> > You may ask users to implement a "factory" interface for Class they
> > intend to use as parameter type for the bean component source object.
> >
> > The interface should be like that :
> > 8<----------------------------------
> > interface Factory<T> {
> > T create();
> > }
> > 8<----------------------------------
> > And then you just call the create() implementation.
> >
> > The problem is that that "solution" is very error prone : the interface
> > base implementation has to be overridden by each subclass or you will
> > end with the same type problem.
> > So, it seems to be a wore solution than the other one...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
--
Welcome to China Java Users Group(CNJUG).
http://cnjug.dev.java.net
Re: T5: Generic page classes with beaneditform
Posted by Jesse Kuhnert <jk...@gmail.com>.
I don't know if this helps or not, but I got generics working in a very
limited way with 4.1.x in that I do all the type lookup work
manually...(this probably won't work for this use case but thought I'd throw
it out just in case it does, even this breaks down in many places)
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/enhance/GenericsMethodSignatureImpl.java?view=markup
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/enhance/GenericsClassInspectorImpl.java?view=markup
On 6/26/07, Francois Armand <fa...@linagora.com> wrote:
>
> Francois Armand wrote:
> > Actually, it's not really an acceptable solution, but the sole
> > workaround I know (if somebody as another idea, I would be glad to use
> > it).
> Well, this sentence is not true.
> You may ask users to implement a "factory" interface for Class they
> intend to use as parameter type for the bean component source object.
>
> The interface should be like that :
> 8<----------------------------------
> interface Factory<T> {
> T create();
> }
> 8<----------------------------------
> And then you just call the create() implementation.
>
> The problem is that that "solution" is very error prone : the interface
> base implementation has to be overridden by each subclass or you will
> end with the same type problem.
> So, it seems to be a wore solution than the other one...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: T5: Generic page classes with beaneditform
Posted by Francois Armand <fa...@linagora.com>.
Francois Armand wrote:
> Actually, it's not really an acceptable solution, but the sole
> workaround I know (if somebody as another idea, I would be glad to use
> it).
Well, this sentence is not true.
You may ask users to implement a "factory" interface for Class they
intend to use as parameter type for the bean component source object.
The interface should be like that :
8<----------------------------------
interface Factory<T> {
T create();
}
8<----------------------------------
And then you just call the create() implementation.
The problem is that that "solution" is very error prone : the interface
base implementation has to be overridden by each subclass or you will
end with the same type problem.
So, it seems to be a wore solution than the other one...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Generic page classes with beaneditform
Posted by Francois Armand <fa...@linagora.com>.
Howard Lewis Ship wrote:
> There's an existing bug for this. I'm not sure how fixable it's going
> to be; welcome to the implementation nitty gritty of generic types and
> type erasure. Just cause you don't see the typecasts doesn't mean the
> compiler has put them there.
> Here's a challenge: what if there was a createWidget() method on your
> class. How would you implement it, to create an instance of the
> correct class? You can't do a new T() (the compiler won't let you,
> since it doesn't know what T is).
As you say, the wonderful type erasure "feature" implies that you have
to have more information about your type. For instance, you need to pass
a "Class<T> type" to your create() method. Actually, it's not really an
acceptable solution, but the sole workaround I know (if somebody as
another idea, I would be glad to use it).
After that, you can use reflection :
8<-----------------------------
public class EditWidgetPage<T extends Widget> {
T widget;
T create(Class<T> type) {
widget = type..newInstance();
....
}
}
8<-----------------------------
A bunch of infos are available at www.angelikalanger.com FAQs, and more
precisely about your concern :
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#How%20do%20I%20pass%20type%20information%20to%20a%20method?
Hope it may help...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Generic page classes with beaneditform
Posted by Howard Lewis Ship <hl...@gmail.com>.
There's an existing bug for this. I'm not sure how fixable it's going
to be; welcome to the implementation nitty gritty of generic types and
type erasure. Just cause you don't see the typecasts doesn't mean the
compiler has put them there.
Here's a challenge: what if there was a createWidget() method on your
class. How would you implement it, to create an instance of the
correct class? You can't do a new T() (the compiler won't let you,
since it doesn't know what T is).
On 6/25/07, Bill Holloway <bi...@gmail.com> wrote:
> I have a Widget base entity extended by several concrete product
> entities. I have
>
> public class <T extends Widget> EditWidgetPage
> {
> ...
> @Persist
> public Long _someWidgetId;
>
> public T _someWidget;
>
> // normal setters / getters
>
> void onActivate (long id)
> {
> _someWidgetId = id;
> _someWidget = _dao.get (id); // gets right subtype of Widget.
> Generics. Tested.
> }
>
> // onPassivate as per usual pattern.
>
> void onActionFromEditForm ()
> {
> _dao.saveOrUpdate (_someWidget);
> }
> }
>
> The page for this just uses a bean edit form, nothing else:
> object="someWidget". The saveOrUpdate call complains that someWidget
> is of type Widget rather than the subclass it's instantiated to be.
> Any thoughts?
>
> bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org