Re: [Webmacro-devel] Some WM PR stuff

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

> ebr has been a terrific asset to wm but wm is a jewel to which many,
> many have added countless hours and to which others continue to add th=
e
> fruits of their knowledge.

Hey... you took my "us lazy people" too seriously Lane! I know full well=
=20
many people have worked on it. I was referring to putting together the=20=

release though, rather than doing all the coding :-)

> now.... as to your offer below. I, for one, think it would be marvelou=
s
> if you would produce a slick pdf press release. I think you should add=

> photos of the main contributors as well as their locations on the bott=
om
> in the section "for contact information". This would give the press
> release some pizazz and substance. Put real people behind the wm
> community. Also, I think it would be a good idea to develop on our wik=
i
> site, a list of contacts for pr purposes. I will add some names from m=
y
> file.

Well I could produce a PDF release, but I don't think this will work for=
=20
the online sites. The sites I am planning to target will just want a=20=

plain text release they can paste into their site =96 it's what they've =

done with everything else.

Online sites are our main target... and the key with press is to make it=
=20
a no-brainer for them to include your content on their site.

> as to the web project, my thinking follows along these lines which I
> think are close to yours.

> a) a general purpose plug-in servlet which has some lifecyle methods
> specific to webMacro and good servlet design:
> installWMPlugins(); //on init, read the plugin property list (in
> dependency order!), initialize
> getUser(); // adapter method to get user object making request
> authenticate(); // adapter method to authenticate user for this reques=
t,
> if required
> authorize(); // adapter method to authorize user for this request, if=

> required
> refreshWMPlugins(); // a call back to the servlet to refresh the
> services installed
> addWMPlugin(); // allow a plugin to be added dynamically
> removeWMPlugin(); // allow a plugin to be removed dynamically
> dispatchRequest(); // dispatch the request object returning a template=

> evaluateTemplate(); // evaluate the template and return a completed pa=
ge
> for sending.

I assume you mean here that a servlet with this design would work "out o=
f=20
the box" but would also work as a base class for developers' own=20
servlets.

> Instead of loading plugins and objects from a properties file, I
> strongly urge the use of a webmacro template file so as to benefit fro=
m
> caching and the ability to create a list, not a map of plugins to
> initialize. To your thinking, how is a plugin different from a context=
=20
tool?

Um, not at all. I just mean an object to put into the page context. Nice=
=20
and simple stuff.

We could of course use the ActionServlet concept and allow setup of=20
custom action objects to handle specific requests with more complex=20
behaviour than just returning a template.

> b) plug-in contributions. Each of us could contribute some plugins fro=
m
> our APIs. I can add some physical-independent storage for authenticati=
on
> and authorization.

Yep! SQL helpers, XML helpers, RSS helpers etc. would all be fantastic. =

If we have something like this in WM 1.2 then we can expect to get a muc=
h=20
larger audience (amongst the Freshmeat crowd etc.) and then hopefully th=
e=20
list of plugins/helpers will grow.

I think we should settle on a specific name for this =96 plugin or helpe=
r=20
for example, rather than context tool.

How about:

Handler ("Request Handler") =96 a "plugin" object that handles requests =

with a certain "action" value

Plugin =96 an object placed in to the page context.

Any more thoughts on this?

Best wishes,
Marc