You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Robert <rv...@xs4all.nl> on 2005/06/03 10:30:13 UTC
Concrete pages and components
Hi,
After working with tapestry a little bit I decided to find a way to not
use abstract classes anymore. They give me too much trouble. I was
hoping you people could give me some insight in the possibilities to
accomplish this.
For pages I read about the possibility to use getProperty/setProperty to
avoid abstract classes. Could anyone elobarate on this?
Also is anyone using just instance variables and using initialize to
reset them? Doesn't sound to be too much work to do.
And how would I deal with the parameters of components? How can I avoid
the abstract getters and setters for those?
Thanks for any help.
Robert.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Concrete pages and components
Posted by Robert <rv...@xs4all.nl>.
Erik Hatcher wrote:
>
> On Jun 3, 2005, at 9:05 AM, Robert wrote:
>
>> The thing that I don't understand is that when I define my own
>> getter or setter for a property, that I will get into an infinite loop.
>
>
> I see what you mean. I do not wrap my calls to getProperty inside
> normal looking getters like that so I've not had that issue.
>
> I'm not sure if you're saying you have had a problem naming things
> this way or if you're saying you expected there to be a problem - I
> don't know if this is an issue or not, but I wouldn't be surprised.
>
I guess what I am trying to say is that it is too easy to break things
with Tapestry without any warning that it is not allowed. I just try to
get a feeling of how Tapestry works.
>> I noticed that initialize is never called. Isn't it needed for the
>> same reason as pages?
>> The first time when going to a page with this component, it will
>> enter both getValue and setValue. But the next times it will enter
>> just setValue.
>> The value 50 or 40 are actually never displayed on my page. I will
>> only see the value that was given to the value parameter.
>
>
> I'm not sure off the top of my head about component parameters like
> this, but initialize() is a page thing, not component if I remember
> correctly.
>
So does that mean that instance variables are not allowed for components?
Does anyone else know why the getter and setter are called like this?
> I highly recommend you get Howard's book if you don't already have it
> - he's provided a lot of helpful state information in there.
>
Yes I have it and almost finished it. Still I think I could a learn a
lot of it if I read it again now that I have a little bit experience
with it :p
If I could make any recommendation for Tapestry. Make it easier to avoid
having abstract classes. Actually.... don't enhance classes as well. It
is not transparant what is happening and decreases the benefits of
strong typing and fixing errors compile time.
Robert.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Concrete pages and components
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jun 3, 2005, at 9:05 AM, Robert wrote:
>> There really isn't much to elaborate on. You can make your
>> classes concrete, use <property-specification> (or <property> in
>> Tapestry 4.0 DTD) in the specification files and simply use get/
>> setProperty in your Java code to work with the values.
>>
>
> The thing that I don't understand is that when I define my own
> getter or setter for a property, that I will get into an infinite
> loop.
> For example if I have an address property and implement:
> public Address getAddress()
> {
> return (Address)getProperty("address");
> }
>
> What I expected is that the call would lead into the enhanced class
> with its own implementation of getAddress.
> I forgot if the enhancing was based on the properties specified in
> the page specification, or on the abstract methods, or both.
>
> Of course if I name the method getAddressProperty or something then
> it works fine.
I see what you mean. I do not wrap my calls to getProperty inside
normal looking getters like that so I've not had that issue.
I'm not sure if you're saying you have had a problem naming things
this way or if you're saying you expected there to be a problem - I
don't know if this is an issue or not, but I wouldn't be surprised.
> I think that as long as I do all my instances like this, I will get
> used to it and won't forget.
> Are there any other downsides on it? Like losing some functionality
> regarding lifecycle management?
Be careful with persistent properties - but other than that I think
you'd be fine.
> For example I have a component with a value parameter
> <parameter name="value" direction="in" required="yes" type="int"/>
>
> The component class contains:
> private int value;
> public void initialize() {
> value = 0;
> }
>
> public int getValue() {
> return 50;
> }
>
> public void setValue(int value) {
> this.value = 40;
> }
>
> I noticed that initialize is never called. Isn't it needed for the
> same reason as pages?
> The first time when going to a page with this component, it will
> enter both getValue and setValue. But the next times it will enter
> just setValue.
> The value 50 or 40 are actually never displayed on my page. I will
> only see the value that was given to the value parameter.
>
> I really would like to know what is happening.
> I find Tapestry very confusing :)
Me too :)
I'm not sure off the top of my head about component parameters like
this, but initialize() is a page thing, not component if I remember
correctly.
Personally, I avoid instance variables in Tapestry pages/components,
but I do use get/setProperty. I highly recommend you get Howard's
book if you don't already have it - he's provided a lot of helpful
state information in there.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Concrete pages and components
Posted by Robert <rv...@xs4all.nl>.
Erik Hatcher wrote:
>
> On Jun 3, 2005, at 4:30 AM, Robert wrote:
>
>> Hi,
>>
>> After working with tapestry a little bit I decided to find a way to
>> not use abstract classes anymore. They give me too much trouble. I
>> was hoping you people could give me some insight in the
>> possibilities to accomplish this.
>>
>> For pages I read about the possibility to use getProperty/
>> setProperty to avoid abstract classes. Could anyone elobarate on this?
>
>
> There really isn't much to elaborate on. You can make your classes
> concrete, use <property-specification> (or <property> in Tapestry 4.0
> DTD) in the specification files and simply use get/setProperty in
> your Java code to work with the values.
The thing that I don't understand is that when I define my own getter or
setter for a property, that I will get into an infinite loop.
For example if I have an address property and implement:
public Address getAddress()
{
return (Address)getProperty("address");
}
What I expected is that the call would lead into the enhanced class with
its own implementation of getAddress.
I forgot if the enhancing was based on the properties specified in the
page specification, or on the abstract methods, or both.
Of course if I name the method getAddressProperty or something then it
works fine.
>> Also is anyone using just instance variables and using initialize to
>> reset them?
>> Doesn't sound to be too much work to do.
>
>
> I would only recommend using instance variables sparingly just to
> minimize the risk of overlooking the initialization/resetting of
> them. But you're right, it's not really that much work.
>
I think that as long as I do all my instances like this, I will get used
to it and won't forget.
Are there any other downsides on it? Like losing some functionality
regarding lifecycle management?
>> And how would I deal with the parameters of components? How can I
>> avoid the abstract getters and setters for those?
>
>
> Parameters of components become properties also, defaulting to the
> same name. So you'd deal with them just like you would properties as
> above.
>
And could I use instance variables for those too? Or just use the
set/getProperty?
I found some strange behaviour while trying to use instances in components.
For example I have a component with a value parameter
<parameter name="value" direction="in" required="yes" type="int"/>
The component class contains:
private int value;
public void initialize() {
value = 0;
}
public int getValue() {
return 50;
}
public void setValue(int value) {
this.value = 40;
}
I noticed that initialize is never called. Isn't it needed for the same
reason as pages?
The first time when going to a page with this component, it will enter
both getValue and setValue. But the next times it will enter just setValue.
The value 50 or 40 are actually never displayed on my page. I will only
see the value that was given to the value parameter.
I really would like to know what is happening.
I find Tapestry very confusing :)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Concrete pages and components
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jun 3, 2005, at 4:30 AM, Robert wrote:
> Hi,
>
> After working with tapestry a little bit I decided to find a way to
> not use abstract classes anymore. They give me too much trouble. I
> was hoping you people could give me some insight in the
> possibilities to accomplish this.
>
> For pages I read about the possibility to use getProperty/
> setProperty to avoid abstract classes. Could anyone elobarate on this?
There really isn't much to elaborate on. You can make your classes
concrete, use <property-specification> (or <property> in Tapestry 4.0
DTD) in the specification files and simply use get/setProperty in
your Java code to work with the values. It'll work the same as the
abstract technique with getters/setters defined. You do lose some
compile-time checking, of course, but that is something we all need
to be a bit less concerned with in general :)
> Also is anyone using just instance variables and using initialize
> to reset them?
> Doesn't sound to be too much work to do.
I would only recommend using instance variables sparingly just to
minimize the risk of overlooking the initialization/resetting of
them. But you're right, it's not really that much work.
> And how would I deal with the parameters of components? How can I
> avoid the abstract getters and setters for those?
Parameters of components become properties also, defaulting to the
same name. So you'd deal with them just like you would properties as
above.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org