It's not a case so much that a component is guaranteed *not* to
render on it's own, it's more a case that it's not guaranteed that it
*will*. Outside of a page context, some components will render just peachy.
Others will fail.
It all comes down to whether or not your page depends on data
prepped elsewhere in the page render. You using an odd/even bean to change
color? Well, that bean won't be set properly in a component-only render.
Your component drawing based on data that the page pulled out of the DB?
That data won't be there in a component-only render, etc. Some components
though, which are totally self contained, can render just fine in a
partial-render situation.
It strikes me that this isn't particularly problematic e.g. it's
reasonable that some use cases require a full page, but others do not. I
think what tapestry needs to do is define a way to *identify* a discrete, as
opposed to page-dependant component. I'd think this is something the
component designer could set as a flag that Tapestry (and things like Tacos)
could then use to determine how to re-render the component. (another useful
flag would be "cacheable" to identify a component which renders repeatably
and hence could be cached by the framework).
Right now though, absent external information, the framework has to
assume everything requires a full page render. Some things, like the portlet
code, can assume otherwise, but that's precisely because they *know* it's a
portlet and hence has to obey certain rules. A generic component on a
generic page is an unknown quantity though and hence Tapestry has to assume
the most conservative case.
--- Pat
> -----Original Message-----
> From: Leonardo Quijano Vincenzi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 01, 2005 12:35 PM
> To: Tapestry users
> Subject: Re: daydreaming of tapetry and ajax
>
> Patrick Casey wrote:
> > Tapestry though, is architected around the concept of whole page
> > rendering. One can't guarantee that a component will render properly
> outside
> > of the context of its page. Which means, even if I only want to refresh
> > 1/100th of a page, I still need to render the whole thing on the server,
> > trim out the part I want to refresh, and push that back to the client.
> So I
> > cut down on my wire traffic, and I save the user a page load, *but* the
> > server is still building a full page.
> >
> This is an important limitation of Tapestry component model that should
> be targeted, if true, don't you think? I mean, a component - by
> definition - is a black box. A component that depends on its container
> page being rendered for proper rendering breaches that encapsulation
> (note that this is different of just a component who needs its container
> page to *exist* for proper rendering - in this case we don't have to
> render the whole page, just to have it in memory).
>
> I was talking about this in the Tacos list. Components, should IMO, be
> rendereable on their own, instead of needing the full page render cycle
> to work. A server-side component model in memory would help in this
> respect, I think.
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
