Re: [Webmacro-devel] WM WebApp design draft

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

>> Am I on the nail now?
>
> Yeah. You let the template author control the expert action flow. Not the 
> servlet writer. In this case, the action control flow is delegated to a 
> template writer's expert knowledge of the action flow, rule base. The 
> programmer writes the ugly stuff like transaction commits, etc.

OK, the only thing I don't like about this is using WM as a general purpose 
language. We don't have all the syntax and capabilities of a "full" 
language as well as the WM philosophy consideration that it's just for 
presentation.

Is this really necessary anyway? I mean, a template will expose links to a 
bunch of actions so the user clicks on them / submits forms. These will 
execute the appropriate action, and return the appropriate response.

Actions will be able to support some kind of "nextAction" parameter that 
indicates what should happen next after the Action executes.

i.e. an InsertIntoDatabaseAction might look for the nextAction parameter 
and use some supplied mechanism to execute that action after the insert. If 
the nextAction parameter is not present, it could just return a results 
template with the new database contents. (for example)

I can't see how the business rules of an application can be cleanly coded 
into a WM template (or main template plus included parts). Wouldn't it be 
really ugly?

One thing I am planning to add to the idea is a default helper for 
generating URIs to execute actions, so the template need not know the 
details of "hidden" parameter names and so on. This concept could be 
extended to support creating a single URI that will result in the execution 
of several actions i.e:

<FORM METHOD=POST ACTION="$WebMacro.executeActions( ["insertIntoDB", 
"commitToDB", "queryDB"])">
...hidden fields containing parameters such as table name and fields....
...visible data fields...
</FORM>

This function would make a pretty complex long URI, or put the info into 
the session and return a short URI that identifies the info in the session 
so the servlet can retrieve it and work out what actions to execute.

This would make things quite modular and allow actions to be stacked - 
writing to a DB and then emailing the data for example - with the proviso 
that all the info necessary to perform all actions must be available in the 
first request. We could allow per-action parameters to be supplied too:

<FORM METHOD=POST ACTION="$WebMacro.executeActions( 
["insertIntoDB:table=testdata", "commitToDB", "queryDB:sqlselect='SELECT * 
FROM testdata',template='dataresults.wmt'"])">

As every, thoughts welcome... but I really don't believe this webapp will 
be the cure for all web application needs... just enough for 90% of 
websites, and at the very least a much better replacement for server side 
includes and related technologies.

Marc