You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Geoff Howard <co...@leverageweb.com> on 2002/12/19 00:32:08 UTC
current status of global input module / variables
Briefly if need be, what is the current status of this concept:
<map:component-configurations>
<global-variables>
<skin>cocoon</skin>
</global-variables>
</map:component-configurations>
as discussed a few months ago? I haven't been getting it to work. Is it
abandoned?
My use case:
I have several domains virtual hosted on my one cocoon instance and plan on
more. They are mounted off the root sitemap by means of a host matcher. As
a pre-blocks way of sharing some common behaviours i am experimenting with
mounting from each of those back to a directory at the context root:
in mounted sub-sitemap:
<map:match pattern="admin/content/edit/**">
<map:mount check-reload="yes" src="../edit/"
uri-prefix="admin/content/edit"/>
</map:match>
(side note: I wanted to use context:/edit instead of ../edit but couldn't
get it to work - any idea why?)
so that http://host1.com/admin/content/edit/ is handled by the same sitemap
as http://host2.com/admin/content/edit/.
It works, but now need to make some references back to resources relative to
the host-specific mounting sitemap, and that's where I hoped to have those
global input module values assigned in the sitemap.
Thanks,
Geoff Howard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, Dec 19, 2002, at 11:20 Europe/London, Christian Haul wrote:
> On 19.Dec.2002 -- 10:45 AM, Jeremy Quinn wrote:
>>
>> On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin
>> Piroumian
>> wrote:
>>
>>> From: "Geoff Howard" <co...@leverageweb.com>
>>>
>>>> Update: It works fine. I had to try so many different variations on
>>>> the
>>>> configuration first that I had gotten turned around.
>>>
>>> Strange... AFAIR, we've agreed to deprecate or even remove
>>> 'global-parameters' from the sitemap in favour of Input modules. I
>>> think
>>> that what you are looking for is the XMLModule. You'll find a sample
>>> in
>>> /webapp/samples/modules (C2.1-dev).
>>>
>>
>> Is it possible to use the XMLModule in such a way that values from the
>> XML conf file can be overridden by request parameters?
>>
>> I tried using Input Modules before, but always got strange errors from
>> the sitemap.
>
> Jeremy,
> if there are still problems, please let me know. I'm very interested
> in fixing any issues. If a module encounters problems, it usually just
> returns null and does not throw an exception. All debug messages end
> up in core.log. Most modules are quite verbose on their operation.
>
Thanks Chris, I'll let you know this time ;)
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 19.Dec.2002 -- 10:45 AM, Jeremy Quinn wrote:
>
> On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin Piroumian
> wrote:
>
> >From: "Geoff Howard" <co...@leverageweb.com>
> >
> >>Update: It works fine. I had to try so many different variations on
> >>the
> >>configuration first that I had gotten turned around.
> >
> >Strange... AFAIR, we've agreed to deprecate or even remove
> >'global-parameters' from the sitemap in favour of Input modules. I
> >think
> >that what you are looking for is the XMLModule. You'll find a sample in
> >/webapp/samples/modules (C2.1-dev).
> >
>
> Is it possible to use the XMLModule in such a way that values from the
> XML conf file can be overridden by request parameters?
>
> I tried using Input Modules before, but always got strange errors from
> the sitemap.
Jeremy,
if there are still problems, please let me know. I'm very interested
in fixing any issues. If a module encounters problems, it usually just
returns null and does not throw an exception. All debug messages end
up in core.log. Most modules are quite verbose on their operation.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Jeff Turner" <je...@apache.org>
> On Thu, Dec 19, 2002 at 03:09:22PM +0300, Konstantin Piroumian wrote:
> > From: "Jeremy Quinn" <je...@media.demon.co.uk>
> > > On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul
wrote:
> >
> > <snip-to-save-space-and-time />
> >
> > > >
> > > > which would result is {chain:other-var} being looked up as
> > > > {myxml:/root/section/other-var} and {request-param:other-var} but of
> > > > course {chain:my-var} would turn into {myxml:/root/section/my-var}
> > > > which is not desired here. SimpleMappingMetaModule supports some
more
> > > > mapping options if you need it.
> > > >
> > > > Chris.
> > >
> > >
> > > WOW! This stuff is amazing!
> > > And very complicated!
> >
> > Agree.
> > The mapping seems a little complicated to me. Can't we implement it a
little
> > different, something like that was proposed by Jeff Turner:
> >
> > <component-instance
> > class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> > logger="core.modules.input" name="chain">
> > <input-module name="request-param" />
> > <input-module name="myxml" map-to="/root/section/{0}"/>
> > </component-instance>
>
> What's implemented currently is flexible enough to support two models:
>
> 1) Each IM is defined separately:
>
> <component-instance
>
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
> logger="core.modules.mapper" name="mapper">
> <input-module name="site"/>
> <prefix>/site/</prefix>
> <suffix>/@href</suffix>
> </component-instance>
>
> <component-instance
> class="org.apache.cocoon.components.modules.input.XMLFileModule"
> logger="core.modules.xml" name="site">
> <reloadable>true</reloadable>
> <file src="cocoon://samples/link/linkmap"/>
> </component-instance>
>
> Here, both {site:/site/index/@href} and {mapper:index} will refer to the
> same node in the XML file generated by
> http://localhost:8080/samples/link/linkmap.
Great!
>
> (incidentally, isn't the fact that XMLFileModule can use cocoon: protocol
> incredibly cool?:)
Yes it's cool ;)
>
>
> 2) When a meta module 'uses' another module, it can override that
> module's configuration. For example, let's declare an unconfigured
> SimpleMappingMetaModule and configure it inside a ChainMetaModule:
>
>
> <component-instance
>
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
> logger="core.modules.mapper" name="chainmapper"/>
>
> component-instance
> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="mapped">
> <input-module name="request-param"/>
> <input-module name="request-attr"/>
> <input-module name="session-attr"/>
> <input-module name="chainmapper">
> <input-module name="site"/>
> <prefix>/site/</prefix>
> <suffix>/@href</suffix>
> </input-module>
> </component-instance>
>
> Again, {mapped:index} would refer to the same thing as
> {site:/site/index/@href}, unless, say, you added ?index=bob to the URL
> and the request-param kicked in to override it.
>
Fine!
> It's even possible to 'partially' configure a module in another one. Eg,
> the <input-module name="site"/> could be moved to the chainmapper
> definition.
Ok, you've both - Chris and Jeff - convienced me.
These thread could be a good source for a Wiki documentation on input
modules.
Listeners, are there any volunteer to write a summary? ;)
Konstantin
>
>
> I'm currently knee-deep in IMs implementing an
> InputModuleTransformer-based linking system for Forrest, after which I
> promise to help document this stuff (or rather, write lots and lots of
> examples).
>
>
> --Jeff
>
> > But of course, there's no much problems to use request parameters like
> > 'root/section/name'. This can cause a little troubles with JavaScript if
> > used as input element names.
> >
> > > Thank you very much for this explanation, I would not have groked
that!
> >
> > Yes, we need a more detailed documentation on modules, especially for
input
> > modules and their usage in the sitemap.
> >
> > Regards,
> > Konstantin
> >
> > >
> > > regards Jeremy
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Jeff Turner <je...@apache.org>.
On Thu, Dec 19, 2002 at 03:09:22PM +0300, Konstantin Piroumian wrote:
> From: "Jeremy Quinn" <je...@media.demon.co.uk>
> > On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
>
> <snip-to-save-space-and-time />
>
> > >
> > > which would result is {chain:other-var} being looked up as
> > > {myxml:/root/section/other-var} and {request-param:other-var} but of
> > > course {chain:my-var} would turn into {myxml:/root/section/my-var}
> > > which is not desired here. SimpleMappingMetaModule supports some more
> > > mapping options if you need it.
> > >
> > > Chris.
> >
> >
> > WOW! This stuff is amazing!
> > And very complicated!
>
> Agree.
> The mapping seems a little complicated to me. Can't we implement it a little
> different, something like that was proposed by Jeff Turner:
>
> <component-instance
> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="chain">
> <input-module name="request-param" />
> <input-module name="myxml" map-to="/root/section/{0}"/>
> </component-instance>
What's implemented currently is flexible enough to support two models:
1) Each IM is defined separately:
<component-instance
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
logger="core.modules.mapper" name="mapper">
<input-module name="site"/>
<prefix>/site/</prefix>
<suffix>/@href</suffix>
</component-instance>
<component-instance
class="org.apache.cocoon.components.modules.input.XMLFileModule"
logger="core.modules.xml" name="site">
<reloadable>true</reloadable>
<file src="cocoon://samples/link/linkmap"/>
</component-instance>
Here, both {site:/site/index/@href} and {mapper:index} will refer to the
same node in the XML file generated by
http://localhost:8080/samples/link/linkmap.
(incidentally, isn't the fact that XMLFileModule can use cocoon: protocol
incredibly cool?:)
2) When a meta module 'uses' another module, it can override that
module's configuration. For example, let's declare an unconfigured
SimpleMappingMetaModule and configure it inside a ChainMetaModule:
<component-instance
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
logger="core.modules.mapper" name="chainmapper"/>
component-instance
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input" name="mapped">
<input-module name="request-param"/>
<input-module name="request-attr"/>
<input-module name="session-attr"/>
<input-module name="chainmapper">
<input-module name="site"/>
<prefix>/site/</prefix>
<suffix>/@href</suffix>
</input-module>
</component-instance>
Again, {mapped:index} would refer to the same thing as
{site:/site/index/@href}, unless, say, you added ?index=bob to the URL
and the request-param kicked in to override it.
It's even possible to 'partially' configure a module in another one. Eg,
the <input-module name="site"/> could be moved to the chainmapper
definition.
I'm currently knee-deep in IMs implementing an
InputModuleTransformer-based linking system for Forrest, after which I
promise to help document this stuff (or rather, write lots and lots of
examples).
--Jeff
> But of course, there's no much problems to use request parameters like
> 'root/section/name'. This can cause a little troubles with JavaScript if
> used as input element names.
>
> > Thank you very much for this explanation, I would not have groked that!
>
> Yes, we need a more detailed documentation on modules, especially for input
> modules and their usage in the sitemap.
>
> Regards,
> Konstantin
>
> >
> > regards Jeremy
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 19.Dec.2002 -- 03:09 PM, Konstantin Piroumian wrote:
> From: "Jeremy Quinn" <je...@media.demon.co.uk>
> > On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
>
> <snip-to-save-space-and-time />
>
> > >
> > > which would result is {chain:other-var} being looked up as
> > > {myxml:/root/section/other-var} and {request-param:other-var} but of
> > > course {chain:my-var} would turn into {myxml:/root/section/my-var}
> > > which is not desired here. SimpleMappingMetaModule supports some more
> > > mapping options if you need it.
> > >
> > WOW! This stuff is amazing!
> > And very complicated!
>
> Agree.
> The mapping seems a little complicated to me. Can't we implement it a little
> different, something like that was proposed by Jeff Turner:
The mapping itself should not be difficult to understand, though: The
example I gave just prepends the string "/root/section/" to any
requested attribute name, just like the "/root/section/{0}" would do,
I guess. (But it also allows to append a string, remove prefixes and
suffixes plus use a mapping table)
> <component-instance
> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="chain">
> <input-module name="request-param" />
> <input-module name="myxml" map-to="/root/section/{0}"/>
> </component-instance>
The rationale here is that every module would need such mapping
facilities and a central place would be nicer. In addition, someone
might come up with a different mapping syntax (regexp or the above)
Now, two things happen here: the requested attribute name travels down
to the innermost module. Since every meta module has to hand the name
over, the name can be changed on every stage. Next, the innermost
module creates an object and hands it one stage up. On every stage
something is done with this object until it finally is returned to the
caller.
The nesting is not visible to the outside, thus hiding this complexity
and allowing to change the inner workings without affecting the result.
> But of course, there's no much problems to use request parameters like
> 'root/section/name'. This can cause a little troubles with JavaScript if
> used as input element names.
>
> > Thank you very much for this explanation, I would not have groked that!
>
> Yes, we need a more detailed documentation on modules, especially for input
> modules and their usage in the sitemap.
Which is a little difficult as it really depends on the module itself,
how to use it. I have tried to put enough into the javadocs to get one
started using a module, but obviously I am the wrong one to judge that
;-)
Hence a solution could be me answering questions and perhaps someone
could work that into a document of some sort.
(Or we could move such discussions to the wiki and send notifications
to the list.)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Jeremy Quinn" <je...@media.demon.co.uk>
> On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
<snip-to-save-space-and-time />
> >
> > which would result is {chain:other-var} being looked up as
> > {myxml:/root/section/other-var} and {request-param:other-var} but of
> > course {chain:my-var} would turn into {myxml:/root/section/my-var}
> > which is not desired here. SimpleMappingMetaModule supports some more
> > mapping options if you need it.
> >
> > Chris.
>
>
> WOW! This stuff is amazing!
> And very complicated!
Agree.
The mapping seems a little complicated to me. Can't we implement it a little
different, something like that was proposed by Jeff Turner:
<component-instance
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input" name="chain">
<input-module name="request-param" />
<input-module name="myxml" map-to="/root/section/{0}"/>
</component-instance>
But of course, there's no much problems to use request parameters like
'root/section/name'. This can cause a little troubles with JavaScript if
used as input element names.
> Thank you very much for this explanation, I would not have groked that!
Yes, we need a more detailed documentation on modules, especially for input
modules and their usage in the sitemap.
Regards,
Konstantin
>
> regards Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
> On 19.Dec.2002 -- 11:21 AM, Jeremy Quinn wrote:
>>
>> On Thursday, Dec 19, 2002, at 10:55 Europe/London, Konstantin
>> Piroumian
>> wrote:
>>
>>> From: "Jeremy Quinn" <je...@media.demon.co.uk>
>>>> On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin
>>>> Piroumian
>>>>> From: "Geoff Howard" <co...@leverageweb.com>
>>
>> <snip/>
>>
>>>> Is it possible to use the XMLModule in such a way that values from
>>>> the
>>>> XML conf file can be overridden by request parameters?
>>>
>>> Yes, that was the intention for creating the ChainMetaModule. See how
>>> it is
>>> configured in cocoon.xconf and add a similar configuration for your
>>> case.
>>>
>>
>> Something like this in cocoon.xconf? :
>>
>> <component-instance
>> class="org.apache.cocoon.components.modules.input.XMLFileModule"
>> logger="core.modules.xml" name="myxml">
>> <file src="context://my-conf.xml"/>
>> </component-instance>
>>
>> <component-instance
>> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
>> logger="core.modules.input" name="chain">
>> <input-module name="request-param"/>
>> <input-module name="myxml"/>
>> </component-instance>
>>
>>
>> Then how do you access the variables in the sitemap?
>> Like this?:
>>
>> {chain:/*/my-var} if I want it overridden by request params
>
> Assume that the parameter is named "my-var" and the my-conf.xml looks
> like
>
> <my-var>value</my-var>
>
> note: this is the only node.
>
> Then you'd access it through
>
> {chain:/my-var} or {chain:my-var}
>
> If a request parameter with the same name exists, it would be
> preferred over the value from the file.
>
>> and
>>
>> {myxml:/*/myvar} if I do not want an override?
>
> Yes, {myxml:/myvar} or {myxml:myvar} in this case.
>
> So, if your my-conf.xml looks like
>
> <root>
> <my-var>value</my-var>
> <section>
> <other-var>value</other-var>
> </section>
> </root>
>
> it would be {chain:root/section/other-var} and the request parameter
> would need to be "root/section/other-var". If you don't like that,
> consider adding the SimpleMappingMetaModule around the myxml in the
> chain config: (I assume that the component has been declared as
> simple-map)
>
> <component-instance
> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="chain">
> <input-module name="simple-map">
> <prefix>/root/section/</prefix>
> <input-module name="request-param"/>
> </input-module>
> <input-module name="myxml"/>
> </component-instance>
>
> which would result is {chain:other-var} being looked up as
> {myxml:/root/section/other-var} and {request-param:other-var} but of
> course {chain:my-var} would turn into {myxml:/root/section/my-var}
> which is not desired here. SimpleMappingMetaModule supports some more
> mapping options if you need it.
>
> Chris.
WOW! This stuff is amazing!
And very complicated!
Thank you very much for this explanation, I would not have groked that!
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 19.Dec.2002 -- 11:21 AM, Jeremy Quinn wrote:
>
> On Thursday, Dec 19, 2002, at 10:55 Europe/London, Konstantin Piroumian
> wrote:
>
> >From: "Jeremy Quinn" <je...@media.demon.co.uk>
> >>On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin
> >>Piroumian
> >>>From: "Geoff Howard" <co...@leverageweb.com>
>
> <snip/>
>
> >>Is it possible to use the XMLModule in such a way that values from the
> >>XML conf file can be overridden by request parameters?
> >
> >Yes, that was the intention for creating the ChainMetaModule. See how
> >it is
> >configured in cocoon.xconf and add a similar configuration for your
> >case.
> >
>
> Something like this in cocoon.xconf? :
>
> <component-instance
> class="org.apache.cocoon.components.modules.input.XMLFileModule"
> logger="core.modules.xml" name="myxml">
> <file src="context://my-conf.xml"/>
> </component-instance>
>
> <component-instance
> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="chain">
> <input-module name="request-param"/>
> <input-module name="myxml"/>
> </component-instance>
>
>
> Then how do you access the variables in the sitemap?
> Like this?:
>
> {chain:/*/my-var} if I want it overridden by request params
Assume that the parameter is named "my-var" and the my-conf.xml looks
like
<my-var>value</my-var>
note: this is the only node.
Then you'd access it through
{chain:/my-var} or {chain:my-var}
If a request parameter with the same name exists, it would be
preferred over the value from the file.
> and
>
> {myxml:/*/myvar} if I do not want an override?
Yes, {myxml:/myvar} or {myxml:myvar} in this case.
So, if your my-conf.xml looks like
<root>
<my-var>value</my-var>
<section>
<other-var>value</other-var>
</section>
</root>
it would be {chain:root/section/other-var} and the request parameter
would need to be "root/section/other-var". If you don't like that,
consider adding the SimpleMappingMetaModule around the myxml in the
chain config: (I assume that the component has been declared as simple-map)
<component-instance
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input" name="chain">
<input-module name="simple-map">
<prefix>/root/section/</prefix>
<input-module name="request-param"/>
</input-module>
<input-module name="myxml"/>
</component-instance>
which would result is {chain:other-var} being looked up as
{myxml:/root/section/other-var} and {request-param:other-var} but of
course {chain:my-var} would turn into {myxml:/root/section/my-var}
which is not desired here. SimpleMappingMetaModule supports some more
mapping options if you need it.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, Dec 19, 2002, at 10:55 Europe/London, Konstantin Piroumian
wrote:
> From: "Jeremy Quinn" <je...@media.demon.co.uk>
>> On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin
>> Piroumian
>>> From: "Geoff Howard" <co...@leverageweb.com>
<snip/>
>> Is it possible to use the XMLModule in such a way that values from the
>> XML conf file can be overridden by request parameters?
>
> Yes, that was the intention for creating the ChainMetaModule. See how
> it is
> configured in cocoon.xconf and add a similar configuration for your
> case.
>
Something like this in cocoon.xconf? :
<component-instance
class="org.apache.cocoon.components.modules.input.XMLFileModule"
logger="core.modules.xml" name="myxml">
<file src="context://my-conf.xml"/>
</component-instance>
<component-instance
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input" name="chain">
<input-module name="request-param"/>
<input-module name="myxml"/>
</component-instance>
Then how do you access the variables in the sitemap?
Like this?:
{chain:/*/my-var} if I want it overridden by request params
and
{myxml:/*/myvar} if I do not want an override?
Thanks for your help.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Jeremy Quinn" <je...@media.demon.co.uk>
> On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin Piroumian
> > From: "Geoff Howard" <co...@leverageweb.com>
> >
> >> Update: It works fine. I had to try so many different variations on
> >> the
> >> configuration first that I had gotten turned around.
> >
> > Strange... AFAIR, we've agreed to deprecate or even remove
> > 'global-parameters' from the sitemap in favour of Input modules. I
> > think
> > that what you are looking for is the XMLModule. You'll find a sample in
> > /webapp/samples/modules (C2.1-dev).
> >
>
> Is it possible to use the XMLModule in such a way that values from the
> XML conf file can be overridden by request parameters?
Yes, that was the intention for creating the ChainMetaModule. See how it is
configured in cocoon.xconf and add a similar configuration for your case.
>
> I tried using Input Modules before, but always got strange errors from
> the sitemap.
Now they work (at least was working a couple of days ago) and there is a
sample at /cocoon/samples/modules/.
Suggestions and comments are welcome.
Regards,
Konstantin
P.S. Carsten committed something like a property container today and it
looks very similar to ChainMetaModule, though I have no idea what are the
differences.
>
>
> Thanks for any help.
>
> regards Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin Piroumian
wrote:
> From: "Geoff Howard" <co...@leverageweb.com>
>
>> Update: It works fine. I had to try so many different variations on
>> the
>> configuration first that I had gotten turned around.
>
> Strange... AFAIR, we've agreed to deprecate or even remove
> 'global-parameters' from the sitemap in favour of Input modules. I
> think
> that what you are looking for is the XMLModule. You'll find a sample in
> /webapp/samples/modules (C2.1-dev).
>
Is it possible to use the XMLModule in such a way that values from the
XML conf file can be overridden by request parameters?
I tried using Input Modules before, but always got strange errors from
the sitemap.
Thanks for any help.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: current status of global input module / variables
Posted by Geoff Howard <co...@leverageweb.com>.
Wow, I need to get on European time. I miss all the fun while I'm asleep.
I was in a hurry to write before, so I've added clarification below:
> -----Original Message-----
> From: Konstantin Piroumian [mailto:kpiroumian@apache.org]
> Sent: Thursday, December 19, 2002 4:15 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: current status of global input module / variables
>
>
> From: "Geoff Howard" <co...@leverageweb.com>
>
> > Update: It works fine. I had to try so many different variations on the
> > configuration first that I had gotten turned around.
>
> Strange... AFAIR, we've agreed to deprecate or even remove
> 'global-parameters' from the sitemap in favour of Input modules. I think
> that what you are looking for is the XMLModule. You'll find a sample in
> /webapp/samples/modules (C2.1-dev).
Yes, 'global-parameters' was removed (possibly twice if I understand the
archive correctly!) and replaced with the GlobalInputModule implementation,
which can be given values in the
sitemap with the appropriate name: global-variables inside
map:component-configurations like authentication-manager. Here's the
snippet that's working for me in my sitemap as we speak (last updated from
cvs around Dec. 7):
<map:pipelines>
<map:component-configurations>
<global-variables>
<mount-dir>leverage</mount-dir>
</global-variables>
<authentication-manager>
<handlers>
<handler name="provAdmin">
<redirect-to uri="cocoon:/login"/>
<authentication uri="cocoon:raw:/authenticate"/>
</handler>
</handlers>
</authentication-manager>
</map:component-configurations>
...
and in the sitemap mounted by each of the host-specific sitemaps I described
in my original message, the variable is inherited "polymorpically" so to
speak so that a reference to {global:mount-dir} is assigned a different
value
in the shared sitemap depending on which context it's called in.
It works great, is very cool, please don't say it's going away.
> > I'd volunteer to submit a snippet or wiki entry on this, but wasn't sure
> > this feature/syntax was going to last based on the discussions from
> october.
> > Anyone have a problem with making this more visible?
>
> Not sure about the map:component-configurations though. Let's see what
> others think.
I've expected that the syntax may change, and that component definition may
go away
(referring to the undocumented ability to define components in the sitemap)
but what
is crucial is the ability to achieve 1) the definition specific to a sitemap
(and
probably therefore in the sitemap) and 2) inheritance, or at very least a
way to
reference the value defined by the preceding sitemap.
(OT Wish: I have wished for a way to refer to the previous sitemap with the
cocoon:
protocol // gets you all the way back and slash refers to the one you're in,
but
there's no way to refer to the mount-er unless it happens to be the root
sitemap.)
>
> Konstantin
>
Thanks for getting back,
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: current status of global input module / variables
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Geoff Howard" <co...@leverageweb.com>
> Update: It works fine. I had to try so many different variations on the
> configuration first that I had gotten turned around.
Strange... AFAIR, we've agreed to deprecate or even remove
'global-parameters' from the sitemap in favour of Input modules. I think
that what you are looking for is the XMLModule. You'll find a sample in
/webapp/samples/modules (C2.1-dev).
>
> I'd volunteer to submit a snippet or wiki entry on this, but wasn't sure
> this feature/syntax was going to last based on the discussions from
october.
> Anyone have a problem with making this more visible?
Not sure about the map:component-configurations though. Let's see what
others think.
Konstantin
>
> Geoff
>
> > -----Original Message-----
> > From: Geoff Howard [mailto:cocoon@leverageweb.com]
> > Sent: Wednesday, December 18, 2002 6:32 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: current status of global input module / variables
> >
> >
> > Briefly if need be, what is the current status of this concept:
> >
> > <map:component-configurations>
> > <global-variables>
> > <skin>cocoon</skin>
> > </global-variables>
> > </map:component-configurations>
> >
> > as discussed a few months ago? I haven't been getting it to work. Is
it
> > abandoned?
> >
> > My use case:
> > I have several domains virtual hosted on my one cocoon instance
> > and plan on
> > more. They are mounted off the root sitemap by means of a host
> > matcher. As
> > a pre-blocks way of sharing some common behaviours i am experimenting
with
> > mounting from each of those back to a directory at the context root:
> >
> > in mounted sub-sitemap:
> > <map:match pattern="admin/content/edit/**">
> > <map:mount check-reload="yes" src="../edit/"
> > uri-prefix="admin/content/edit"/>
> > </map:match>
> >
> > (side note: I wanted to use context:/edit instead of ../edit but
couldn't
> > get it to work - any idea why?)
> >
> > so that http://host1.com/admin/content/edit/ is handled by the
> > same sitemap
> > as http://host2.com/admin/content/edit/.
> >
> > It works, but now need to make some references back to resources
> > relative to
> > the host-specific mounting sitemap, and that's where I hoped to have
those
> > global input module values assigned in the sitemap.
> >
> > Thanks,
> > Geoff Howard
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: current status of global input module / variables
Posted by Geoff Howard <co...@leverageweb.com>.
Update: It works fine. I had to try so many different variations on the
configuration first that I had gotten turned around.
I'd volunteer to submit a snippet or wiki entry on this, but wasn't sure
this feature/syntax was going to last based on the discussions from october.
Anyone have a problem with making this more visible?
Geoff
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Wednesday, December 18, 2002 6:32 PM
> To: cocoon-dev@xml.apache.org
> Subject: current status of global input module / variables
>
>
> Briefly if need be, what is the current status of this concept:
>
> <map:component-configurations>
> <global-variables>
> <skin>cocoon</skin>
> </global-variables>
> </map:component-configurations>
>
> as discussed a few months ago? I haven't been getting it to work. Is it
> abandoned?
>
> My use case:
> I have several domains virtual hosted on my one cocoon instance
> and plan on
> more. They are mounted off the root sitemap by means of a host
> matcher. As
> a pre-blocks way of sharing some common behaviours i am experimenting with
> mounting from each of those back to a directory at the context root:
>
> in mounted sub-sitemap:
> <map:match pattern="admin/content/edit/**">
> <map:mount check-reload="yes" src="../edit/"
> uri-prefix="admin/content/edit"/>
> </map:match>
>
> (side note: I wanted to use context:/edit instead of ../edit but couldn't
> get it to work - any idea why?)
>
> so that http://host1.com/admin/content/edit/ is handled by the
> same sitemap
> as http://host2.com/admin/content/edit/.
>
> It works, but now need to make some references back to resources
> relative to
> the host-specific mounting sitemap, and that's where I hoped to have those
> global input module values assigned in the sitemap.
>
> Thanks,
> Geoff Howard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org