Re: [Webmacro-devel] WM WebApp design draft

[Lane S. <la...@op...>]

Marc,

I would like to see 2 high level changes.

First, all initialization, configuration is handled in a template that 
provides the application configurator with the ability to use templates 
to configure the application. property files are way to narrow and limiting.

Second, I want to see some rule-based action handling from a template:

#if (conditionA) { $actionA }
.
.
.
#if (conditionZ) { $actionB }

-Lane

Marc Palmer wrote:

>
> Hi guys,
>
> Just spent a little time hacking out a rough design for how I see the 
> "install and go" WM WebApp working.
>
> Attached is a GIF of the basic UML. The buzzword here is "keep it 
> simple".
>
> Goals of the project:
>
> 1. Provide a web application that can be installed and used 
> immediately. No config necessary to start using simple WM templates - 
> web designers can use it immediately, including using #bean if they 
> want to.
>
> 2. Make it such that it is very flexible and can be used as a base for 
> custom web-applications written by Java programmers. i.e. "son of 
> WMServlet".
>
>
> The idea is as follows:
>
> 1. "Helpers" would be any Java classes/beans (no need to implement any 
> interface). These would be put into every context for every page 
> returned. The loading of the classnames and the instantiation of the 
> classes AND whether they are created on a per-context basis or use a 
> shared global instance is abstracted. Implementations of HelperList 
> will be able to do what they like.
>
> A default implementation called SimpleHelperList would load a list of 
> class names and their variable names from a properties file and would 
> put them into the context. The properties file would be specified 
> using a servet context init parameter, or JNDI. Only one instance of 
> each would be created, and shared for all WebContext(s) used.
>
> 2. "Actions" are pluggable action handlers - a familiar concept to 
> everyone here. However the way the servlet determines what action to 
> execute is abstracted through ActionList. ActionList is always asked 
> which Action to use for a given request (WebContext) so there is huge 
> flexibility there. The default SimpleActionList will, like the 
> SimpleHelperList, load a list of action classnames and their action 
> "name" string, and will look for an "action=" parameter in the 
> request, and return the appropriate Action.
>
> Other implementations could make educated choices based on a wide 
> range of parameters or session variables, and Action(s) could even be 
> dynamically created on a per-request basis. This should also allow 
> this web application to plug in to existing web applications that may 
> wish to switch to a cleaner design model without changing any of their 
> templates or URIs. There need not be any 1:1 mapping between 
> parameters and Action executed, so in a way ActionList can become the 
> "brain" to a complex (or badly designed!) webapp.
>
> 3. "ActionResponse" represents what happens after an Action executes. 
> It can trigger the return of a WM template to the client, or an error 
> page containing an error message, or send a HTTP error code, or 
> redirect to another URI. This gives Action implementations a great 
> deal of flexibility. The servlet handles how these actually take place.
>
> 4. By default, if no action is found the system will return to 
> executing the ReturnTemplateAction which looks for a "template=" 
> parameter and tries to return that template. This would be the most 
> common usage for "Joe web monkey", as it would require no Java code or 
> configuration.
>
> 5. All of the core behaviour in the servlet uses protected methods so 
> that it can just be used as a framework for more complicated 
> applications or people who don't want to use the HelperList or 
> ActionList.
>
> As you can see it's all pretty simple I think, and should be trivial 
> to implement.
>
> Comments please! I do feel pretty strongly though that this should be 
> so simple that any idiot can understand it (even Java newbies) and 
> write helpers and custom actions.
>
> Anyway, using this web app along with #macro, #bean etc. I think WM 
> could definitely be a contender for the "webmaster scripting" market 
> occupied by PHP and ASP.
>
>
> ------------------------------------------------------------------------
>

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO