You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/10/12 10:22:35 UTC
The Problems with Sitemap Factories
Hi Team,
I would like to propose that we get rid of the sitemap factories,
the selector and matcher factory.
I see at least three reasons for this:
- If you want to use a matcher factory inside a subsitemap,
you currently MUST redefine it in the subsitemap as it is
not "inherited" from the parent sitemap. This is true
of course also true for selectors (I entered this already
in bugzilla).
Using matchers and selectors in subsitemaps becomes very
error prone as you always as a sitemap editor have to be
aware if it is *implemented* as a factory or not. I think
the sitemap editor does not have to know about such technical
details.
- The factories are hard to code. Java code generated from strings
is not so easy to write.
- This is needed for the new RT, like the recent Tree traversal approach
So I'm +3 on removing the factories and this even for the final release!
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The Problems with Sitemap Factories
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Fri, 12 Oct 2001, Sylvain Wallez wrote:
> And since we're talking about matchers and selectors, a few thoughts
> (for 2.1 ?) :
> - I've always been confused that selectors don't have a method called on
> "map:select" to set up a context that could be reused between the
> different "map:when" alternatives. In many cases this would allow to
> reduce select() to a simple equality test and thus speed up processing.
I agree with this Sylvain, it was something that confused me as
well in the beginning.
Having such a function called at map:select time would help a
lot - currently we have to all our selector's processing in each
map:test statement, everytime. I reckon it would be much better if it
was done once, and then simply checked like map:test leads to mean.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Managesoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@managesoft.com
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: The Problems with Sitemap Factories
Posted by Stefano Mazzocchi <st...@apache.org>.
Jason Foster wrote:
>
> How about using a lazy prepare() instead of precalculating? That way we
> can amortize the initialization time.
>
> The counterpoint is that the original sitemap will be used until the new
> sitemap is fully prepared, which means that initialization time is mostly
> a non-issue, except on initial startup which should happen as infrequently
> as possible (right?).
Right. In theory, on production environments, the sitemap should never
change (or change so rarely it doesn't really matter the sitemap
preparation time).
On development environments, where the sitemap may change as frequently
as for each request, the init time is important, but it will be *FAR*
less than what we have today anyway, expecially thinking about the near
future sitemap interpretation.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: The Problems with Sitemap Factories
Posted by Jason Foster <ja...@uwaterloo.ca>.
How about using a lazy prepare() instead of precalculating? That way we
can amortize the initialization time.
The counterpoint is that the original sitemap will be used until the new
sitemap is fully prepared, which means that initialization time is mostly
a non-issue, except on initial startup which should happen as infrequently
as possible (right?).
Jason Foster
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: The Problems with Sitemap Factories
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
> > Sylvain Wallez wrote:
> >
> > Carsten Ziegeler a écrit :
> > >
> > > Hi Sylvain,
> > >
> > > > Sylvain Wallez wrote:
> > > >
> > > > +1. I find these too much complicated and like the idea of an
> > > > interpreded sitemap, and even more flowmaps !
> > > >
> > > > But in order to still have a good performance we need a way for some
> > > > matchers to prepare patterns (e.g. precompile regexps) during sitemap
> > > > initialization. So what about a "PreparedMatcher" ?
> > > >
> > > > interface Matcher {
> > > > Map match (Object pattern, Map objectModel, Parameters parameters);
> > > > }
> > > >
> > > > interface PreparedMatcher {
> > > > Object prepare(String pattern);
> > > > Map match (Object pattern, Map objectModel, Parameters parameters);
> > > > }
> > > >
> > > > As you see, this requires a little modification of the
> > Matcher interface
> > > > since the "pattern" parameter will be an Object :
> > > > - it's the pattern String (as now) for non-prepared matchers,
> > > > - it's the object returned by prepare() for prepared matchers
> > > >
> > > > Or we can also simply add prepare() to Matcher and have
> > AbstractMatcher
> > > > return the pattern as is.
> > > >
> > > Could you give an example of a real matcher and how that would implement
> > > the interface?
> >
> > Here is the RegexpURIMatcherFactory transformed as a Matcher with the
> > additionnal prepare() method (which I finally prefer to a separate
> > PreparedMatcher interface) :
> >
> > public class RegexpURIMatcher implements Matcher {
> >
> > // Compile the pattern as a RE object
> > public Object prepare(String pattern) throws Exception {
> > RECompiler comp = new RECompiler();
> > REProgram program = comp.compile(pattern);
> > String pat = correctPattern(pattern);
> > return new RE(pat);
> > }
> >
> > // "pattern" is the RE returned by prepare()
> > public Map match (Object pattern, Map objectModel, Parameters
> > parameters) {
> > RE re = (RE)pattern;
> > String uri = XSPRequestHelper.getSitemapURI(objectModel);
> > if(uri.startsWith("/")) uri = uri.substring(1);
> >
> > if(re.match(uri)) {
> > HashMap map = new HashMap();
> > int parenCount = re.getParenCount();
> > for (int paren = 1; paren <= parenCount; paren++) {
> > map.put(Integer.toString(paren), re.getParen(paren));
> > }
> > return map;
> > } else {
> > return null;
> > }
> > }
> >
> > public String correctPattern(String pattern) {
> > ... (same as RegexpURIMatcherFactory)
> > }
> > }
> >
> > You can see from this example that the only performance cost compared to
> > a factory is at sitemap startup time where the regexp is compiled
> > instead of beeing created from a byte array. Request handling is
> > identical.
> >
> Ok, I understand this. So the usual order of calls is:
> - When the sitemap is generated, a matcher object (for each type) is
> instantiated.
> - If the matcher is preparable:
> For each pattern occuring in the pipelines the prepare(method) is
> used and the pattern is "replaced" with the result
> - In the pipelines the match is done using the match() function with
> either the pattern or the prepared pattern.
> Right?
Exactly. I also finally think we could have a single Matcher interface
including the prepare() method. Implementations that don't want to
prepare something just return the pattern unchanged. This will reduce
complexity on both the implementor's side (doesn't have to choose
between prepared/unprepared) and sitemap's side (same handling of all
matchers).
> There is only one thing I don't like: The necessary casting of the
> pattern in the match method(). I think it should still be a String
> and the prepare() method should also return a string.
> So, next thing we could add is the SourceResolver to the match method().
In many cases it can't be a String : in the example above, the RE class
is an object representing the compiled regular expression (a FSM parser
?). If the pattern parameter is forced to be a String, then the regexp
cannot be precompiled and thus we loose the benefit of prepare().
I also don't think pattern (or better named "preparedPattern") being an
Object in select() is a problem, since it's producer (the prepare()
method) is in the same class as it's consumer (the match() method). The
contract defining the actual type of the prepared pattern doesn't need
to be known outside the Matcher class itself.
> > > > I don't know if Selectors could also benefit from a
> > "PreparedSelector".
> > > >
> > > > And since we're talking about matchers and selectors, a few thoughts
> > > > (for 2.1 ?) :
> > > > - What about giving matchers and selectors access to the
> > source resolver
> > > > ?
> > > I can remember that we had a discussion on this, but I can't remember
> > > the agreement we made. Do you recall it?
> > > If anything is against it, we should add the source resolver to the
> > > interfaces *if* we change the interfaces anyway.
> >
> > IIRC, there wasn't any clear conclusion, maybe because this requires
> > interface changes. But I'm +1 for adding them if interfaces have to
> > change because of the removal of CodeFactory.
> >
> > > > - I've always been confused that selectors don't have a
> > method called on
> > > > "map:select" to set up a context that could be reused between the
> > > > different "map:when" alternatives. In many cases this would allow to
> > > > reduce select() to a simple equality test and thus speed up
> > processing.
> > > >
> > > Could you please give an example here, too?
> > >
> >
> > Here it is, based on the BrowserSelector !
> > The new prepare() method is called on <map:select> and returns an object
> > which is passed back to select() (called for each <map:when>).
> >
> > prepare() allows to gather information that is required to all
> > <map:when> to do their job. Maybe in this example this isn't very
> > CPU-costly, but we have a real benefit if the context involves a query
> > in a database. Additionnaly, the "Vary" header is set once, while in the
> > factory version it is set for each <map:when>.
> >
> > public class BrowserSelector implements Selector {
> > // Association of select names to array of user-agent strings,
> > // built in configure()
> > Map agentNames;
> >
> > public Object prepare(Map objectModel, Parameters parameters) {
> > // Indicate this response depends on the user-agent
> > XSPResponseHelper.addHeader(objectModel, "Vary", "User-Agent");
> > // Return the user-agent from the request
> > if (objectModel.get(Constants.REQUEST_OBJECT) != null) {
> > return XSPRequestHelper.getHeader(objectModel,"User-Agent");
> > }
> > return null;
> > }
> >
> > public boolean select(String expression, Object selectContext, Map
> > objectModel, Parameters parameters) {
> > if (selectContext == null)
> > return false;
> >
> > String[] agents = (String[]) agentNames.get(expression);
> > if (agents == null) // no definition of expression
> > return false;
> >
> > String userAgent = (String) selectContext;
> > for (int i = 0; i < agents.length; i++) {
> > if (userAgent.indexOf(agents[i]) != -1)
> > return true;
> > }
> > return false;
> > }
> > }
> >
> Ok, same as for the matchers applies to this selectors: String as input,
> SourceResolver and I would like to remove the XSP dependency (I know,
> this is also in the sitemap.xsl, but it's actually not necessary).
>
And same remark about Strings ;)
XSP dependencies are here because I have copy/pasted existing code :
these are just convenience wrappers to access directly the request and
response and can easily be removed.
> But mainly, I agree with your suggestions. So let's wait for other
> opinions.
>
Great !
Sylvain.
> Carsten
>
> > > Carsten
> > >
> > > > Sylvain.
> > > >
> > > > Carsten Ziegeler a écrit :
> > > > >
> > > > > Hi Team,
> > > > >
> > > > > I would like to propose that we get rid of the sitemap factories,
> > > > > the selector and matcher factory.
> > > > >
> > > > > I see at least three reasons for this:
> > > > > - If you want to use a matcher factory inside a subsitemap,
> > > > > you currently MUST redefine it in the subsitemap as it is
> > > > > not "inherited" from the parent sitemap. This is true
> > > > > of course also true for selectors (I entered this already
> > > > > in bugzilla).
> > > > > Using matchers and selectors in subsitemaps becomes very
> > > > > error prone as you always as a sitemap editor have to be
> > > > > aware if it is *implemented* as a factory or not. I think
> > > > > the sitemap editor does not have to know about such technical
> > > > > details.
> > > > > - The factories are hard to code. Java code generated from strings
> > > > > is not so easy to write.
> > > > > - This is needed for the new RT, like the recent Tree
> > traversal approach
> > > > >
> > > > > So I'm +3 on removing the factories and this even for the
> > final release!
> > > > >
> > > > > Carsten
> > > > >
> > > > > Open Source Group sunShine - b:Integrated
> > > > > ================================================================
> > > > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > > > www.sundn.de mailto: cziegeler@sundn.de
> > > > > ================================================================
> > > >
> > > > --
> > > > Sylvain Wallez
> > > > Anyware Technologies - http://www.anyware-tech.com
> > > >
> >
> > --
> > Sylvain Wallez
> > Anyware Technologies - http://www.anyware-tech.com
> >
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: The Problems with Sitemap Factories
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> > Hi Sylvain,
> >
> > > Sylvain Wallez wrote:
> > >
> > > +1. I find these too much complicated and like the idea of an
> > > interpreded sitemap, and even more flowmaps !
> > >
> > > But in order to still have a good performance we need a way for some
> > > matchers to prepare patterns (e.g. precompile regexps) during sitemap
> > > initialization. So what about a "PreparedMatcher" ?
> > >
> > > interface Matcher {
> > > Map match (Object pattern, Map objectModel, Parameters parameters);
> > > }
> > >
> > > interface PreparedMatcher {
> > > Object prepare(String pattern);
> > > Map match (Object pattern, Map objectModel, Parameters parameters);
> > > }
> > >
> > > As you see, this requires a little modification of the
> Matcher interface
> > > since the "pattern" parameter will be an Object :
> > > - it's the pattern String (as now) for non-prepared matchers,
> > > - it's the object returned by prepare() for prepared matchers
> > >
> > > Or we can also simply add prepare() to Matcher and have
> AbstractMatcher
> > > return the pattern as is.
> > >
> > Could you give an example of a real matcher and how that would implement
> > the interface?
>
> Here is the RegexpURIMatcherFactory transformed as a Matcher with the
> additionnal prepare() method (which I finally prefer to a separate
> PreparedMatcher interface) :
>
> public class RegexpURIMatcher implements Matcher {
>
> // Compile the pattern as a RE object
> public Object prepare(String pattern) throws Exception {
> RECompiler comp = new RECompiler();
> REProgram program = comp.compile(pattern);
> String pat = correctPattern(pattern);
> return new RE(pat);
> }
>
> // "pattern" is the RE returned by prepare()
> public Map match (Object pattern, Map objectModel, Parameters
> parameters) {
> RE re = (RE)pattern;
> String uri = XSPRequestHelper.getSitemapURI(objectModel);
> if(uri.startsWith("/")) uri = uri.substring(1);
>
> if(re.match(uri)) {
> HashMap map = new HashMap();
> int parenCount = re.getParenCount();
> for (int paren = 1; paren <= parenCount; paren++) {
> map.put(Integer.toString(paren), re.getParen(paren));
> }
> return map;
> } else {
> return null;
> }
> }
>
> public String correctPattern(String pattern) {
> ... (same as RegexpURIMatcherFactory)
> }
> }
>
> You can see from this example that the only performance cost compared to
> a factory is at sitemap startup time where the regexp is compiled
> instead of beeing created from a byte array. Request handling is
> identical.
>
Ok, I understand this. So the usual order of calls is:
- When the sitemap is generated, a matcher object (for each type) is
instantiated.
- If the matcher is preparable:
For each pattern occuring in the pipelines the prepare(method) is
used and the pattern is "replaced" with the result
- In the pipelines the match is done using the match() function with
either the pattern or the prepared pattern.
Right?
There is only one thing I don't like: The necessary casting of the
pattern in the match method(). I think it should still be a String
and the prepare() method should also return a string.
So, next thing we could add is the SourceResolver to the match method().
> > > I don't know if Selectors could also benefit from a
> "PreparedSelector".
> > >
> > > And since we're talking about matchers and selectors, a few thoughts
> > > (for 2.1 ?) :
> > > - What about giving matchers and selectors access to the
> source resolver
> > > ?
> > I can remember that we had a discussion on this, but I can't remember
> > the agreement we made. Do you recall it?
> > If anything is against it, we should add the source resolver to the
> > interfaces *if* we change the interfaces anyway.
>
> IIRC, there wasn't any clear conclusion, maybe because this requires
> interface changes. But I'm +1 for adding them if interfaces have to
> change because of the removal of CodeFactory.
>
> > > - I've always been confused that selectors don't have a
> method called on
> > > "map:select" to set up a context that could be reused between the
> > > different "map:when" alternatives. In many cases this would allow to
> > > reduce select() to a simple equality test and thus speed up
> processing.
> > >
> > Could you please give an example here, too?
> >
>
> Here it is, based on the BrowserSelector !
> The new prepare() method is called on <map:select> and returns an object
> which is passed back to select() (called for each <map:when>).
>
> prepare() allows to gather information that is required to all
> <map:when> to do their job. Maybe in this example this isn't very
> CPU-costly, but we have a real benefit if the context involves a query
> in a database. Additionnaly, the "Vary" header is set once, while in the
> factory version it is set for each <map:when>.
>
> public class BrowserSelector implements Selector {
> // Association of select names to array of user-agent strings,
> // built in configure()
> Map agentNames;
>
> public Object prepare(Map objectModel, Parameters parameters) {
> // Indicate this response depends on the user-agent
> XSPResponseHelper.addHeader(objectModel, "Vary", "User-Agent");
> // Return the user-agent from the request
> if (objectModel.get(Constants.REQUEST_OBJECT) != null) {
> return XSPRequestHelper.getHeader(objectModel,"User-Agent");
> }
> return null;
> }
>
> public boolean select(String expression, Object selectContext, Map
> objectModel, Parameters parameters) {
> if (selectContext == null)
> return false;
>
> String[] agents = (String[]) agentNames.get(expression);
> if (agents == null) // no definition of expression
> return false;
>
> String userAgent = (String) selectContext;
> for (int i = 0; i < agents.length; i++) {
> if (userAgent.indexOf(agents[i]) != -1)
> return true;
> }
> return false;
> }
> }
>
Ok, same as for the matchers applies to this selectors: String as input,
SourceResolver and I would like to remove the XSP dependency (I know,
this is also in the sitemap.xsl, but it's actually not necessary).
But mainly, I agree with your suggestions. So let's wait for other
opinions.
Carsten
> > Carsten
> >
> > > Sylvain.
> > >
> > > Carsten Ziegeler a écrit :
> > > >
> > > > Hi Team,
> > > >
> > > > I would like to propose that we get rid of the sitemap factories,
> > > > the selector and matcher factory.
> > > >
> > > > I see at least three reasons for this:
> > > > - If you want to use a matcher factory inside a subsitemap,
> > > > you currently MUST redefine it in the subsitemap as it is
> > > > not "inherited" from the parent sitemap. This is true
> > > > of course also true for selectors (I entered this already
> > > > in bugzilla).
> > > > Using matchers and selectors in subsitemaps becomes very
> > > > error prone as you always as a sitemap editor have to be
> > > > aware if it is *implemented* as a factory or not. I think
> > > > the sitemap editor does not have to know about such technical
> > > > details.
> > > > - The factories are hard to code. Java code generated from strings
> > > > is not so easy to write.
> > > > - This is needed for the new RT, like the recent Tree
> traversal approach
> > > >
> > > > So I'm +3 on removing the factories and this even for the
> final release!
> > > >
> > > > Carsten
> > > >
> > > > Open Source Group sunShine - b:Integrated
> > > > ================================================================
> > > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > > www.sundn.de mailto: cziegeler@sundn.de
> > > > ================================================================
> > >
> > > --
> > > Sylvain Wallez
> > > Anyware Technologies - http://www.anyware-tech.com
> > >
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.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: AW: The Problems with Sitemap Factories
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
> Hi Sylvain,
>
> > Sylvain Wallez wrote:
> >
> > +1. I find these too much complicated and like the idea of an
> > interpreded sitemap, and even more flowmaps !
> >
> > But in order to still have a good performance we need a way for some
> > matchers to prepare patterns (e.g. precompile regexps) during sitemap
> > initialization. So what about a "PreparedMatcher" ?
> >
> > interface Matcher {
> > Map match (Object pattern, Map objectModel, Parameters parameters);
> > }
> >
> > interface PreparedMatcher {
> > Object prepare(String pattern);
> > Map match (Object pattern, Map objectModel, Parameters parameters);
> > }
> >
> > As you see, this requires a little modification of the Matcher interface
> > since the "pattern" parameter will be an Object :
> > - it's the pattern String (as now) for non-prepared matchers,
> > - it's the object returned by prepare() for prepared matchers
> >
> > Or we can also simply add prepare() to Matcher and have AbstractMatcher
> > return the pattern as is.
> >
> Could you give an example of a real matcher and how that would implement
> the interface?
Here is the RegexpURIMatcherFactory transformed as a Matcher with the
additionnal prepare() method (which I finally prefer to a separate
PreparedMatcher interface) :
public class RegexpURIMatcher implements Matcher {
// Compile the pattern as a RE object
public Object prepare(String pattern) throws Exception {
RECompiler comp = new RECompiler();
REProgram program = comp.compile(pattern);
String pat = correctPattern(pattern);
return new RE(pat);
}
// "pattern" is the RE returned by prepare()
public Map match (Object pattern, Map objectModel, Parameters
parameters) {
RE re = (RE)pattern;
String uri = XSPRequestHelper.getSitemapURI(objectModel);
if(uri.startsWith("/")) uri = uri.substring(1);
if(re.match(uri)) {
HashMap map = new HashMap();
int parenCount = re.getParenCount();
for (int paren = 1; paren <= parenCount; paren++) {
map.put(Integer.toString(paren), re.getParen(paren));
}
return map;
} else {
return null;
}
}
public String correctPattern(String pattern) {
... (same as RegexpURIMatcherFactory)
}
}
You can see from this example that the only performance cost compared to
a factory is at sitemap startup time where the regexp is compiled
instead of beeing created from a byte array. Request handling is
identical.
> > I don't know if Selectors could also benefit from a "PreparedSelector".
> >
> > And since we're talking about matchers and selectors, a few thoughts
> > (for 2.1 ?) :
> > - What about giving matchers and selectors access to the source resolver
> > ?
> I can remember that we had a discussion on this, but I can't remember
> the agreement we made. Do you recall it?
> If anything is against it, we should add the source resolver to the
> interfaces *if* we change the interfaces anyway.
IIRC, there wasn't any clear conclusion, maybe because this requires
interface changes. But I'm +1 for adding them if interfaces have to
change because of the removal of CodeFactory.
> > - I've always been confused that selectors don't have a method called on
> > "map:select" to set up a context that could be reused between the
> > different "map:when" alternatives. In many cases this would allow to
> > reduce select() to a simple equality test and thus speed up processing.
> >
> Could you please give an example here, too?
>
Here it is, based on the BrowserSelector !
The new prepare() method is called on <map:select> and returns an object
which is passed back to select() (called for each <map:when>).
prepare() allows to gather information that is required to all
<map:when> to do their job. Maybe in this example this isn't very
CPU-costly, but we have a real benefit if the context involves a query
in a database. Additionnaly, the "Vary" header is set once, while in the
factory version it is set for each <map:when>.
public class BrowserSelector implements Selector {
// Association of select names to array of user-agent strings,
// built in configure()
Map agentNames;
public Object prepare(Map objectModel, Parameters parameters) {
// Indicate this response depends on the user-agent
XSPResponseHelper.addHeader(objectModel, "Vary", "User-Agent");
// Return the user-agent from the request
if (objectModel.get(Constants.REQUEST_OBJECT) != null) {
return XSPRequestHelper.getHeader(objectModel,"User-Agent");
}
return null;
}
public boolean select(String expression, Object selectContext, Map
objectModel, Parameters parameters) {
if (selectContext == null)
return false;
String[] agents = (String[]) agentNames.get(expression);
if (agents == null) // no definition of expression
return false;
String userAgent = (String) selectContext;
for (int i = 0; i < agents.length; i++) {
if (userAgent.indexOf(agents[i]) != -1)
return true;
}
return false;
}
}
> Carsten
>
> > Sylvain.
> >
> > Carsten Ziegeler a écrit :
> > >
> > > Hi Team,
> > >
> > > I would like to propose that we get rid of the sitemap factories,
> > > the selector and matcher factory.
> > >
> > > I see at least three reasons for this:
> > > - If you want to use a matcher factory inside a subsitemap,
> > > you currently MUST redefine it in the subsitemap as it is
> > > not "inherited" from the parent sitemap. This is true
> > > of course also true for selectors (I entered this already
> > > in bugzilla).
> > > Using matchers and selectors in subsitemaps becomes very
> > > error prone as you always as a sitemap editor have to be
> > > aware if it is *implemented* as a factory or not. I think
> > > the sitemap editor does not have to know about such technical
> > > details.
> > > - The factories are hard to code. Java code generated from strings
> > > is not so easy to write.
> > > - This is needed for the new RT, like the recent Tree traversal approach
> > >
> > > So I'm +3 on removing the factories and this even for the final release!
> > >
> > > Carsten
> > >
> > > Open Source Group sunShine - b:Integrated
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > www.sundn.de mailto: cziegeler@sundn.de
> > > ================================================================
> >
> > --
> > Sylvain Wallez
> > Anyware Technologies - http://www.anyware-tech.com
> >
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: The Problems with Sitemap Factories
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi Sylvain,
> Sylvain Wallez wrote:
>
> +1. I find these too much complicated and like the idea of an
> interpreded sitemap, and even more flowmaps !
>
> But in order to still have a good performance we need a way for some
> matchers to prepare patterns (e.g. precompile regexps) during sitemap
> initialization. So what about a "PreparedMatcher" ?
>
> interface Matcher {
> Map match (Object pattern, Map objectModel, Parameters parameters);
> }
>
> interface PreparedMatcher {
> Object prepare(String pattern);
> Map match (Object pattern, Map objectModel, Parameters parameters);
> }
>
> As you see, this requires a little modification of the Matcher interface
> since the "pattern" parameter will be an Object :
> - it's the pattern String (as now) for non-prepared matchers,
> - it's the object returned by prepare() for prepared matchers
>
> Or we can also simply add prepare() to Matcher and have AbstractMatcher
> return the pattern as is.
>
Could you give an example of a real matcher and how that would implement
the interface?
> I don't know if Selectors could also benefit from a "PreparedSelector".
>
> And since we're talking about matchers and selectors, a few thoughts
> (for 2.1 ?) :
> - What about giving matchers and selectors access to the source resolver
> ?
I can remember that we had a discussion on this, but I can't remember
the agreement we made. Do you recall it?
If anything is against it, we should add the source resolver to the
interfaces *if* we change the interfaces anyway.
> - I've always been confused that selectors don't have a method called on
> "map:select" to set up a context that could be reused between the
> different "map:when" alternatives. In many cases this would allow to
> reduce select() to a simple equality test and thus speed up processing.
>
Could you please give an example here, too?
Carsten
> Sylvain.
>
> Carsten Ziegeler a écrit :
> >
> > Hi Team,
> >
> > I would like to propose that we get rid of the sitemap factories,
> > the selector and matcher factory.
> >
> > I see at least three reasons for this:
> > - If you want to use a matcher factory inside a subsitemap,
> > you currently MUST redefine it in the subsitemap as it is
> > not "inherited" from the parent sitemap. This is true
> > of course also true for selectors (I entered this already
> > in bugzilla).
> > Using matchers and selectors in subsitemaps becomes very
> > error prone as you always as a sitemap editor have to be
> > aware if it is *implemented* as a factory or not. I think
> > the sitemap editor does not have to know about such technical
> > details.
> > - The factories are hard to code. Java code generated from strings
> > is not so easy to write.
> > - This is needed for the new RT, like the recent Tree traversal approach
> >
> > So I'm +3 on removing the factories and this even for the final release!
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: cziegeler@sundn.de
> > ================================================================
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.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: The Problems with Sitemap Factories
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
+1. I find these too much complicated and like the idea of an
interpreded sitemap, and even more flowmaps !
But in order to still have a good performance we need a way for some
matchers to prepare patterns (e.g. precompile regexps) during sitemap
initialization. So what about a "PreparedMatcher" ?
interface Matcher {
Map match (Object pattern, Map objectModel, Parameters parameters);
}
interface PreparedMatcher {
Object prepare(String pattern);
Map match (Object pattern, Map objectModel, Parameters parameters);
}
As you see, this requires a little modification of the Matcher interface
since the "pattern" parameter will be an Object :
- it's the pattern String (as now) for non-prepared matchers,
- it's the object returned by prepare() for prepared matchers
Or we can also simply add prepare() to Matcher and have AbstractMatcher
return the pattern as is.
I don't know if Selectors could also benefit from a "PreparedSelector".
And since we're talking about matchers and selectors, a few thoughts
(for 2.1 ?) :
- What about giving matchers and selectors access to the source resolver
?
- I've always been confused that selectors don't have a method called on
"map:select" to set up a context that could be reused between the
different "map:when" alternatives. In many cases this would allow to
reduce select() to a simple equality test and thus speed up processing.
Sylvain.
Carsten Ziegeler a écrit :
>
> Hi Team,
>
> I would like to propose that we get rid of the sitemap factories,
> the selector and matcher factory.
>
> I see at least three reasons for this:
> - If you want to use a matcher factory inside a subsitemap,
> you currently MUST redefine it in the subsitemap as it is
> not "inherited" from the parent sitemap. This is true
> of course also true for selectors (I entered this already
> in bugzilla).
> Using matchers and selectors in subsitemaps becomes very
> error prone as you always as a sitemap editor have to be
> aware if it is *implemented* as a factory or not. I think
> the sitemap editor does not have to know about such technical
> details.
> - The factories are hard to code. Java code generated from strings
> is not so easy to write.
> - This is needed for the new RT, like the recent Tree traversal approach
>
> So I'm +3 on removing the factories and this even for the final release!
>
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: cziegeler@sundn.de
> ================================================================
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The Problems with Sitemap Factories
Posted by giacomo <gi...@apache.org>.
On Fri, 12 Oct 2001, Stefano Mazzocchi wrote:
> Carsten Ziegeler wrote:
> >
> > Hi Team,
> >
> > I would like to propose that we get rid of the sitemap factories,
> > the selector and matcher factory.
> >
> > I see at least three reasons for this:
> > - If you want to use a matcher factory inside a subsitemap,
> > you currently MUST redefine it in the subsitemap as it is
> > not "inherited" from the parent sitemap. This is true
> > of course also true for selectors (I entered this already
> > in bugzilla).
> > Using matchers and selectors in subsitemaps becomes very
> > error prone as you always as a sitemap editor have to be
> > aware if it is *implemented* as a factory or not. I think
> > the sitemap editor does not have to know about such technical
> > details.
> > - The factories are hard to code. Java code generated from strings
> > is not so easy to write.
> > - This is needed for the new RT, like the recent Tree traversal approach
> >
> > So I'm +3 on removing the factories and this even for the final release!
>
> +1, whatever makes it easier to write subsitemaps I'm all for it.
>
> Let's start removing the code compilation thing.
+1
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The Problems with Sitemap Factories
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> > > Sylvain Wallez wrote:
> > >
> > > Carsten Ziegeler a écrit :
> > > >
> > > <snip/>
> > >
> > > > > There's another point on which we still didn't came to a
> > > clear decision
> > > > > : what about making the SourceResolver available to matchers and
> > > > > selectors ? Can't it be simply added to the ObjectModel ?
> > > > >
> > > > To be compatible we shoud pass the SourceResolver as a separate object
> > > > in the method as the other interfaces do the same.
> > >
> > > Mmmh... and what about the other way ? If the SourceResolver becomes
> > > generally available, let's add it to the object model so that we don't
> > > have to pass it as a parameter everywhere.
> > >
> > > If we don't want to change now APIs that have this parameter, we can
> > > "deprecate" its use (in the doc, because we cannot put @deprecated on a
> > > parameter). These methods will have two ways to access the
> > > SourceResolver, but this shouldn't hurt.
If you @deprecate the whole method, replacing it with the correct version,
you can modify the base Abstract class so that the deprecated method calls
the new method (or vice versa). That way, no matter which one the user
overrode in the end, they still get the correct (or expected) results.
> > > This will avoid API changes now (no more, no less parameters) and
> > > prepare for a future release where these parameters would be removed.
> > > Also, the interpreted sitemap to come may allow to handle more easily
> > > different interfaces that implement a single sitemap element than today
> > > (I'm starting heavy thinking about that ;)
> > >
> > > Thoughts ?
> > >
> > I really would like to hear other opinions on this than our two's.
>
> Yep : HEY, TEAM, WHAT DO YOU THINK ?
If you mark it as deprecated sooner than later, then you give folks a heads
up that it is going to change.
> > We have to change the two Interfaces (Matcher and Selector) anyway,
> > so it shouldn't hurt to add the SourceResolver into one signature.
>
> Mmh... not so sure now. After more thinking, it appears to me we should
> keep separate interfaces for Matcher and PreparedMatcher. This would
> reduce sitemap setup time for Matchers that don't require it and allow
> to keep the pattern parameter as a String, as you seem to prefer it, for
> non-prepared matchers. More about this soon...
The whole filter proposal I had a while back would supercede the matcher/selector
interface, and possibly be a base class for them. The whole thing is that
they affect the pipeline differently. I will have to put together a RT that
redescribes everything.
> > But I think you're right: the objectModel seems exactly the right
> > place to hold such objects, rather than adding separate parameters
> > for each.
> >
> > So the solution should be adding it to the objectModel and removing
> > the parameter from the methods. This has three disadvantages: first -
> > of course - incompatible interface changes and second some slight
> > performance loss as nearly each component first queries the objectModel
> > to get the SourceResolver before using it. The third one: the code
> > becomes less readable as one more object is hidden in a Map.
>
> Several points here :
> - incompatible interface changes : interfaces that have today both
> object model and SourceResolver can live unchanged with an enhanced
> object model. This small inconsistency would be the price for
> compatibility.
> - performance loss : right, but consider the request : it's much more
> used than the source resolver and is only accessible from the object
> model
> - less readable code : agree. Take a look a the new ObjectModelHelper in
> the 2.1 cvs : I often use this pattern to provide typed access to
> well-known entries in a Map or request and session attributes.
I like the ObjectModelHelper idea, and now wonder why it wasn't introduced
sooner.
The idea behind the object model is a method of providing a unique
context per request. This is distinct fromt the Context object which is
used to provide a unique static (as in unchanging) context.
To this end, I would rather extend the ObjectModelHelper idea to the point
where the ObjectModel is a first class citizen. I originally thought that
the Environment class was going to take on this role (as of last year).
It turns out that there are other purposes for the Environment. It makes
sense that the ObjectModel should have accessors for specific environment
components (Request, Response, Session, etc.). Since this does not affect
Sitemap Factories (something I dislike anyway) I will post this in another
RT regarding the environment model--which would require some deprecation.
> > Looking at all the RTs which passed in over the last weeks
> > and looking through my own wish-list for the Cocoon development,
> > I fear that there might be incompatible interface changes after a
> > final release, anyway. Having this in mind, I would prefer only adding
> > the SourceResolver to the signature of Matcher and Selector
> > and leaving everything else as it is.
> >
> > Carsten
>
> Would you mind telling us about your wish list ?
If the Matcher and Selector receive the SourceResolver through the ObjectMap,
then there would be no need. In fact the new ObjectMap first class citizen
would be able to extend Map so that the signatures of most methods do not need
to be changed yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: The Problems with Sitemap Factories
Posted by Martin Man <Ma...@seznam.cz>.
On Thu, Oct 18, 2001 at 11:22:28AM +0200, Sylvain Wallez wrote:
>
>
> Carsten Ziegeler a écrit :
> </snip>
>
> Yep : HEY, TEAM, WHAT DO YOU THINK ?
>
> > We have to change the two Interfaces (Matcher and Selector) anyway,
> > so it shouldn't hurt to add the SourceResolver into one signature.
>
>
> Several points here :
> - incompatible interface changes : interfaces that have today both
> object model and SourceResolver can live unchanged with an enhanced
> object model. This small inconsistency would be the price for
> compatibility.
I agree completely here, +1 for adding sourceResolver to the objectModel and
in the future we can deprecate the methods which have it as a parameter and
create new ones that take it from the objectModel instead
> - performance loss : right, but consider the request : it's much more
> used than the source resolver and is only accessible from the object
> model
i think the same, even for the performance one map lookup shouldn't hurt that
much (though never did any tests !!!)
> - less readable code : agree. Take a look a the new ObjectModelHelper in
> the 2.1 cvs : I often use this pattern to provide typed access to
> well-known entries in a Map or request and session attributes.
took a look and personally like it, it's leaving me though meditating
philosophically wheter java is the right language if you consider these tons
of wrapping code for get/set methods laying around :-?.... but yes, this
helper will make code cleaner :-))
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
ciao,
martin
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: The Problems with Sitemap Factories
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> > > Sylvain Wallez wrote:
> > >
> > > Carsten Ziegeler a écrit :
> > > >
> > > <snip/>
> > >
> > > > > There's another point on which we still didn't came to a
> > > clear decision
> > > > > : what about making the SourceResolver available to matchers and
> > > > > selectors ? Can't it be simply added to the ObjectModel ?
> > > > >
> > > > To be compatible we shoud pass the SourceResolver as a
> separate object
> > > > in the method as the other interfaces do the same.
> > >
> > > Mmmh... and what about the other way ? If the SourceResolver becomes
> > > generally available, let's add it to the object model so that we don't
> > > have to pass it as a parameter everywhere.
> > >
> > > If we don't want to change now APIs that have this parameter, we can
> > > "deprecate" its use (in the doc, because we cannot put
> @deprecated on a
> > > parameter). These methods will have two ways to access the
> > > SourceResolver, but this shouldn't hurt.
> > >
> > > This will avoid API changes now (no more, no less parameters) and
> > > prepare for a future release where these parameters would be removed.
> > > Also, the interpreted sitemap to come may allow to handle more easily
> > > different interfaces that implement a single sitemap element
> than today
> > > (I'm starting heavy thinking about that ;)
> > >
> > > Thoughts ?
> > >
> > I really would like to hear other opinions on this than our two's.
>
> Yep : HEY, TEAM, WHAT DO YOU THINK ?
>
> > We have to change the two Interfaces (Matcher and Selector) anyway,
> > so it shouldn't hurt to add the SourceResolver into one signature.
>
> Mmh... not so sure now. After more thinking, it appears to me we should
> keep separate interfaces for Matcher and PreparedMatcher. This would
> reduce sitemap setup time for Matchers that don't require it and allow
> to keep the pattern parameter as a String, as you seem to prefer it, for
> non-prepared matchers. More about this soon...
>
Eagerly waiting...
> > But I think you're right: the objectModel seems exactly the right
> > place to hold such objects, rather than adding separate parameters
> > for each.
> >
> > So the solution should be adding it to the objectModel and removing
> > the parameter from the methods. This has three disadvantages: first -
> > of course - incompatible interface changes and second some slight
> > performance loss as nearly each component first queries the objectModel
> > to get the SourceResolver before using it. The third one: the code
> > becomes less readable as one more object is hidden in a Map.
>
> Several points here :
> - incompatible interface changes : interfaces that have today both
> object model and SourceResolver can live unchanged with an enhanced
> object model. This small inconsistency would be the price for
> compatibility.
Hm, also I don't like it, this might be a solution with minimum problems.
> - performance loss : right, but consider the request : it's much more
> used than the source resolver and is only accessible from the object
> model
> - less readable code : agree. Take a look a the new ObjectModelHelper in
> the 2.1 cvs : I often use this pattern to provide typed access to
> well-known entries in a Map or request and session attributes.
I'm not sure if the Request is used more than the SourceResolver.
But let's not argue about that. I don't like looking up Request and
Response objects from the objectModel, either.
Yesterday I was thinking if I should make a proposal to change the
type of the objectmodel from a Map to a custom class. The interface
looked similar to your ObjectModelHelper with addition get() and
put() methods to hold any objects in it - like the map currently does.
I discarded this, as it might be a too dramatical interface change.
>
> Ok, now let's wait for other peoples opinion.
>
Yupp!
> > Looking at all the RTs which passed in over the last weeks
> > and looking through my own wish-list for the Cocoon development,
> > I fear that there might be incompatible interface changes after a
> > final release, anyway. Having this in mind, I would prefer only adding
> > the SourceResolver to the signature of Matcher and Selector
> > and leaving everything else as it is.
> >
> > Carsten
>
> Would you mind telling us about your wish list ?
No I don't mind and I will from time to time send a RT (as I did over
the last weeks). But I will not do this before we have the final release.
Sorry, but we still haven't had any release, so we should more
focus in this then on new great ideas. (Of course, these ideas are
always welcome and appreciated).
Carsten
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.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: The Problems with Sitemap Factories
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
> > Sylvain Wallez wrote:
> >
> > Carsten Ziegeler a écrit :
> > >
> > <snip/>
> >
> > > > There's another point on which we still didn't came to a
> > clear decision
> > > > : what about making the SourceResolver available to matchers and
> > > > selectors ? Can't it be simply added to the ObjectModel ?
> > > >
> > > To be compatible we shoud pass the SourceResolver as a separate object
> > > in the method as the other interfaces do the same.
> >
> > Mmmh... and what about the other way ? If the SourceResolver becomes
> > generally available, let's add it to the object model so that we don't
> > have to pass it as a parameter everywhere.
> >
> > If we don't want to change now APIs that have this parameter, we can
> > "deprecate" its use (in the doc, because we cannot put @deprecated on a
> > parameter). These methods will have two ways to access the
> > SourceResolver, but this shouldn't hurt.
> >
> > This will avoid API changes now (no more, no less parameters) and
> > prepare for a future release where these parameters would be removed.
> > Also, the interpreted sitemap to come may allow to handle more easily
> > different interfaces that implement a single sitemap element than today
> > (I'm starting heavy thinking about that ;)
> >
> > Thoughts ?
> >
> I really would like to hear other opinions on this than our two's.
Yep : HEY, TEAM, WHAT DO YOU THINK ?
> We have to change the two Interfaces (Matcher and Selector) anyway,
> so it shouldn't hurt to add the SourceResolver into one signature.
Mmh... not so sure now. After more thinking, it appears to me we should
keep separate interfaces for Matcher and PreparedMatcher. This would
reduce sitemap setup time for Matchers that don't require it and allow
to keep the pattern parameter as a String, as you seem to prefer it, for
non-prepared matchers. More about this soon...
> But I think you're right: the objectModel seems exactly the right
> place to hold such objects, rather than adding separate parameters
> for each.
>
> So the solution should be adding it to the objectModel and removing
> the parameter from the methods. This has three disadvantages: first -
> of course - incompatible interface changes and second some slight
> performance loss as nearly each component first queries the objectModel
> to get the SourceResolver before using it. The third one: the code
> becomes less readable as one more object is hidden in a Map.
Several points here :
- incompatible interface changes : interfaces that have today both
object model and SourceResolver can live unchanged with an enhanced
object model. This small inconsistency would be the price for
compatibility.
- performance loss : right, but consider the request : it's much more
used than the source resolver and is only accessible from the object
model
- less readable code : agree. Take a look a the new ObjectModelHelper in
the 2.1 cvs : I often use this pattern to provide typed access to
well-known entries in a Map or request and session attributes.
Ok, now let's wait for other peoples opinion.
> Looking at all the RTs which passed in over the last weeks
> and looking through my own wish-list for the Cocoon development,
> I fear that there might be incompatible interface changes after a
> final release, anyway. Having this in mind, I would prefer only adding
> the SourceResolver to the signature of Matcher and Selector
> and leaving everything else as it is.
>
> Carsten
Would you mind telling us about your wish list ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: The Problems with Sitemap Factories
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> <snip/>
>
> > > There's another point on which we still didn't came to a
> clear decision
> > > : what about making the SourceResolver available to matchers and
> > > selectors ? Can't it be simply added to the ObjectModel ?
> > >
> > To be compatible we shoud pass the SourceResolver as a separate object
> > in the method as the other interfaces do the same.
>
> Mmmh... and what about the other way ? If the SourceResolver becomes
> generally available, let's add it to the object model so that we don't
> have to pass it as a parameter everywhere.
>
> If we don't want to change now APIs that have this parameter, we can
> "deprecate" its use (in the doc, because we cannot put @deprecated on a
> parameter). These methods will have two ways to access the
> SourceResolver, but this shouldn't hurt.
>
> This will avoid API changes now (no more, no less parameters) and
> prepare for a future release where these parameters would be removed.
> Also, the interpreted sitemap to come may allow to handle more easily
> different interfaces that implement a single sitemap element than today
> (I'm starting heavy thinking about that ;)
>
> Thoughts ?
>
I really would like to hear other opinions on this than our two's.
We have to change the two Interfaces (Matcher and Selector) anyway,
so it shouldn't hurt to add the SourceResolver into one signature.
But I think you're right: the objectModel seems exactly the right
place to hold such objects, rather than adding separate parameters
for each.
So the solution should be adding it to the objectModel and removing
the parameter from the methods. This has three disadvantages: first -
of course - incompatible interface changes and second some slight
performance loss as nearly each component first queries the objectModel
to get the SourceResolver before using it. The third one: the code
becomes less readable as one more object is hidden in a Map.
Looking at all the RTs which passed in over the last weeks
and looking through my own wish-list for the Cocoon development,
I fear that there might be incompatible interface changes after a
final release, anyway. Having this in mind, I would prefer only adding
the SourceResolver to the signature of Matcher and Selector
and leaving everything else as it is.
Carsten
> > Carsten
> >
> > > Sylvain.
> > > --
> > > Sylvain Wallez
> > > Anyware Technologies - http://www.anyware-tech.com
> > >
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.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: The Problems with Sitemap Factories
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
<snip/>
> > There's another point on which we still didn't came to a clear decision
> > : what about making the SourceResolver available to matchers and
> > selectors ? Can't it be simply added to the ObjectModel ?
> >
> To be compatible we shoud pass the SourceResolver as a separate object
> in the method as the other interfaces do the same.
Mmmh... and what about the other way ? If the SourceResolver becomes
generally available, let's add it to the object model so that we don't
have to pass it as a parameter everywhere.
If we don't want to change now APIs that have this parameter, we can
"deprecate" its use (in the doc, because we cannot put @deprecated on a
parameter). These methods will have two ways to access the
SourceResolver, but this shouldn't hurt.
This will avoid API changes now (no more, no less parameters) and
prepare for a future release where these parameters would be removed.
Also, the interpreted sitemap to come may allow to handle more easily
different interfaces that implement a single sitemap element than today
(I'm starting heavy thinking about that ;)
Thoughts ?
> Carsten
>
> > Sylvain.
> > --
> > Sylvain Wallez
> > Anyware Technologies - http://www.anyware-tech.com
> >
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: The Problems with Sitemap Factories
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> > > Stefano Mazzocchi wrote:
> > >
> > > Carsten Ziegeler wrote:
> > > >
> > > > Hi Team,
> > > >
> > > > I would like to propose that we get rid of the sitemap factories,
> > > > the selector and matcher factory.
> > > >
> > > > I see at least three reasons for this:
> > > > - If you want to use a matcher factory inside a subsitemap,
> > > > you currently MUST redefine it in the subsitemap as it is
> > > > not "inherited" from the parent sitemap. This is true
> > > > of course also true for selectors (I entered this already
> > > > in bugzilla).
> > > > Using matchers and selectors in subsitemaps becomes very
> > > > error prone as you always as a sitemap editor have to be
> > > > aware if it is *implemented* as a factory or not. I think
> > > > the sitemap editor does not have to know about such technical
> > > > details.
> > > > - The factories are hard to code. Java code generated from strings
> > > > is not so easy to write.
> > > > - This is needed for the new RT, like the recent Tree
> traversal approach
> > > >
> > > > So I'm +3 on removing the factories and this even for the
> final release!
> > >
> > > +1, whatever makes it easier to write subsitemaps I'm all for it.
> > >
> > > Let's start removing the code compilation thing.
> > >
> > So any volunteers? We should first change the cvs head, test if
> > everything is fine and then back porting it to the 2.0 branch.
> >
> > Carsten
> >
> I'd like to volunteer on this : I'm really interested in this subject,
> along with the future developments it will allow (flowmap, transparent
> transformers for link rewriting, etc).
>
> However, I don't have so much spare time so it won't be very fast : I'm
> targetting beginning of november.
Great!
>
> An initial step will be to add the new PreparedMatcher we have formerly
> discussed of to replace CodeFactory. This will allow to quickly
> introduce API changes within the current compiled sitemap so that people
> can start using them and be ready when the tree traversal implementation
> will be finished.
>
> There's another point on which we still didn't came to a clear decision
> : what about making the SourceResolver available to matchers and
> selectors ? Can't it be simply added to the ObjectModel ?
>
To be compatible we shoud pass the SourceResolver as a separate object
in the method as the other interfaces do the same.
Carsten
> Sylvain.
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.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: The Problems with Sitemap Factories
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
> > Stefano Mazzocchi wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > Hi Team,
> > >
> > > I would like to propose that we get rid of the sitemap factories,
> > > the selector and matcher factory.
> > >
> > > I see at least three reasons for this:
> > > - If you want to use a matcher factory inside a subsitemap,
> > > you currently MUST redefine it in the subsitemap as it is
> > > not "inherited" from the parent sitemap. This is true
> > > of course also true for selectors (I entered this already
> > > in bugzilla).
> > > Using matchers and selectors in subsitemaps becomes very
> > > error prone as you always as a sitemap editor have to be
> > > aware if it is *implemented* as a factory or not. I think
> > > the sitemap editor does not have to know about such technical
> > > details.
> > > - The factories are hard to code. Java code generated from strings
> > > is not so easy to write.
> > > - This is needed for the new RT, like the recent Tree traversal approach
> > >
> > > So I'm +3 on removing the factories and this even for the final release!
> >
> > +1, whatever makes it easier to write subsitemaps I'm all for it.
> >
> > Let's start removing the code compilation thing.
> >
> So any volunteers? We should first change the cvs head, test if
> everything is fine and then back porting it to the 2.0 branch.
>
> Carsten
>
I'd like to volunteer on this : I'm really interested in this subject,
along with the future developments it will allow (flowmap, transparent
transformers for link rewriting, etc).
However, I don't have so much spare time so it won't be very fast : I'm
targetting beginning of november.
An initial step will be to add the new PreparedMatcher we have formerly
discussed of to replace CodeFactory. This will allow to quickly
introduce API changes within the current compiled sitemap so that people
can start using them and be ready when the tree traversal implementation
will be finished.
There's another point on which we still didn't came to a clear decision
: what about making the SourceResolver available to matchers and
selectors ? Can't it be simply added to the ObjectModel ?
Sylvain.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: The Problems with Sitemap Factories
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> >
> > Hi Team,
> >
> > I would like to propose that we get rid of the sitemap factories,
> > the selector and matcher factory.
> >
> > I see at least three reasons for this:
> > - If you want to use a matcher factory inside a subsitemap,
> > you currently MUST redefine it in the subsitemap as it is
> > not "inherited" from the parent sitemap. This is true
> > of course also true for selectors (I entered this already
> > in bugzilla).
> > Using matchers and selectors in subsitemaps becomes very
> > error prone as you always as a sitemap editor have to be
> > aware if it is *implemented* as a factory or not. I think
> > the sitemap editor does not have to know about such technical
> > details.
> > - The factories are hard to code. Java code generated from strings
> > is not so easy to write.
> > - This is needed for the new RT, like the recent Tree traversal approach
> >
> > So I'm +3 on removing the factories and this even for the final release!
>
> +1, whatever makes it easier to write subsitemaps I'm all for it.
>
> Let's start removing the code compilation thing.
>
So any volunteers? We should first change the cvs head, test if
everything is fine and then back porting it to the 2.0 branch.
Carsten
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> 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: The Problems with Sitemap Factories
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi Team,
>
> I would like to propose that we get rid of the sitemap factories,
> the selector and matcher factory.
>
> I see at least three reasons for this:
> - If you want to use a matcher factory inside a subsitemap,
> you currently MUST redefine it in the subsitemap as it is
> not "inherited" from the parent sitemap. This is true
> of course also true for selectors (I entered this already
> in bugzilla).
> Using matchers and selectors in subsitemaps becomes very
> error prone as you always as a sitemap editor have to be
> aware if it is *implemented* as a factory or not. I think
> the sitemap editor does not have to know about such technical
> details.
> - The factories are hard to code. Java code generated from strings
> is not so easy to write.
> - This is needed for the new RT, like the recent Tree traversal approach
>
> So I'm +3 on removing the factories and this even for the final release!
+1, whatever makes it easier to write subsitemaps I'm all for it.
Let's start removing the code compilation thing.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org