Re: [Webmacro-devel] WM WebApp design draft

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

On Mon, 20 Jan 2003 18:53:29 -0500, Eric B. Ridge <eb...@tc...> wrote:

>> 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.
>
> I don't really see the difference between "helpers" and ContextTools.   
> This came up a few weeks ago too.  Should we just change the  ContextTool 
> loading to also be able instantiate *any* object with a  zero-arg ctor?  
> Should we use #bean instead of ContextTools and  "helpers"?  Lane says 
> they're all different, but they look like the  same thing to me.

Well helpers require no changes to webmacro.properties. i.e. the config is 
a no-brainer and down to the application.

The application, in this case "WM webapp", would load a list of these 
helper classnames and a name to bind them to from a simple properties file 
or JNDI. i.e. no knowledge of webmacro.properties naming conventions etc. 
and using JNDI (if possible) you get web-based config of these with some 
servlet containers.

#bean is not the same - #bean requires a bit more understanding of pages 
and contexts etc. to do it properly. I like the K.I.S.S. principle :)

I've used this exact mechanism in antwmcompile and Lane hasn't complained 
about it so far... the beauty of "helpers" is that one instance is created 
and passed to all contexts. If you want per-page stuff you can add a 
factory method to the helper or use #bean... or implement a different 
HelperList implementation.
 What I want to do is make it so that WM is a "shrink wrapped" part of this 
webapp - so  no new webmacro.properties are specified etc and it just ships 
with the defaults. Advanced users can extra the WAR and add a 
webmacro.properties if they need to override more complex stuff.

It's all about keeping the barrier to entry as low as possible. 
Antwmcompile, for example, can be used by anybody who can write HTML and 
run a script (batch file) to do the build. Apart from the WM scripting 
language being used, they are effectively unaware that WM is there.

>> 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.
>
> Are actions .class files?  JavaScript (rhino rules!)?  WM  
> templates/#macro's?  Any of the above?

Well by default they are classes. As it is all abstracted, a custom 
ActionList could basically instantiate whatever it liked as long as it had 
an Action interface ... so you could defer to a javascript engine or 
whatever.

> PHP/ASP (and even JSP) take the old CGI approach where there is a 1:1  
> mapping between the URI and the script being executed.  Does this apply  
> here too?  Or are you thinking of something like:
> 	http://server.com/servlet/WMApp?template=search_results.wm
>
> instead of:
> 	http://server.com/search_results.wm

I'm pretty sure we can do both. It depends on your servlet container 
though.

> And what does this display?
> 	http://server.com/search_results.wm?template=logoff.wm

Again, should be fine if your servlet container supports it.

>> 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.
>
> Should #macro's be extended to allow return values?  Example:
>
> #macro getMyName () {
> #return "Eric"
> }
>
> #set $myName = #getMyName()
>
> Brian and Keats and I chatted about this a few times.  I don't think we  
> ever came to a good answer.
>
> If they could return values, they could act as Actions that #return an  
> $ActionResponse.
>
> I'm just thinking of (silly) ways to keep one from writing Java  classes. 
> One of those ideas is one I had awhile back for "WebMacro  Server Pages" 
> that went something like this:

I understand this... but we have to be cautious here because WM is not a 
general purpose language, and we should avoid using as one.

> --- search_results.wm --
>
> #script language="javascript" {
>
> 	Connection conn =  
> DriverManager.getConnection("jdbc:postgresql://server/ 
> db?user=postgres&password=postgres");
> 	Statement stmt = conn.createStatement("select * from books");
> ResultSst rs = stmt.executeQuery();
[snip]
> }
>
> --- / search_results.wm ---

I see what you're getting at, but YUCK. That's what WM was designed to 
avoid. Talk about WM ---> JSP convergence  
Noooooooooooooooooooooooooooooooo !

> The #script blocks would just be executed in-line as the template was  
> evaluated.  The "language" property could be any BSF compatible  language 
> (javascript, perl, python, whatever).  I mentioned this to  Brian once 
> and he said something like "uh, that breaks MVC".   :)    Nonetheless, 
> just throwing it out there as an idea.  You could  structure your script 
> snippets into little reusable blocks, wrap 'em in  #macro's, then do 
> something like:

I concur with Brian here. It's a horrible idea, in terms of WM's 
philosophy.

However, this BSF #script directive could be an optional directive.

I think the options for custom actions are pretty wide:

1. Write a simple Java class file. Trivial for java programmers. We can 
provide a tutorial about how to compile it all etc. After all, once you 
know how to create a .java file properly and compile it against the 
required libs, it's hardly different from writing javascript etc. - your 
code is just inside an existing method.

2. Use some of the many free Action implementations that will be available 
on the WM site - i.e. SendEmailAction, InsertIntoDatabaseAction, 
QueryDatabaseAction (using database connection from JNDI) and so on.

3. We could also make it so that templates could be used as actions too. 
This, coupled with the nasty #script idea would make it possible to do it 
all without writing Java code.

It's important to realise that I don't propose that this WM webapp be used 
for large-scale web applications. It is just aimed at people who want 
template-based sites with a bit more clever glue in them.

We have a fundamental problem putting any serious non-WM code/scripting 
into templates because of exception handling (or the lack thereof). 
Handling database exceptions cleanly when they happen during template 
processing is not fun. That's why I never do it... I always prepare data 
first, and that's what the Actions are supposed to do - but using something 
like templates with #script would likely provide a poor mechanism for 
handling such complicated error conditions cleanly.

Marc