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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
