Re: Why can't component classes be abstract? [5.1]
On Mon, 22 Feb 2010 21:57:22 -0300, Hilco Wijbenga
wrote:
On 22 February 2010 12:48, Howard Lewis Ship wrote:
In all cases where Tapestry needs to access the field, such as to
synchronize its value with the session, it bypasses getters and
setters (either yours, or those generated by @Property) and updates
the field directly.
So what happens if I have something like
Thing getThing() { return model.getThing(); }
void setThing(Thing thing) { model.setThing(thing); }
? Or any other scenario where there is no easily identifiable field?
It works normally. Howard was talking specifically about *fields* with the
@Persist annotation (@SessionState too).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why can't component classes be abstract? [5.1]
On 22 February 2010 12:48, Howard Lewis Ship wrote:
> In all cases where Tapestry needs to access the field, such as to
> synchronize its value with the session, it bypasses getters and
> setters (either yours, or those generated by @Property) and updates
> the field directly.
So what happens if I have something like
Thing getThing() { return model.getThing(); }
void setThing(Thing thing) { model.setThing(thing); }
? Or any other scenario where there is no easily identifiable field?
Cheers,
Hilco
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why can't component classes be abstract? [5.1]
Nope, @Property is completely for your convienience, typically so you can reference a value (or injected service, component or whatnot) directly from a template using a property expression. In all cases where Tapestry needs to access the field, such as to synchronize its value with the session, it bypasses getters and setters (either yours, or those generated by @Property) and updates the field directly. On Mon, Feb 22, 2010 at 11:46 AM, Andy Pahne wrote: > Am 22.02.2010 16:20, schrieb Piero Sartini: >>> >>> Yeah, I understand the limitation. But how should I access a property >>> which >>> is defined in my base class in one of the subclasses with these >>> limitations? >>> >> >> Just don't use @Property - provide getXXX and setXXX methods. >> >> >>> >>> As far as I understand, I cannot make my base classes property protected, >>> nor can I generate a public getter/Setter pair. >>> >> >> You can generate a public getter/setter pair - but you may not use >> @Property then. If tapestry finds @Property, everything it does is >> creating the getter/setter methods. But it fails to do so if they are >> already present. Don't use @Property and it works like expected. >> >> > > This sounds like reasonable and clean solution. I was thinking way to > complicated. I had thought that this @Property annotation is necessary in > order to persist a property with @Persist or for using it as a form > component's value property. > > Thanks, > Andy > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why can't component classes be abstract? [5.1]
Am 22.02.2010 16:20, schrieb Piero Sartini: Yeah, I understand the limitation. But how should I access a property which is defined in my base class in one of the subclasses with these limitations? Just don't use @Property - provide getXXX and setXXX methods. As far as I understand, I cannot make my base classes property protected, nor can I generate a public getter/Setter pair. You can generate a public getter/setter pair - but you may not use @Property then. If tapestry finds @Property, everything it does is creating the getter/setter methods. But it fails to do so if they are already present. Don't use @Property and it works like expected. This sounds like reasonable and clean solution. I was thinking way to complicated. I had thought that this @Property annotation is necessary in order to persist a property with @Persist or for using it as a form component's value property. Thanks, Andy - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why can't component classes be abstract? [5.1]
On Mon, 22 Feb 2010 12:21:22 -0300, Andy Pahne wrote: Also abstract getter/setters won't work. (Although they used to work in T4. T4 could instantiate page or component classes, even if they werde abstract). T4 is a completely different codebase, another architecture. T5 transforms classes at runtime, T4 creates subclasses. T4 page and component classes were obliged to be abstract, not supporting concrete classes. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why can't component classes be abstract? [5.1]
> Yeah, I understand the limitation. But how should I access a property which > is defined in my base class in one of the subclasses with these limitations? Just don't use @Property - provide getXXX and setXXX methods. > As far as I understand, I cannot make my base classes property protected, > nor can I generate a public getter/Setter pair. You can generate a public getter/setter pair - but you may not use @Property then. If tapestry finds @Property, everything it does is creating the getter/setter methods. But it fails to do so if they are already present. Don't use @Property and it works like expected. > Also abstract getter/setters won't work. (Although they used to work in T4. > T4 could instantiate page or component classes, even if they werde > abstract). I am not totally sure, but I think I've used abstract getter methods in the past and it worked. Piero - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why can't component classes be abstract? [5.1]
Am 22.02.2010 15:34, schrieb Thiago H. de Paula Figueiredo:
I am really wonderung why an abstract class cannot be used as
component (page) class.
Because it needs to be instantiated.
The reason why I am wondering:
Let's suppose I have a few pages with some shared functionality. I'd
like to create a base class:
public abstract class BasePage{
@Property
private Object someProp;
public abstract Object getSomeProp();
public void setSomeProp(Object someProp)
}
Put BasePage in the base package, not the components or pages one.
Abstract classes are allowed there.
By the way, you cannot use @Property in a property with getters and
setters.
Yeah, I understand the limitation. But how should I access a property
which is defined in my base class in one of the subclasses with these
limitations?
As far as I understand, I cannot make my base classes property
protected, nor can I generate a public getter/Setter pair.
Also abstract getter/setters won't work. (Although they used to work in
T4. T4 could instantiate page or component classes, even if they werde
abstract).
Kind regards,
Andy
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why can't component classes be abstract? [5.1]
On Mon, 22 Feb 2010 11:33:56 -0300, Andy Pahne
wrote:
I am really wonderung why an abstract class cannot be used as component
(page) class.
Because it needs to be instantiated.
The reason why I am wondering:
Let's suppose I have a few pages with some shared functionality. I'd
like to create a base class:
public abstract class BasePage{
@Property
private Object someProp;
public abstract Object getSomeProp();
public void setSomeProp(Object someProp)
}
Put BasePage in the base package, not the components or pages one.
Abstract classes are allowed there.
By the way, you cannot use @Property in a property with getters and
setters.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
