You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "F. Da Costa" <da...@xs4all.nl> on 2004/02/27 11:42:12 UTC

Best practice question

Hi,

As i am finally nearing my alfa-test i'm getting to the point where left or 
right turns have to be made.
Though some choices others are not because of a incomplete understanding of 
the effects of certain decisions on the performance of Tapestry.

.page side signifies the implementing page spec with its corresponding 
.java and .html spec.
.jwc side implies the same for the treetable component being used

Overview:
- .page contains a 'complexish' treetable component.
- the treetable can contain 1000++ rows (and 10++ of columns) of which part 
will be relevant to the user working on it (only the relevant rows will be 
loaded, as required).
- Type of the tree is determined on the .page side
- User data is obviously initially retrieved on the .page side as well

Q:
What is the best place to hold on to:
- the treeType, which is basically a one-off (could be on the .page or .jwc 
side)
- the userdata set, whereby it should be noted that the treetable component 
supports full editing as well, thus having a direct impact on the userdata.
I could set up a variable on the .page side and 'connect' to that from the 
.jwc side via binding (i guess?) but would this actually work. page pooling 
is in the back of my mind now.

I'm currently inclined to shift everything slichtly user related or dynamic 
in nature to the .page side but i'm just going on gut feeling here.

Is there a best course to follow (roughly speaking)?

TIA
Fermin DCG


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org