Only because howard might be stuck on a long flight or otherwise indisposed,
I'll try another crack at it.
You could probably think of mixins as having the ability to do multiple
inheritance in java. The only difference being that we're moving away from
interfaces/subclassing to more of a composition sort of pattern.
For instance..The tacos logic that enhances all components via javassist
does a few things to component classes.
- ) Adds an injected hivemind service reference to the AjaxWebRequest.
-) Extends the renderComponent() method to do some checks on whether or not
the component should be renderd. (if requested in the ajax request, or if
it's even a valid ajax request).
This is all done more or less manually, using the javassist API through
howards render enhancement stuff. So, instead of all this fun logic being
defined in a nice easily testable class, it's mostly manually written java
code inside of string blocks..ie:
StringBuffer renderComponent = new StringBuffer("if (ajaxRequest) {
dothisThing(); } ");
It's a little more complicated than that, but that's the basic premise. It's
an ok thing to do for internal API's, but isn't friendly to testing or more
regular uses overall..
The most ideal way to do it would instead be able to define what this actual
class would look like in a real java class...We could have something like
this:
public class AjaxRenderEnhancement {
AjaxWebRequest ajaxRequest;
//normal hivemind injected service
public void setAjaxRequest(AjaxWebRequest ....);
public void renderComponent(IComponent component, IMarkupWriter
writer, IRequestCycle cycle) {
if (ajaxRequest.isAjaxRequest()) {
component.renderComponent(writer, cycle);
}
else return;
}
}
This is more or less the end result of what all the ajax enhancement stuff
would create. Now someone could take this code, which by itself can't do
anything, and "mix it" in with the component I want to enhance...Like a
PropertySelection component, or whatever you want. The AjaxWebRequest would
be made a member of the PropertySelection class, and the renderComponent
method would be added as well. (Signature is different).
I don't actually know how he's going to implement it, so there are a lot of
very large flaws I've written up...But that is my understanding of it.
C# supports this construct as well..So does javascript. That's how dojo
provides "super" class sort of functionality. There is a method
dojo.lang.mixin() that gets called to merge two javascript object
definitions together. Of course that language is much more dynamic, so it's
perfectly legal to do something like this:
function validateInput(inputField) {
if (!inputField.value) //validate
}
var myObject = new Object();
At this point my "myObject" object isn't really capable of doing
anything..But now we can do this:
myObject.validateInput = validateInput;
and then call:
myObject.validateInput(document.getElementById("foo"));
I'll leave the rendering queue to Howard as there are too many possibilities
for me to try imagining...
On 2/27/06, Geoff Longman < [EMAIL PROTECTED]> wrote:
>
> 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]
>
>
