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
