On 2/27/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: <snip!> > > It can probably get a ~lot~ more dynamic and graceful than that, but the > basic premise I think is that he'd be going in and automagically connecting > all of these things for you..Instead of having to manually specify a lot of > logic all over the place. The same would hold true for a lot of other things > as well I'm guessing.
ok, without knowing if Howard's intent matches your description I'd be loathe to call this mixins. Looks more like auto-wiring to me. Enhancement today adds methods and fields to the public interface of a 'base' class but unless that added interface is there in the base class (abstract method decl) then the added 'stuff' is visible only to reflection based mechanisms (ognl as one example) and then only because Tapestry does a little "bait & switch" by substituting the enhanced class for the original one at runtime. But the following makes me doubt that autowire is all there is: >You will put your pages under com.example.root.pages and your >component under com.example.root.components. Further, you will put >your mixins under com.examples.root.mixins. So a mixin appears to be a class - a class containing what? > > rendering queue - Again, no idea what's actually in his head, but my > layman's notion of it was that this would more or less be addressing the > issue of not knowing about something until you get to it, and then more or > less it being too late to do something smarter by the time you've gotten > there.. ok. (and I'm not bashing you Jesse) how will this be accomplished? > > This would enable css to be globally contributed into the Shell for example. > So, we know how the Form does the rewind cycles...It passes in a null writer > that basically still does the entire render, it just doesn't output > anything..I think in this scenerio he would completely break out the logic > of rendering from the logic that sort of "moves the cycle forward". ..Making > it very very efficient to do the form rewind sort of logic if the actual > rendering is made into a seperate thing. That's a goal worth persuing. I still don't get it though. (boy I feel dumb today). > > This would also make about 10 billion other things much better. Like direct > component renders, etc.... > > That's a layman's view on it though. I'm sure there is more too it but I > think that is the overall ~reason~ for the queue, even if not what the > actual details would contain. I think I'm just lacking a clear explanation. It worries me that even though I have been using Tapestry for many years this new stuff is sailing right over my head. Perhaps I'm too tied to java and static thinking. The closest I've been to a dynamic language is ruby. and not really even that as the closest I've been to ruby is the word "ruby" - a stone in one of my mother's rings! Geoff -- The Spindle guy. http://spindle.sf.net Get help with Spindle: http://lists.sourceforge.net/mailman/listinfo/spindle-user Blog: http://jroller.com/page/glongman Feature Updates: http://spindle.sf.net/updates --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
