tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Piterman <rpiter...@gmx.net>
Subject Re: Global Asset change proposal
Date Mon, 02 Jan 2006 18:52:05 GMT
So a pre-render cycle will gather information...
sounds very neefty, its only the performance issue I guess which twicks 
a little...
Cheers,
Ron


Jesse Kuhnert wrote:
> I'm still a little stumped on this one right now as well. The delegate idea
> is what I'm currently doing in tacos4.1, but it's not the ideal path.
> 
> I'm hoping/thinking that howard's elimination of the rewind cycle will shed
> some light on how best to solve this problem. Anything I add without
> addressing that just feels like a hack. There's no getting around it :(
> Maybe it will be called the "logic" cycle. The inefficiencies of passing
> around a NullWriter could be fixed by adding logic/interfaces/etc that
> directly deal with the need for this special cycle.
> 
> We could then have full knowledge (more or less?) of what sort of page setup
> we're dealing with without actually having to render things. I think it will
> break a lot of things for people, but the power and flexibility a change
> like this brings sort of outweighs these type of concerns in my mind. It's
> exciting to think about :) It would fix/improve soooo much.
> 
> I'm starting to get it, slowly but surely..
> 
> On 1/2/06, Ron Piterman <rpiterman@gmx.net> wrote:
> 
>>Hi Jesse,
>>
>>I am facing yet again the same problem :
>>I need to add a css depending on a page state.
>>What I am going to do is add a Delegate which will render a css link and
>>register in this delegate some providers - thought you might be
>>interested, since it addresses just what you mentioned here...
>>Cheers,
>>and HNY,
>>Ron
>>
>>
>>
>>Jesse Kuhnert wrote:
>>
>>>I'm starting to think over how to implement being able to have
>>
>>components
>>
>>>contribute css/js type assets into the Shell component automatically and
>>>have run into a one way or the other sort of decision.
>>>
>>>Method 1:
>>>Because the Shell component will almost always come first before any
>>
>>other
>>
>>>component, the only way to allow these global contributions in a normal
>>>sense would be to create a NestedMarkupWriter that Shell hands off to
>>
>>render
>>
>>>it's body with. This has major drawbacks in that the memory footprint of
>>
>>a
>>
>>>page render will grow very large(or not, depending on your pages
>>>implementation..), as well as the negative impact of content not being
>>>written to the client as it is found, making percieved response times of
>>>apps slower.
>>>
>>>Method 2:
>>>The way I'd like to do it, but don't even know if is possible would be
>>
>>to
>>
>>>use IComponentSpecification instances of all the components involved in
>>
>>a
>>
>>>response to allow the Shell to iterate over and determine the global
>>
>>assets
>>
>>>ahead of time. This sounds like the more "correct" way to do things, but
>>>also makes me question how reasonable this is to do. It would almost be
>>
>>like
>>
>>>doing a rewind cycle the way forms do to parse out submitted values. I
>>
>>can't
>>
>>>imagine it will be as simple as just iterating over some assets as they
>>
>>must
>>
>>>somehow change sometimes during loops or other application specific
>>
>>logic.
>>
>>>My gut says Method 1 is going to win, but if someone can point out an
>>>obvious way that Method 2 is safe I'd definitely be willing to explore
>>
>>that
>>
>>>path.
>>>
>>>jesse
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message