RE: current status of global input module / variables
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:[EMAIL PROTECTED]]
> Sent: Thursday, December 19, 2002 4:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: current status of global input module / variables
>
>
> From: "Geoff Howard" <[EMAIL PROTECTED]>
>
> > 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):
leverage
...
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
From: "Jeff Turner" <[EMAIL PROTECTED]>
> On Thu, Dec 19, 2002 at 03:09:22PM +0300, Konstantin Piroumian wrote:
> > From: "Jeremy Quinn" <[EMAIL PROTECTED]>
> > > On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul
wrote:
> >
> >
> >
> > > >
> > > > 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:
> >
> > > class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> > logger="core.modules.input" name="chain">
> >
> >
> >
>
> What's implemented currently is flexible enough to support two models:
>
> 1) Each IM is defined separately:
>
>
class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
> logger="core.modules.mapper" name="mapper">
>
> /site/
> /@href
>
>
>class="org.apache.cocoon.components.modules.input.XMLFileModule"
> logger="core.modules.xml" name="site">
> true
>
>
>
> 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:
>
>
>
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">
>
>
>
>
>
> /site/
> /@href
>
>
>
> 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 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
On Thu, Dec 19, 2002 at 03:09:22PM +0300, Konstantin Piroumian wrote:
> From: "Jeremy Quinn" <[EMAIL PROTECTED]>
> > On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
>
>
>
> > >
> > > 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:
>
>class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="chain">
>
>
>
What's implemented currently is flexible enough to support two models:
1) Each IM is defined separately:
/site/
/@href
true
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.ChainMetaModule"
logger="core.modules.input" name="mapped">
/site/
/@href
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 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
On 19.Dec.2002 -- 03:09 PM, Konstantin Piroumian wrote:
> From: "Jeremy Quinn" <[EMAIL PROTECTED]>
> > On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
>
>
>
> > >
> > > 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)
>class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="chain">
>
>
>
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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
From: "Jeremy Quinn" <[EMAIL PROTECTED]>
> On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
> >
> > 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:
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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
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" <[EMAIL PROTECTED]>
On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin
Piroumian
From: "Geoff Howard" <[EMAIL PROTECTED]>
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? :
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
value
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
value
value
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)
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input" name="chain">
/root/section/
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
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" <[EMAIL PROTECTED]>
> >>On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin
> >>Piroumian
> >>>From: "Geoff Howard" <[EMAIL PROTECTED]>
>
>
>
> >>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? :
>
>class="org.apache.cocoon.components.modules.input.XMLFileModule"
> logger="core.modules.xml" name="myxml">
>
>
>
>class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input" name="chain">
>
>
>
>
>
> 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
value
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
value
value
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)
/root/section/
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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
On Thursday, Dec 19, 2002, at 10:55 Europe/London, Konstantin Piroumian
wrote:
From: "Jeremy Quinn" <[EMAIL PROTECTED]>
On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin
Piroumian
From: "Geoff Howard" <[EMAIL PROTECTED]>
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? :
class="org.apache.cocoon.components.modules.input.XMLFileModule"
logger="core.modules.xml" name="myxml">
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input" name="chain">
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
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" <[EMAIL PROTECTED]> > > > >>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 [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
From: "Jeremy Quinn" <[EMAIL PROTECTED]> > On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin Piroumian > > From: "Geoff Howard" <[EMAIL PROTECTED]> > > > >> 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
On Thursday, Dec 19, 2002, at 09:14 Europe/London, Konstantin Piroumian wrote: From: "Geoff Howard" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: current status of global input module / variables
From: "Geoff Howard" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED]] > > Sent: Wednesday, December 18, 2002 6:32 PM > > To: [EMAIL PROTECTED] > > Subject: current status of global input module / variables > > > > > > Briefly if need be, what is the current status of this concept: > > > > > > > > cocoon > > > > > > > > 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: > > > > > uri-prefix="admin/content/edit"/> > > > > > > (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: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: current status of global input module / variables
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:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 6:32 PM > To: [EMAIL PROTECTED] > Subject: current status of global input module / variables > > > Briefly if need be, what is the current status of this concept: > > > > cocoon > > > > 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: > > uri-prefix="admin/content/edit"/> > > > (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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
