[Webmacro-devel] WM WebApp design draft

[Marc P. <ma...@an...>]

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.

-- 
Marc Palmer