Re: [Webmacro-devel] WM 2.0 strategy

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

On Mon, 16 Jun 2003 00:25:17 -0400, Harmeet Bedi <ha...@ko...> 
wrote:

> - Precompiled/Optimized templates: A mode to generate java code and 
> classes
> from wm files would be good. One example is jython. It is interpretted,
> there can be a pool of interpretters to execute code but it has a tool to
> generate java source and class files. I would like to use WM like
> precompiled JSP files and not put wm source code on production server. I
> would also like to profile these end precompiled templates and see if 
> there
> are any bottlenecks. For instance if a precompiled template does not have
> any shared state and no need to reload, should ideally have no 
> synchronized
> calls.

Like Brian I think this is a bad idea. Generating (or compiling) code is 
not a good plan for template-based scripting. It complicates things and you 
just have to do almost exactly the same things - iterate over the syntax 
tree etc.

You might benefit from some compile-time optimisations but like Brian I 
doubt it would be significant.

> - Sandbox. I realize that WM templates depends only on model, but it 
> would
> be nice to make the view as tight as possible, for instance if I need to
> exposed, HttpServerletRequest object to WM, would it be better to instead
> expose a ServletRequest Object inside a wrapper and allow server
> administrator to control what can or cannot be invoked. Some support for
> sandoxing say by automatically creating proxies and tying permissions to
> user roles may be helpful. I don't have any concrete ideas but if you 
> could
> keep security/safety as you add more features that would be awesome.

Now this is quite an interesting idea that I quite like, having felt quite 
strongly about this in the past. For example, we've all done this:

   context.put( "myVar", myHashtable);

Even though the data in the Hashtable should be immutable. Sure there's 
Collections.unmodifiableMap(myHashtable) but it's still ugly.

There's also the problem of providing runtime help information for template 
writers, tackled to a large degree by my Ignition webapp. We could solve 
both of these problems in one go, very simply:

 * Add an option to WM for "StrictJavaClasses" mode. (and 
"StrictJavaClassesExcludes=")
 * Add a flagging interface called something like WMScriptSafe

When "StrictJavaClasses" is true, WM would throw an exception if any object 
is put into the context that does not  implement the (empty) interface 
WMScriptSafe. This immediately forces the programmer to realise that they 
need to make a decision about what they are doing. It stops 
HttpServletRequest being put in but allows WMSafeHttpServletRequest being 
put in, which would expose only certain properties etc.
 In addition to this, WM could provide a mechanism to show introspected 
help information about any objects placed into the context (#help ?) that 
implemenet WMScriptSafe, looking for the BeanInfo of the script-safe object 
- i.e. WMSafeHttpServletRequestBeanInfo.

By having the flagging interface we are forcing people to implement a new 
class that wraps non-safe classes, therefore giving them the ability to 
implement a BeanInfo object that can provide documentation that WM template 
writers can understand - instead of any existing "Java programmer" BeanInfo 
provided on the original bean.

Granted, not that many people use BeanInfo, but it's an under-used facility 
if you ask me. We use it to great effect in Ignition. Take any existing 
Bean and you can use it as a helper in WM, and if the Bean has a BeanInfo 
impl, you get to see all the help info about it. No special interfaces to 
implement.

> - Safe. Loops and cyclic loops can be written in JSP. With webmacro it is
> very hard. I use 1.0 with constraints on include directive to control
> looping( I only allow templates in subfolders and no url include). WM
> Templates should not be able to bring server down, either by intent or by
> coding error. Of course this does depend on exposed model, but if model 
> is
> safe, templates should be safe too. I think this can be done by making 
> some
> changes to tools in 1.0 and Include directive. In later versions my
> impression was that macros can cause loops. If this is true, from safety
> perspective it may not be a step forward.

I don't see how #include can bring the server down. You get a 
StackOverflowError before the server comes down. Same with infinite loops.

Recursive #include or #templet (when we get that) would have the same 
outcome, a stack overflow which just kills the current page render, not the 
whole container.

It is possible to create infinite loops in WM but not using WMScript. You 
could for example add a context variable that is an Iterator, which is 
badly implemented and continuously returns the same element, never 
stopping.

There's nothing we can do about that.

Best wishes,
Marc

-- 
Marc Palmer
Contract Java Consultant/Developer

http://www.anyware.co.uk/marc/
http://www.wangjammers.org