tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Kuhnert <jkuhn...@gmail.com>
Subject Re: Global Asset change proposal
Date Mon, 02 Jan 2006 18:34:29 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message