As Steve mentions its an evolution of personal best practice for your coding style. My personal taste through the years evolved through trial and error, more components is not always better but components to me work best when devoid of state, i.e.: breaking out the mechanics into the component and leaving the state in the page, this makes for wonderful reuse and very generic components reusable across applications without change.
Cheers, Peter ----- Original Message ----- From: "Steve Eynon" <steve.ey...@alienfactory.co.uk> To: "Tapestry users" <users@tapestry.apache.org> Sent: Friday, 9 September, 2011 10:22:59 GMT +02:00 Athens, Bucharest, Istanbul Subject: Re: pages vs components... use model still the same or has it evolved any ? This is less to do with Tapestry and more to do with general OO practises and your personal preference towards it. e.g. When writing a Java class, you could write everything in a single method, but to gain efficient reuse you usually refactor it out into multiple methods. Similarly, you split your pages into components to gain reuse. And for practical reuse, both methods and components need parameters. If in the past you were writing components that had so many parameters that they confused you, then I would suggest next time you try a different design approach. Steve. On 9 September 2011 09:30, Ken in Nashua <kcola...@live.com> wrote: > > I guess I am wondered in other peoples ideas over pages and components. > > Though my take on them... pages NEED to persist properties across request > boundaries... and components persist those page properties thru their well > defined parameter interface. Does this mean that components should never have > properties ? > > Looking forward to light on this subject that might adhere to a natural > model... > > thanks > > From: kcola...@live.com > To: users@tapestry.apache.org > Subject: pages vs components... use model still the same or has it evolved > any ? > Date: Thu, 8 Sep 2011 21:25:23 -0400 > > > > > > > > > An exerpt from a 2004 tapestry guide... > > -------- > A component's parameters are bound to properties of the > enclosing page. The component is allowed to read its parameter, to access the > page property the parameter > is bound to. A component may also update its parameter, to force a change to > the bound page > property. > ----------- > > Does this imply that components do not have properties ? or should not ?... I > know tapestry gives us enough rope to hang ourselves with > > Is there a politically correct semantic for pages vs components now... with > tapestry5 or is the concept the same since older versions ? > > If anyone could elaborate on a general use model for components vs pages that > would be helpful. > > I have found some page/component code cluttered up with so many properties > and parameters not knowing which to use and when... whereby either of these > have both pages and properties.... > > If anyone could elaborate on a general use model for components vs pages that > would be helpful. > > Thanks > Ken > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
