It's all because of Tapestry's/hivemind wonderful binding parameter infrastructure. You really can do this, and the components ~don't~ need to be completely self contained. It just works :)
I think the interfaces/IRequestCycle/base classes all provide more than enough for this functionality to also "just work". There are more ideal new concepts that I'd like to introduce, but overall the framework really does support these things as is. It just needs an ever so slight change here or there to make it possbile. I promise, it really is possible. You will see :) On 12/1/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > 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] > >
