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 s
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
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 h
>
> I don't understand when I would use a Component and what they are for.
Typically a web-application is built from a number of pages. And each page
is different.
Many elements on the pages will be the same or similar though. For those
elements it is usually wise to create a separate component
On Fri, Jan 16, 2009 at 1:42 PM, Christian Edward Gruber
wrote:
> In some ways, a Page is just a Component that has no parent.
A page is a top level component. Technically, the page component is
actually the root component of the actual page (true pages
are a concept internal to Tapestry) but it
In some ways, a Page is just a Component that has no parent. I'm not
100% sure why they're separated, except that it's a historical
artifact. Components (and pages being a special-case component) are a
piece of java software that renders itself (usually as tags and
possibly with a body, w
