>
> Hi all - I've lurked here for a little while and am just embarking on
> implementing a project using Turbine so I thought I'd pop my head up.
> First I'd just like to say that I'm very impressed with Turbine's
> elegance as an API, plus for obvious reasons quite chuffed that
> someone else has written half my code already ;-)
:-) That is the point of Turbine. :-)
> Anyway I'm going to be using WebMacro, and it struck me that given Dave
> Bryson's work with WebMacroSitePage etc it would be possible to write
> even fewer Screens if the Action and WebMacro template shared a
> WebContext. Then the Action could set up the WebContext and the template
> display it.
-1. That isn't what the Action modules are for. There is a clear
description on the site that explains what Actions are for.
> If not I'd be happy to put together some patches. I would probably have
> the WebMacroSitePage set up a WebContext in the user object's temp
> hashtable and have a WebMacroSiteAction baseclass that wraps fetching
> the context. The default WebMacroSiteScreen would then pass _that_
> context into the template.
-1. The webcontext won't be the same across requests unless you really
want it to be. If you make this the default behavior, people will get
confused.
> I guess that given the level of integration of WebMacro that Dave has
> been suggesting on this list it might even make sense to put the context
> in the RunData object? Either way only the 3 WebMacroSite* classes would
> need to know where the context comes from.
-1. The RunData object should not be template language specific.
> A possible danger I can see is the weakening of the elegant separation
> of MVC that Turbine's module structure encourages - definitely the bit I
> like the most about Turbine coming from GUI app development to web apps
> - if people took this as an excuse to write view logic in Actions, but
> as long as it is clear that specific WebMacroSiteScreen derivations
> should be written where specific view logic is needed this should be ok.
Anything that weakens the MVC is bad.
> Excuse the slightly verbose form of my proposal, but partly I'm just
> interested in bouncing my thoughts off the list to see if I'm
> understanding this stuff as well as I think I am :)
I'm just happy someone is looking at and using the code and thinking about
cool ways to improve things (even if I just -1'd all your ideas <smile>).
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
