Another possible way, I think, is to write your own transformers that e.g. do set the admininstrators e-mail address. These transformers could be initialized either via the sitemap in the components section or by reading its configuration data form an external file or database.
I imagine there are a hundred of other ways to solve your problem using Cocoon.
Helmut
On Tue, 1 Apr 2003 12:44:46 +0200, Leszek Gawron <[EMAIL PROTECTED]> wrote:
I started to learn web development some years ago with PHP. Up till now some
habits are still vivid. Some days ago I came up with a problem while
developing simple application with cocoon that I cannot overcome. If you ever
used php you should be familar with the way that PHP gives you a possibility
to customize a web application. The only PHP app I'm using now is MantisBT (a
bugtracker) so my explanation will be based on this one. Mantis contains a
configuration file called config_inc.php that contains the application options
you can change (there are really a lot of them - all config options take 40kB
of text). That file is included into every php script. The options configure
all aspects of web application. The examples are:
-application base url
-smtp host
-administrative options like
-should application present an option to sign up or not
-should user be able to reset his/hers password
-should email notification be enabled or not
-presentation options
-should menu bar be displayed at top of the page, bottom or maybe
both
-colors -available languages
-number of entries per page
The way described above is ok for a scripting language like PHP. Cocoon is not
so I started searching for the way to provide a user with a file with all
configuration options. We have different cocoon areas that we have to cover:
1. Data There is no problem if data is generated dynamically with XSP - you can use XMlFileModule and query configuration from external file
2. Logic If logicsheet is being used (or actions) one could also use input modules
to read configuration from
But then we end up with:
3. Presentation
If one wants to use XSL to present data the only way to parametrize the
stylesheet is to provide _ALL_ parameters in the sitemap. That is ok if
you have 4-5 parameters (you can pass them all using map:parameter and
sitemap is still quite readable). Imagine now you have 100 parameters that
strictly define presentation aspects. Another example: if you wanted to
parametrize administrator's email that could be shown in different
application pages you would have to pass this parameter to EVERY
stylesheet that renders it.
You could aggregate every static/dynamic data with a static configuration file
and then filter it out at last transformation but:
1. Is would not be nice for the performance
2. You would have to do a lot of XPath gymnastics
3. There still is a bug with caching pipelines and aggregated dynamic content.
It has been reported here:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16958 and here
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348
My idea: is it possible to modify the transformer so it could "see" all the
parameters without declaring them in sitemap? You just pass an input module
and it uses all variables it can query in it.
ouzo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
