Global Asset change proposal

[Jesse Kuhnert <jk...@gmail.com>]

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

Re: Global Asset change proposal

[Ron Piterman <rp...@gmx.net>]

What css concerns, I would leave it to the trouble of the developer to 
specify the right css's to use.
it is a very tricky issue because css is very sensitive in respect to 
the order of the stylesheets, so the designer must decide, and thus it 
goes as static def. in the page.
No component contributions.

We did implement such a thing for a border component: it went down the 
tree of components, and took css defs from Styleable (interface) instances.
We ended up not knowing which css will be contributed on which place, 
making of our styles a big salat, impossible to design. Css is very 
tricky...

Now I thought js contributions are already there using the Body...
Is it essential to add the to the head?
what about changing body to render the </head> after it renders JS 
contributions?

Cheers,
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

Re: Global Asset change proposal

[Jesse Kuhnert <jk...@gmail.com>]

P.S. I think this is sort of what MindBridge was hinting at in his(her? I
can't tell who it is, always feels like a divine entity dropping in ;) )
post in regard to the ActionService, and needing parameters/bindings to be
completely setup for listener methods.

On 1/2/06, Jesse Kuhnert <jk...@gmail.com> 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 <rp...@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
> >
> >
>

Re: Global Asset change proposal

[Jesse Kuhnert <jk...@gmail.com>]

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 <rp...@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 <rp...@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
>
>

Re: Global Asset change proposal

[Ron Piterman <rp...@gmx.net>]

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 <rp...@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

Re: Global Asset change proposal

[Jesse Kuhnert <jk...@gmail.com>]

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 <rp...@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
>
>

Re: Global Asset change proposal

[Ron Piterman <rp...@gmx.net>]

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