Hi.
> Thanks! (curious) How did you first hear about turbine? ;-)
I found a link to the Working Dogs site a while back where I read about
Dash. I was sufficiently intrigued but didn't have any time to dig in but
when it made the move to Turbine I subscribed to the mailing list so I
wouldn't be able to forget about it. I've been lurking since then and
finally got my hands dirty.
> With regards to DefaultTopNavigation...you don't have to use it. You can
> also "replace" it by simply creating your own DefaultTopNavigation class
and
> putting it first in your modules.packages path. Your patch is also
probably
> valid...as Brett says...we will take a look at it more tomorrow. ;-)
I understand. That's what makes Turbine so flexible. But while writing some
of my own Navigations I was looking at the DefaultTopNavigation as a guide
and was perplexed as to why it was adding it's elements to the RunData's
page instead of returning the element the way that the
DefaultBottomNavigation did. The Navigation was basically bypassing the
Layout and just appending itself to the page (which was empty so everything
worked out ok in this case).
I think that the Action.build method would be more appropriately named
execute or something similar. Actions are, as far as I can tell, the main
reason for the differing eval and exec methods in all the *Loaders. Although
the build method isn't used polymorphically for even the "visible"
Assemblers like Screen and Navigation. Couldn't virtually all of the *Loader
code be factored out into an abstract super class if you had a build method
in an interface like Assembler? Of course, Action wouldn't then be able to
implement Assembler which is OK because Assemblers aren't being used
polymorphically anywhere. Not even as a marker interface.
Jason.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
