[Webmacro-devel] Re: [WebMacro-user] NextRelease

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

On Thu, 10 Apr 2003 08:52:01 -0700, Lane Sharman <la...@op...> 
wrote:

> Following on the recent thread.
>
> http://www.webmacro.org/NextRelease is where you should dump stuff that 
> you think ought to be a relatively agreed to idea. If it is voted off, 
> here is where to make it known that you want it off.

Great stuff Lane.

> Plugin Friendly
> With the above in mind, I propose making WM plugin-friendly so the likes 
> of Marc can see how their distros and frameworks get produced and what 
> standard exists to be a rightful "WM Plugin".

I'm not entirely sure what you're getting at here, but it sounds good.

Something I am coming across now is that there is overlap in terms of 
"helper classes" between my forthcoming general-use WM webapp and general 
WM usage.

As such, I think we should look at a way of presenting the "optional 
helpers" for WM as a separate source tree (org.webmacro.helpers.xxxx) 
containing "approved" general purpose helpers. The "unapproved" stuff would 
still stay in /contrib

This would be a bit like ANT's core tasks and optional tasks. I think you 
should be able to download a WM binary that will run as is with minimum 
frills (just the core directives) and if you also download 
WebMacroPlusPack.jar or similar, and put it on your classpath, you will get 
all the great extra directives and helper classes people have written.

The key thing is that as many of these "helpers" should work as both 
ContextTools -or-normal classes just placed into the context by an 
application.

For example, the optional add-on jar might include:

* A Date helper class(should work as either) you can put use to create and 
manipulate dates. I have some starter code for this.

* A filesystem helper class - for traversing a local filesystem (again I 
have starter code for this)

* A simplified XML traversal helper. We have code for this too we can 
contribute.

...and any other useful self-contained helper classes and general purpose 
(i.e. not "niche") directives.

This jar would work well with my webapp design you see - you could leverage 
the same tools from standard WM in this app. Right now I'm adding helpers 
to this webapp's source tree that really should be somewhere else for 
everybody to use in WM apps.

> Storage
> I think we need storage directives that implementors can implent to 
> load/save objects into a context from a store and back.
>
> The last one will raise a lot of hackles. Tough. I need it and I know 
> there are some others who need it in the context of general WM 
> processing.

Hehe :-)

I don't understand why you want this as a directive. Why not just do it as 
a context tool / helper? Why do you need to do it as a directive? There's 
minor syntactic sugar agreed, but is it worth "restricting" the code to 
usage as a directive?

As long as it's not a core directive, I won't complain :-)

-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants