You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/04/16 05:34:39 UTC
[c2] simple sitemap question
i'd like to have a conditional stylesheet in my sitemap. here's my default
pipeline:
<map:match pattern="*">
<map:generate src="content/{1}.xml" type="serverpages"/>
<map:transform src="style/{1}.xsl"/>
<map:transform src="style/wziml-html.xsl"/>
<map:serialize/>
</map:match>
problem is, the first stylesheet doesn't necessarily always exist. i'd
like to check for its existence and only if exists, put the transformation
in the pipeline. someone got a clue for me?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Complimentary vs. Complementary
Posted by Berin Loritsch <bl...@apache.org>.
Hans Ulrich Niedermann wrote:
>
> Hi,
>
> when reading the discussion about
> AbstractComplimentaryConfigurableAction I was slightly confused about
> the name. I looked up the words "complementary" and "complimentary" in
> the dictionary and came to the conclusion that probably someone
> misspelled the name of the class.
>
> Should that indeed be the case, I suggest renaming the class to
> AbstractComplementaryConfigurableAction to lessen the confusion about
> its name somewhat.
Yep.. Will do.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Complimentary vs. Complementary
Posted by Hans Ulrich Niedermann <nd...@n-dimensional.de>.
Hi,
when reading the discussion about
AbstractComplimentaryConfigurableAction I was slightly confused about
the name. I looked up the words "complementary" and "complimentary" in
the dictionary and came to the conclusion that probably someone
misspelled the name of the class.
Should that indeed be the case, I suggest renaming the class to
AbstractComplementaryConfigurableAction to lessen the confusion about
its name somewhat.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] Complimentory Configuration (Was: simple sitemap question)
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
> I've taken a deeper look into the Actions for the Employee stuff. I'd
> suggest the following:
>
> If the complimentary configuration you'd like to offer to an Action is
> static over its lifetime you do:
>
> <map:action name="add-employee"
> src="org.apache.cocoon.acting.DatabaseAddAction">
> <complimentary-configuration
> file="context://docs/samples/forms/employee.xml"/>
> </map:action>
>
> in the <map:components> <map:actions> section. Then you need to make
> your Action Configurable and you receive the Configuration that way.
>
> If you need to pass different information to the same Action (because it
> is used in different pipelines or passed values replaced by the sitemap)
> then use the parameter like you've done in the employee samples.
>
> After all, my comment on the employee samples is that the Actions there
> are best extended with the Configurable interface and the complimentary
> configuration is parsed/read at instantiation time once and not for
> every invocation of the act method.
>
> Does this makes sense?
It makes sense, but I don't entirely like it. Let me explain what happens:
You specify one "add-to-database" action for all forms on the system. The
sitemap will pass the parameter to the action. The Complimentary Configuration
engine reads the file ONCE, and converts it to a Configuration object.
Any action (extending AbstractComplimentaryConfigurableAction) that
says it needs the file receives the configuration object. The file is
never reparsed. There really is no overhead other than a small amount of
memory. Using that approach, we can have one action where the mapping
file is specified by another action.
<map:act type="form-engine">
<map:act type="add-to-database">
<parameter name="map-file" value="{form-process}"/>
</map:act>
</map:act>
The database example isn't the best in this approach, however, specifying the
map file in the initial configuration is messy to me.
I have a process where I need to perform additions in steps. I would rather
specify one action and pass a different configuration to it than have to specify
20 different actions (same class, different file) and have to remember what
class-type maps to what file.
The approach I used was the most usable to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by giacomo <gi...@apache.org>.
On Wed, 18 Apr 2001, Berin Loritsch wrote:
> giacomo wrote:
> >
> > On Wed, 18 Apr 2001, Berin Loritsch wrote:
> >
> > > giacomo wrote:
> > > >
> > > > On Tue, 17 Apr 2001, Donald Ball wrote:
> > > >
> > > > > On Mon, 16 Apr 2001, Berin Loritsch wrote:
> > > > >
> > > > > > The AbstractComplimentaryConfigurableAction (though the name is confusing)
> > > > > > is used when you have a Configuration file that you want to load separately
> > > > > > from the Sitemap. The Sitemap configuration is not flexible enough for
> > > > > > some Actions that need structured configurations like the {xxx}DatabaseActions
> > > > > > and the convenience of the Parameters. Since Cocoon doesn't pass Configuration
> > > > > > objects,
> > > >
> > > > If I look into the sitemap.xsl Actions where configured like all other
> > > > sitemap components. Why do you say Actions don't get passed
> > > > Configuration objects?
> > >
> > > I am refering to <map:act> sections in the pipeline or action sets.
> > > Once the thing is originally configured, it can't have context dependant
> > > configurations. Example:
> > >
> > > One action acts the same no matter where you use it.
> > > You have context dependant mapping info that can't be expressed in Parameters.
> > > Now you have to do one of two things:
> > >
> > > 1) Create a new instance of the action for all cases--not very flexible,
> > > and it forces the sitemap to explicitly add 20 different declarations
> > > for the same component.
> > > 2) Use this action, and specify an ancilliary configuration class that adds
> > > the context dependant information.
> > >
> > >
> > > Basically what I am saying is that Actions are not passed Configuration objects
> > > at _run_time_.
> >
> > I think I've really missed something. None of the sitemap components
> > gets passed Configuration objects at _run_time_. It's the same for all.
> > But you can pass Parameters as with all other SitemapComponents. So
> > Actions are (at least I thought I have implemented them that way)
> > treaded as any other SitemapComponent. It's adifferent case with
> > action-sets. Well, for them we haven't really specified how they should
> > be handeled by the sitemap engine.
>
> You are correct. The Action is a sitemap component that gets a Parameters
> object during runtime. Sometimes the runtime context information can't
> be easily or properly stated with simple name/value pairs. For instance,
> the DatabaseActions (that's why they have the complementary configuration).
> There is a three way mapping:
>
> Form Name, Type, Table Column Name
>
> The configuration file can also be further augmented so that you can easily
> put constraints on the form params:
>
> <advertisement>
> <keys>
> <key parameter="id" type="int" column="adId" mode="auto"/>
> </keys>
> <values>
> <value parameter="name" type="string" column="title">
> <constraint nullable="false" min-length="3" max-length="32"/>
> </value>
> </values>
> </advertisement>
I've taken a deeper look into the Actions for the Employee stuff. I'd
suggest the following:
If the complimentary configuration you'd like to offer to an Action is
static over its lifetime you do:
<map:action name="add-employee"
src="org.apache.cocoon.acting.DatabaseAddAction">
<complimentary-configuration
file="context://docs/samples/forms/employee.xml"/>
</map:action>
in the <map:components> <map:actions> section. Then you need to make
your Action Configurable and you receive the Configuration that way.
If you need to pass different information to the same Action (because it
is used in different pipelines or passed values replaced by the sitemap)
then use the parameter like you've done in the employee samples.
After all, my comment on the employee samples is that the Actions there
are best extended with the Configurable interface and the complimentary
configuration is parsed/read at instantiation time once and not for
every invocation of the act method.
Does this makes sense?
Giacomo
>
> This allows a number of different Actions act on the same configuration
> information (not included in the sitemap):
>
> Add/Update/Delete actions worry about the mapping
> Validator actions worry about the constraints
>
> When you have a complimentary configuration, then it makes this approach
> easier than repeating the configuration information for each Action
> involved in the system.
>
> Really, the AbstractComplimentaryConfiguration object has a definite need
> and roll--though not all Actions require this.
>
> ---------------------------------------------------------------------
> 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: [c2] simple sitemap question
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Wed, 18 Apr 2001, Berin Loritsch wrote:
>
> > giacomo wrote:
> > >
> > > On Tue, 17 Apr 2001, Donald Ball wrote:
> > >
> > > > On Mon, 16 Apr 2001, Berin Loritsch wrote:
> > > >
> > > > > The AbstractComplimentaryConfigurableAction (though the name is confusing)
> > > > > is used when you have a Configuration file that you want to load separately
> > > > > from the Sitemap. The Sitemap configuration is not flexible enough for
> > > > > some Actions that need structured configurations like the {xxx}DatabaseActions
> > > > > and the convenience of the Parameters. Since Cocoon doesn't pass Configuration
> > > > > objects,
> > >
> > > If I look into the sitemap.xsl Actions where configured like all other
> > > sitemap components. Why do you say Actions don't get passed
> > > Configuration objects?
> >
> > I am refering to <map:act> sections in the pipeline or action sets.
> > Once the thing is originally configured, it can't have context dependant
> > configurations. Example:
> >
> > One action acts the same no matter where you use it.
> > You have context dependant mapping info that can't be expressed in Parameters.
> > Now you have to do one of two things:
> >
> > 1) Create a new instance of the action for all cases--not very flexible,
> > and it forces the sitemap to explicitly add 20 different declarations
> > for the same component.
> > 2) Use this action, and specify an ancilliary configuration class that adds
> > the context dependant information.
> >
> >
> > Basically what I am saying is that Actions are not passed Configuration objects
> > at _run_time_.
>
> I think I've really missed something. None of the sitemap components
> gets passed Configuration objects at _run_time_. It's the same for all.
> But you can pass Parameters as with all other SitemapComponents. So
> Actions are (at least I thought I have implemented them that way)
> treaded as any other SitemapComponent. It's adifferent case with
> action-sets. Well, for them we haven't really specified how they should
> be handeled by the sitemap engine.
You are correct. The Action is a sitemap component that gets a Parameters
object during runtime. Sometimes the runtime context information can't
be easily or properly stated with simple name/value pairs. For instance,
the DatabaseActions (that's why they have the complementary configuration).
There is a three way mapping:
Form Name, Type, Table Column Name
The configuration file can also be further augmented so that you can easily
put constraints on the form params:
<advertisement>
<keys>
<key parameter="id" type="int" column="adId" mode="auto"/>
</keys>
<values>
<value parameter="name" type="string" column="title">
<constraint nullable="false" min-length="3" max-length="32"/>
</value>
</values>
</advertisement>
This allows a number of different Actions act on the same configuration
information (not included in the sitemap):
Add/Update/Delete actions worry about the mapping
Validator actions worry about the constraints
When you have a complimentary configuration, then it makes this approach
easier than repeating the configuration information for each Action
involved in the system.
Really, the AbstractComplimentaryConfiguration object has a definite need
and roll--though not all Actions require this.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by giacomo <gi...@apache.org>.
On Wed, 18 Apr 2001, Berin Loritsch wrote:
> giacomo wrote:
> >
> > On Tue, 17 Apr 2001, Donald Ball wrote:
> >
> > > On Mon, 16 Apr 2001, Berin Loritsch wrote:
> > >
> > > > The AbstractComplimentaryConfigurableAction (though the name is confusing)
> > > > is used when you have a Configuration file that you want to load separately
> > > > from the Sitemap. The Sitemap configuration is not flexible enough for
> > > > some Actions that need structured configurations like the {xxx}DatabaseActions
> > > > and the convenience of the Parameters. Since Cocoon doesn't pass Configuration
> > > > objects,
> >
> > If I look into the sitemap.xsl Actions where configured like all other
> > sitemap components. Why do you say Actions don't get passed
> > Configuration objects?
>
> I am refering to <map:act> sections in the pipeline or action sets.
> Once the thing is originally configured, it can't have context dependant
> configurations. Example:
>
> One action acts the same no matter where you use it.
> You have context dependant mapping info that can't be expressed in Parameters.
> Now you have to do one of two things:
>
> 1) Create a new instance of the action for all cases--not very flexible,
> and it forces the sitemap to explicitly add 20 different declarations
> for the same component.
> 2) Use this action, and specify an ancilliary configuration class that adds
> the context dependant information.
>
>
> Basically what I am saying is that Actions are not passed Configuration objects
> at _run_time_.
I think I've really missed something. None of the sitemap components
gets passed Configuration objects at _run_time_. It's the same for all.
But you can pass Parameters as with all other SitemapComponents. So
Actions are (at least I thought I have implemented them that way)
treaded as any other SitemapComponent. It's adifferent case with
action-sets. Well, for them we haven't really specified how they should
be handeled by the sitemap engine.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Tue, 17 Apr 2001, Donald Ball wrote:
>
> > On Mon, 16 Apr 2001, Berin Loritsch wrote:
> >
> > > The AbstractComplimentaryConfigurableAction (though the name is confusing)
> > > is used when you have a Configuration file that you want to load separately
> > > from the Sitemap. The Sitemap configuration is not flexible enough for
> > > some Actions that need structured configurations like the {xxx}DatabaseActions
> > > and the convenience of the Parameters. Since Cocoon doesn't pass Configuration
> > > objects,
>
> If I look into the sitemap.xsl Actions where configured like all other
> sitemap components. Why do you say Actions don't get passed
> Configuration objects?
I am refering to <map:act> sections in the pipeline or action sets.
Once the thing is originally configured, it can't have context dependant
configurations. Example:
One action acts the same no matter where you use it.
You have context dependant mapping info that can't be expressed in Parameters.
Now you have to do one of two things:
1) Create a new instance of the action for all cases--not very flexible,
and it forces the sitemap to explicitly add 20 different declarations
for the same component.
2) Use this action, and specify an ancilliary configuration class that adds
the context dependant information.
Basically what I am saying is that Actions are not passed Configuration objects
at _run_time_.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by giacomo <gi...@apache.org>.
On Tue, 17 Apr 2001, Donald Ball wrote:
> On Mon, 16 Apr 2001, Berin Loritsch wrote:
>
> > The AbstractComplimentaryConfigurableAction (though the name is confusing)
> > is used when you have a Configuration file that you want to load separately
> > from the Sitemap. The Sitemap configuration is not flexible enough for
> > some Actions that need structured configurations like the {xxx}DatabaseActions
> > and the convenience of the Parameters. Since Cocoon doesn't pass Configuration
> > objects,
If I look into the sitemap.xsl Actions where configured like all other
sitemap components. Why do you say Actions don't get passed
Configuration objects?
Giacomo
> > but Parameter objects to Actions, I created this thing to handle
> > mapping requests from the database to form parameters.
> >
> > In the process, I envisioned a validation layer that would use the same
> > configuration file and make sure the parameters were within constraints.
> > I also had some other purposes in mind.
> >
> > The end result is that we have a framework Action that can load an XML file
> > and treat it as a Configuration.
>
> and it's a nice piece of work - i guess it's the word 'Complimentary'
> that's tossed in there that makes it sound confusing...
>
> > As to the class used to resolve URIs, I am not sure. The Log message
> > could be downgraded--it depends on context whether it is truly an
> > error or not. Please note that INFO won't allow you to attach
> > exceptions to the message, so it would be either WARN or DEBUG.
>
> i'd vote for DEBUG, myself. right now, every time i hit a pipeline that
> doesn't have a url-specific stylesheet, i get a stacktrace dumped to
> cocoon.log - not a very performant solution. it seems that since the error
> is signaled by tossing an exception to whatever invoked the
> EntityResolver, that it can decide whether or not it's actually a serious
> error or not. make sense?
>
> - donald
>
>
> ---------------------------------------------------------------------
> 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: [c2] simple sitemap question
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 16 Apr 2001, Berin Loritsch wrote:
> The AbstractComplimentaryConfigurableAction (though the name is confusing)
> is used when you have a Configuration file that you want to load separately
> from the Sitemap. The Sitemap configuration is not flexible enough for
> some Actions that need structured configurations like the {xxx}DatabaseActions
> and the convenience of the Parameters. Since Cocoon doesn't pass Configuration
> objects, but Parameter objects to Actions, I created this thing to handle
> mapping requests from the database to form parameters.
>
> In the process, I envisioned a validation layer that would use the same
> configuration file and make sure the parameters were within constraints.
> I also had some other purposes in mind.
>
> The end result is that we have a framework Action that can load an XML file
> and treat it as a Configuration.
and it's a nice piece of work - i guess it's the word 'Complimentary'
that's tossed in there that makes it sound confusing...
> As to the class used to resolve URIs, I am not sure. The Log message
> could be downgraded--it depends on context whether it is truly an
> error or not. Please note that INFO won't allow you to attach
> exceptions to the message, so it would be either WARN or DEBUG.
i'd vote for DEBUG, myself. right now, every time i hit a pipeline that
doesn't have a url-specific stylesheet, i get a stacktrace dumped to
cocoon.log - not a very performant solution. it seems that since the error
is signaled by tossing an exception to whatever invoked the
EntityResolver, that it can decide whether or not it's actually a serious
error or not. make sense?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by Berin Loritsch <bl...@apache.org>.
Donald Ball wrote:
>
>
> well, from where i'm sitting, it looks like Actions are going to be the
> new agents of the supposedly dreaded (too much) Flexibility Syndrome...
:) Their idea is simple, flexible, and workable. I think FS comes into
play when you want everything and the kitchen sink in one component.
> thankfully, i can do what i wanted to with the ResourceExistsAction which
> i just checked in. i stole the URLFactory code from the confusingly-named
> AbstractComplimentaryConfigurableAction but i seem to recall some
> discussion debating which class we should use to resolve urls - is this
> the right one or not? also, when the URLFactory is asked to resolve a URL
> which does not exist, in addition to throwing a RuntimeException, it logs
> an ERROR to the cocoon log - perhaps that should be downgraded to an INFO
> or a WARN?
The AbstractComplimentaryConfigurableAction (though the name is confusing)
is used when you have a Configuration file that you want to load separately
from the Sitemap. The Sitemap configuration is not flexible enough for
some Actions that need structured configurations like the {xxx}DatabaseActions
and the convenience of the Parameters. Since Cocoon doesn't pass Configuration
objects, but Parameter objects to Actions, I created this thing to handle
mapping requests from the database to form parameters.
In the process, I envisioned a validation layer that would use the same
configuration file and make sure the parameters were within constraints.
I also had some other purposes in mind.
The end result is that we have a framework Action that can load an XML file
and treat it as a Configuration.
As to the class used to resolve URIs, I am not sure. The Log message could be
downgraded--it depends on context whether it is truly an error or not. Please
note that INFO won't allow you to attach exceptions to the message, so it
would be either WARN or DEBUG.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 16 Apr 2001, Berin Loritsch wrote:
> > No, your java code does not need to generate java source code........Please take a look at
> > LangSelect.java. I think you need an Action not a Matcher.
>
> There are three methods of doing conditional processing:
>
> 1) Creating a Matcher (Compnent that implements Matcher interface)
> 2) Creating a CodeFactory (a matcher that is embedded in the sitemap)
> 3) Creating an Action (Component that implements Action interface)
>
> There are pluses and minuses to each of the approaches.
>
> A Matcher Component is better for complex tests based on URI only that
> are not really embeddable. It has the overhead of being a distinct
> object, but sometimes the encapsulation is worth it.
>
> A Matcher Factory is better for simple tests based on URI only that
> are easily embeddable. It is more difficult to debug, but usually has
> little overhead associated with it.
>
> An Action is best when you have multiple criteria and complex tests.
> Such a solution is heavier than either the Matcher solutions, but much
> more flexible. There is some overlap between a Matcher Component and
> an Action, but the key difference is that Matchers are not
> Parameterizable.
well, from where i'm sitting, it looks like Actions are going to be the
new agents of the supposedly dreaded (too much) Flexibility Syndrome...
thankfully, i can do what i wanted to with the ResourceExistsAction which
i just checked in. i stole the URLFactory code from the confusingly-named
AbstractComplimentaryConfigurableAction but i seem to recall some
discussion debating which class we should use to resolve urls - is this
the right one or not? also, when the URLFactory is asked to resolve a URL
which does not exist, in addition to throwing a RuntimeException, it logs
an ERROR to the cocoon log - perhaps that should be downgraded to an INFO
or a WARN?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by Berin Loritsch <bl...@apache.org>.
Davanum Srinivas wrote:
>
> Donald,
>
> No, your java code does not need to generate java source code........Please take a look at
> LangSelect.java. I think you need an Action not a Matcher.
There are three methods of doing conditional processing:
1) Creating a Matcher (Compnent that implements Matcher interface)
2) Creating a CodeFactory (a matcher that is embedded in the sitemap)
3) Creating an Action (Component that implements Action interface)
There are pluses and minuses to each of the approaches.
A Matcher Component is better for complex tests based on URI only that are not really
embeddable. It has the overhead of being a distinct object, but sometimes the encapsulation
is worth it.
A Matcher Factory is better for simple tests based on URI only that are easily embeddable.
It is more difficult to debug, but usually has little overhead associated with it.
An Action is best when you have multiple criteria and complex tests. Such a solution
is heavier than either the Matcher solutions, but much more flexible. There is some
overlap between a Matcher Component and an Action, but the key difference is that Matchers
are not Parameterizable.
In the immortal words of the knight in Indiana Jones In the Last Crusade, "You must choose,
but choose wisely...".
>
> Thanks,
> dims
>
> --- Donald Ball <ba...@webslingerZ.com> wrote:
> > On Mon, 16 Apr 2001, giacomo wrote:
> >
> > > > i'd like to have a conditional stylesheet in my sitemap. here's my default
> > > > pipeline:
> > > >
> > > > <map:match pattern="*">
> > > > <map:generate src="content/{1}.xml" type="serverpages"/>
> > > > <map:transform src="style/{1}.xsl"/>
> > > > <map:transform src="style/wziml-html.xsl"/>
> > > > <map:serialize/>
> > > > </map:match>
> > >
> > > Use a custom matcher then.
> >
> > perhaps you'd be so kind as to nudge me in the right direction then? i
> > note the matcher api consists of this method:
> >
> > public interface Matcher extends Component {
> > /**
> > * Matches the pattern against some <code>Request</code> values
> > * and returns a <code>Map</code> object with replacements
> > * for wildcards contained in the pattern.
> > * @param pattern The pattern to match against. Depending on the
> > * implementation the pattern can contain wildcards
> > * or regular expressions.
> > * @param objectModel The <code>Map</code> with object of the
> > * calling environment which can be used
> > * to select values this matchers matches against.
> > * @return Map The returned <code>Map</code> object with
> > * replacements for wildcards/regular-expressions
> > * contained in the pattern.
> > * If the return value is null there was no match.
> > */
> > Map match (String pattern, Map objectModel);
> > }
> >
> > but i'll be danged if i can find a class which actually implements this
> > interface. is this old?
> >
> > maybe i'm supposed to write my own MatcherFactory class? if so, then let
> > me get this straight - i'm supposed to write my own java class which
> > generates java source code in order to put a condition around a pipeline
> > component?
> >
> > - donald
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
> ---------------------------------------------------------------------
> 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: [c2] simple sitemap question
Posted by Davanum Srinivas <di...@yahoo.com>.
Donald,
No, your java code does not need to generate java source code........Please take a look at
LangSelect.java. I think you need an Action not a Matcher.
Thanks,
dims
--- Donald Ball <ba...@webslingerZ.com> wrote:
> On Mon, 16 Apr 2001, giacomo wrote:
>
> > > i'd like to have a conditional stylesheet in my sitemap. here's my default
> > > pipeline:
> > >
> > > <map:match pattern="*">
> > > <map:generate src="content/{1}.xml" type="serverpages"/>
> > > <map:transform src="style/{1}.xsl"/>
> > > <map:transform src="style/wziml-html.xsl"/>
> > > <map:serialize/>
> > > </map:match>
> >
> > Use a custom matcher then.
>
> perhaps you'd be so kind as to nudge me in the right direction then? i
> note the matcher api consists of this method:
>
> public interface Matcher extends Component {
> /**
> * Matches the pattern against some <code>Request</code> values
> * and returns a <code>Map</code> object with replacements
> * for wildcards contained in the pattern.
> * @param pattern The pattern to match against. Depending on the
> * implementation the pattern can contain wildcards
> * or regular expressions.
> * @param objectModel The <code>Map</code> with object of the
> * calling environment which can be used
> * to select values this matchers matches against.
> * @return Map The returned <code>Map</code> object with
> * replacements for wildcards/regular-expressions
> * contained in the pattern.
> * If the return value is null there was no match.
> */
> Map match (String pattern, Map objectModel);
> }
>
> but i'll be danged if i can find a class which actually implements this
> interface. is this old?
>
> maybe i'm supposed to write my own MatcherFactory class? if so, then let
> me get this straight - i'm supposed to write my own java class which
> generates java source code in order to put a condition around a pipeline
> component?
>
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 16 Apr 2001, giacomo wrote:
> > i'd like to have a conditional stylesheet in my sitemap. here's my default
> > pipeline:
> >
> > <map:match pattern="*">
> > <map:generate src="content/{1}.xml" type="serverpages"/>
> > <map:transform src="style/{1}.xsl"/>
> > <map:transform src="style/wziml-html.xsl"/>
> > <map:serialize/>
> > </map:match>
>
> Use a custom matcher then.
perhaps you'd be so kind as to nudge me in the right direction then? i
note the matcher api consists of this method:
public interface Matcher extends Component {
/**
* Matches the pattern against some <code>Request</code> values
* and returns a <code>Map</code> object with replacements
* for wildcards contained in the pattern.
* @param pattern The pattern to match against. Depending on the
* implementation the pattern can contain wildcards
* or regular expressions.
* @param objectModel The <code>Map</code> with object of the
* calling environment which can be used
* to select values this matchers matches against.
* @return Map The returned <code>Map</code> object with
* replacements for wildcards/regular-expressions
* contained in the pattern.
* If the return value is null there was no match.
*/
Map match (String pattern, Map objectModel);
}
but i'll be danged if i can find a class which actually implements this
interface. is this old?
maybe i'm supposed to write my own MatcherFactory class? if so, then let
me get this straight - i'm supposed to write my own java class which
generates java source code in order to put a condition around a pipeline
component?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] simple sitemap question
Posted by giacomo <gi...@apache.org>.
On Sun, 15 Apr 2001, Donald Ball wrote:
> i'd like to have a conditional stylesheet in my sitemap. here's my default
> pipeline:
>
> <map:match pattern="*">
> <map:generate src="content/{1}.xml" type="serverpages"/>
> <map:transform src="style/{1}.xsl"/>
> <map:transform src="style/wziml-html.xsl"/>
> <map:serialize/>
> </map:match>
Use a custom matcher then.
Giacomo
>
> problem is, the first stylesheet doesn't necessarily always exist. i'd
> like to check for its existence and only if exists, put the transformation
> in the pipeline. someone got a clue for me?
>
> - donald
>
>
> ---------------------------------------------------------------------
> 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