Tree Traversal Apologies

[Jason Foster <ja...@uwaterloo.ca>]

I'd like to apologize for putting forth an idea and then disappearing for 3
days.  It was Canadian Thanksgiving and the dial-up connection at my
fiancée's parents' place was unusable.

I'm currently going through the replies to the original idea, as well as the
current sitemap documentation, to figure out how to model the traversal.
I'll try to have a more fleshed out idea tomorrow.

As a side note, what is the opinion out there of a RegExpTable, which is
like a HashTable, except that all of the keys are RegExp patterns?  The
RegExpTable returns an array of objects whose regular expression keys match
the query string equally well?  This seemed like one (very naïve) way to
deal with the different pipelines (at least those that use regular
expressions).

I'm off to struggle with the sitemap.  After 3 years of trying to figure out
engineering education, I have to admit that source code looks a little like
a foreign language :)

Jason Foster


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

AW: Tree Traversal Apologies

[Carsten Ziegeler <cz...@sundn.de>]

> Sergio Carvalho wrote:
>
> On Tue, 09 Oct 2001 19:16:36 -0400, Jason Foster wrote:
> From: Jason Foster <ja...@uwaterloo.ca>
> --
>
> > As a side note, what is the opinion out there of a RegExpTable, which is
> > like a HashTable, except that all of the keys are RegExp patterns?  The
> > RegExpTable returns an array of objects whose regular
> expression keys match
> > the query string equally well?  This seemed like one (very naïve) way to
> > deal with the different pipelines (at least those that use regular
> > expressions).
>
> hmm. Why not take the concept a bit further, and implement a
> MatchDictionary,
> implementing the Java dictionary interface, which delegates the
> actual matching
> to Matcher components. I'm thinking that this MatchDictionary can
> internally
> order Matches so that most frequently used ones are tested first
> to minimize
> match tests. A warning though: in the current implementation,
> matches are not
> required to be mutually exclusive, so match order is relevant.
> And with the
> current interfaces, it is not possible to prove that two matches
> are mutually
> exclusive. Implementing this optimization would break the current
> API -- even if
> this is an undocumented behaviour.
>
And actually the situation is more complicated. It is possible
that more than one match is used to process the request. One simple
example:
<match pattern="*.html">
  <map:generate src="docs/{2}.xml"/>
</match>
<match pattern="index.html">
  <map:transform src="index2doc.xsl"/>
</match>
<match pattern="*.html">
  <map:transform src="doc2html.xsl"/>
  <map:serialize/>
</match>

Perhaps this example doesn't make sense. Perhaps there are more solutions
to solve the problem presented above. Doesn't matter.
What's important is: it is possible by design!

Carsten



> --
> Sergio Carvalho
> ---------------
> sergio.carvalho@acm.org
>
> If at first you don't succeed, skydiving is not for you
>
> ---------------------------------------------------------------------
> 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: Tree Traversal Apologies

[Sergio Carvalho <se...@acm.org>]

On Tue, 09 Oct 2001 19:16:36 -0400, Jason Foster wrote:
From: Jason Foster <ja...@uwaterloo.ca>
--

> As a side note, what is the opinion out there of a RegExpTable, which is
> like a HashTable, except that all of the keys are RegExp patterns?  The
> RegExpTable returns an array of objects whose regular expression keys match
> the query string equally well?  This seemed like one (very naïve) way to
> deal with the different pipelines (at least those that use regular
> expressions).

hmm. Why not take the concept a bit further, and implement a MatchDictionary,
implementing the Java dictionary interface, which delegates the actual matching
to Matcher components. I'm thinking that this MatchDictionary can internally
order Matches so that most frequently used ones are tested first to minimize
match tests. A warning though: in the current implementation, matches are not
required to be mutually exclusive, so match order is relevant. And with the
current interfaces, it is not possible to prove that two matches are mutually
exclusive. Implementing this optimization would break the current API -- even if
this is an undocumented behaviour.

--
Sergio Carvalho
---------------
sergio.carvalho@acm.org

If at first you don't succeed, skydiving is not for you

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org