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:56:57 GMT
Yeah......There is that. I was just thinking about the very same problem
while getting a coke from 711...Perhaps the Shell having it's own
NestedMarkupWriter isn't such a bad idea after all. Will have to think about
this some more...

On 1/2/06, Ron Piterman <rpiterman@gmx.net> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message