You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bip Thelin <bi...@razorfish.com> on 2001/05/23 01:16:41 UTC

Re: the ssi mediator

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