You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ken in Nashua <kc...@live.com> on 2012/10/11 16:35:12 UTC
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
RE: pages and components
Posted by "Wechsung, Wulf" <wu...@sap.com>.
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:kcolassi@live.com]
Sent: Donnerstag, 11. Oktober 2012 16:35
To: users@tapestry.apache.org
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: pages and components
Posted by Dmitry Gusev <dm...@gmail.com>.
Pages and components are generally the same for me.
Pages are just top-level components.
They both have parameters: for pages they came from GET/POST/... HTTP
requests, source of component parameters are pages and other components.
Properties are just their state, the state that pages/components want to
open to other objects, as in general Object Oriented Programming. There are
special case of properties -- which are private fields with @Property
annotation, that a page or component wants to open to its TML-design.
On Thu, Oct 11, 2012 at 6:35 PM, Ken in Nashua <kc...@live.com> wrote:
>
> 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
>
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: pages and components
Posted by George Christman <gc...@cardaddy.com>.
Not entirely related, but Geoff has put together a really nice site
containing lots of examples. Perhaps it might come in handy for you if
you're not already aware of it.
http://jumpstart.doublenegative.com.au/jumpstart/
--
View this message in context: http://tapestry.1045711.n5.nabble.com/pages-and-components-tp5716791p5716801.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: pages and components
Posted by Charlouze <me...@charlouze.com>.
Hey,
I'm not a tapestry expert but here is what I think about pages, components,
properties and parameters:
Parameters (annotated with @Parameter) can only be used in components as
parameters for the component (pages don't have parameters).
Properties (annotated with @Property) are private attributes of pages or
components that you want to expose to the template without the need of
writing getters and setters.
Parameters and properties are, IMHO, not related at all and don't serve the
same purpose.
I hope it will lighten you a little bit.
Charles.
2012/10/11 Ken in Nashua <kc...@live.com>
>
> 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
>
>
>
Re: pages and components
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 11 Oct 2012 11:35:12 -0300, Ken in Nashua <kc...@live.com>
wrote:
> Folks,
Hi!
>
> 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)
I wouldn't say that. Components can have properties just fine, but you
should use parameters to pass information to them (or the Environment on
some specific cases). Pages don't have parameters (unless you count the
page activation context as parameters), so you can't use @Parameter on
them..
> 1. would you agree this is the general concept?
No.
> 2. under what conditions would I deviate...
Any class can have properties.
> 2.1 ok say when would i want my page to have parameters
Yes if you consider parameters as the page activation context, no if
you're thinking about @Parameter.
> 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?
No. Just use the same common sense you'd use for any other Java class. Why
would it be a bad practice? :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org