Hi Ken,

Maybe I can help you out:

1. I would not :)

Pages and Components both have Properties. It's nothing special really. Think 
Bean Properties with automatic getter/setters. 

Components have Parameters, Pages have PageActivationContext.  Both can be 
Properties as well (because a property is just a field with getter and setters 
...).

About Component Parameters: http://tapestry.apache.org/component-parameters.html

About page activation:
http://tapestry.apache.org/page-navigation.html
http://blog.tapestry5.de/index.php/2010/08/23/context-values-vs-request-parameters/

http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/PageActivationContext.html

So ...

2.1 use @PageActivationContext field annotation or implement 
"onActivate(param1, param2 ... etc)" event handler
2.2 use @Property in your components
3. Well, of course it's always best to minimize state but I wouldn't call it a 
bad practice. I'd suggest you browse the tapestry sources and get a feel how 
the internal components are written. I'd think that they represent t5 best 
practices.

Kind Regards,
Wulf


-----Original Message-----
From: Ken in Nashua [mailto:[email protected]] 
Sent: Donnerstag, 11. Oktober 2012 16:35
To: [email protected]
Subject: pages and components


Folks,

I am trying to nail down the concept (or at least inspired concept) of page and 
components and how they should be modeled with parameters and properties.


Here is my semantic concept issue... if you can add to it that would be helpful.

PAGES HAVE PROPERTIES, COMPONENTS HAVE PARAMETERS (yeah I know I can deviate 
but this is the general concept)
1. would you agree this is the general concept?
2. under what conditions would I deviate... 
2.1 ok say when would i want my page to have parameters
2.2 ok say when would i want my component to have properties
3. I am seeing cases where I need both... for a component... is this bad 
practice? What could be bad practice.

I am just searching for the religion on this and its twists.

Thanks in advance
Ken


                                          

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to