the ssi mediator

[Martin van den Bemt <mv...@mvdb.com>]

Hi,

I've been browsing through the util package
(catalaina/src/share/org/apache/catalina/util/* ) for my preperation of
writing tests. I came acros the SsiMediator. All the ssi commands created
there override SsiMediator and SsiMediator adds all the commands to a
hashtable of the commands.
Isn't it wiser to set up a ssicommands.properties with eg :
config=org.apache.blah.blah

And make a instance from that class depending on that properties file.
This will make it more flexible and the "compile" dependencies on each ssi
command are gone..

Don't if this stuff is actualy used in tomcat 4 (and how to use it), but
just an idea..

We could also do this for the server variables (don't know if this is
subject to change though...

I'm happy to do the rewrite if I can test this ;-).

Mvgr,
Martin van den Bemt

Re: the ssi mediator

[Bip Thelin <bi...@razorfish.com>]

Martin van den Bemt wrote:
> 
> Hi,
> 
> I've been browsing through the util package
> (catalaina/src/share/org/apache/catalina/util/* ) for my preperation of
> writing tests. I came acros the SsiMediator. All the ssi commands created
> there override SsiMediator and SsiMediator adds all the commands to a
> hashtable of the commands.
> Isn't it wiser to set up a ssicommands.properties with eg :
> config=org.apache.blah.blah

Yes, I guess that would be a cleaner solution, however you could dispute what
you would actually gain from it. The mediator was created because the SsiCommands
needed to talk to each other at any given time. i.e. the config command could set
a errmsg which would then be used for every SsiCommand on that page.

> And make a instance from that class depending on that properties file.
> This will make it more flexible and the "compile" dependencies on each ssi
> command are gone..

There would still be dependencies, the config command could change how the
output would be for different tags and server variables.

> Don't if this stuff is actualy used in tomcat 4 (and how to use it), but
> just an idea..

It's used in Tomcat4, look in web.xml howto map it to a URL pattern.

> We could also do this for the server variables (don't know if this is
> subject to change though...
> 
> I'm happy to do the rewrite if I can test this ;-).

Remember that there are server variables that could be changed from the config
commands. If you have any thoughts, ideas, patches on how to clean up the Ssi code
and make it modular I'd be happy to review and commit it.


	..bip

Re: the ssi mediator

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 22 May 2001, Martin van den Bemt wrote:

> Hi,
> 
> I've been browsing through the util package
> (catalaina/src/share/org/apache/catalina/util/* ) for my preperation of
> writing tests. I came acros the SsiMediator. All the ssi commands created
> there override SsiMediator and SsiMediator adds all the commands to a
> hashtable of the commands.
> Isn't it wiser to set up a ssicommands.properties with eg :
> config=org.apache.blah.blah
> 
> And make a instance from that class depending on that properties file.
> This will make it more flexible and the "compile" dependencies on each ssi
> command are gone..
> 

It's certainly feasible to do something like this.

> Don't if this stuff is actualy used in tomcat 4 (and how to use it), but
> just an idea..
> 

Check out the "SsiInvokerServlet" that is in package
org.apache.catalina.servlets.  This is mapped by default to the
"*.shtml" file extension.

> We could also do this for the server variables (don't know if this is
> subject to change though...
> 
> I'm happy to do the rewrite if I can test this ;-).
> 

Feel free to send in patches to propose the changes you are interested in.

> Mvgr,
> Martin van den Bemt
> 
> 

Craig