Yarko, I am done. No overhead, just an extra dictionary with pointers in memory.
Yes you can have nested blocks. -- Thadeus On Wed, May 5, 2010 at 10:43 PM, Yarko Tymciurak <[email protected]> wrote: > I've said I think a lot of things will get easier, I think I see a > fundamental (structure of responsibility) problem, and believe solving > it will generate beneficial impact.... > > But this is experimentation, just a concept. Lets not worry too much > about a realease, performance - it might not be worth worrying about > yet - > > If we get _some_ minimal working concept, we can start playing around > (even if it's dog slow) to see if any of my expectations will hold > up: if skinning gets easier, and more than one person can see that, > THEN it will be worth worrying about this more, how to implement, > performance, etc. > > Now, lets try a concept - simply. > > Thank you, thank you, thank you for all of you thinking about it this > much, especially after just making a significant (and important) > change. Hopefully, this will just amplify the changes you already > made! > > Kind regards, > - Yarko > > On May 5, 10:33 pm, Yarko Tymciurak <[email protected]> > wrote: >> On May 5, 10:14 pm, Thadeus Burgess <[email protected]> wrote: >> >> > I can't really say, we need some tests to analyze the effects of this. >> >> > I am thinking of a way that might not include any extra overhead at all. >> >> Yep - then you are on the right track; I predict it will be no >> worse, or possibly faster... (some other things may simplify) >> >> The real benefit (I am hoping) will be opening the door to skinning; >> we always thought "it should be easy", keep looking at sites that have >> skins - get them, adapt them... sure, we can use them, but getting >> them as useful design elements (i.e. being able to have them be _just >> like we want them_) , especially by program, has been a little more >> elusive. >> >> I am confident this will break some blocks to that., although I am not >> sure how far, I am sure it's in the right direction. >> >> - Yarko >> >> >> >> > -- >> > Thadeus >> >> > On Wed, May 5, 2010 at 10:02 PM, mdipierro <[email protected]> wrote: >> > > Before you go and implement this can you assess if this will affect >> > > the speed of template processing? >> >> > > On May 5, 9:57 pm, Thadeus Burgess <[email protected]> wrote: >> > >> It might be possible for the parent to look into its children, and >> > >> analyze the child blocks, and if a block in the child contains a >> > >> {{super <me>}} it can then take its own value and replace it into the >> > >> {{super me}}. >> >> > >> -- >> > >> Thadeus >> >> > >> On Wed, May 5, 2010 at 9:56 PM, Thadeus Burgess <[email protected]> >> > >> wrote: >> > >> > Right. >> >> > >> > As much as I would like the functionality... This cannot be done as >> > >> > the system stands. Child templates know nothing of their parent, >> > >> > therefore they are unable to request anything from the parent >> > >> > template. >> >> > >> > The way that you effectively override a block is by effort of the >> > >> > parent looking at all its children and going "Hey, you have the same >> > >> > block I do, so I will use yours". >> >> > >> > So the way to do this, is for the child to know about its parent, and >> > >> > its parents parents, and parents parents parents (etc, depending on >> > >> > the level of hierarchy.) The issue is, how does this element then >> > >> > determine which parent it should pull from, assuming the grandparent >> > >> > defines a block, and the parent overrides the block, what is left is >> > >> > not what is intended. >> >> > >> > -- >> > >> > Thadeus >> >> > >> > On Wed, May 5, 2010 at 8:28 PM, Yarko Tymciurak >> > >> > <[email protected]> wrote: >> > >> >> nyway, I don't know what the right syntax / implementation (exactly) >> > >> >> of a template "super" function is - I just know it makes sense, and I >> > >> >> think we should have it (I am certainly investing a lot of effort in >> > >> >> driving exploration of how it would work, look, and w >
