Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ats37@hotmail.com designates
 65.54.175.40 as permitted sender)
Message-ID: <BAY104-F30424C1D7880E348B9C49DAD7A0@phx.gbl>
In-Reply-To: <Pine.LNX.4.64.0606221449130.636@lapgp.otego.com>
From: "Andrew Stevens" <ats37@hotmail.com>
To: dev@cocoon.apache.org
Subject: Re: svn commit: r416308 -
 /cocoon/trunk/core/cocoon-core/src/test/java/org/apach
Date: Fri, 23 Jun 2006 23:26:36 +0100
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

>From: Giacomo Pati <giacomo@apache.org>
>Date: Thu, 22 Jun 2006 14:58:05 +0200 (CEST)
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>On Thu, 22 Jun 2006, Carsten Ziegeler wrote:
>
>>Date: Thu, 22 Jun 2006 11:59:35 +0200
>>From: Carsten Ziegeler <cziegeler@apache.org>
>>Reply-To: dev@cocoon.apache.org
>>To: dev@cocoon.apache.org
>>Subject: Re: svn commit: r416308 -
>>     
>>/cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/util/Wildca
>>     rdMatcherHelperTestCase.java
>>
>>Giacomo Pati wrote:
>>>>>
>>>>>-    public void testEmptyPattern() throws Exception {
>>>>>+    public void test21WildcardURIMatch()
>>>>>+    throws Exception {
>>>>>+        Map result = WildcardMatcherHelper.match("*/**", 
>>>>>"samples/blocks/");
>>>>>+        assertNotNull(result);
>>>>>+        assertEquals("", result.get("1"));
>>>
>>>Oh, if this test succeeds isn't it wrong? Shouldn't {1}be "samples"?
>>>
>>Ups, yep - damn copy-paste. I corrected the test case, but it still
>>fails as the result is null.
>
>Ok, looking at those matching sample we need to define how matching is 
>suppose to work. Consider the following sample
>
>Pattern		String
>**/*/**		foo/bar/baz/buz/
>
>What is the result you expect for {1}, {2}, and {3} ? Possible values could 
>be:
>
>{1}="foo"		{2}="bar"	{3}="baz/buz"
>{1}="foo/bar"		{2}="baz"	{3}="buz"
>{1}="foo/bar/baz"	{2}="buz"	{3}=""
>
>which one do you think is the correct one?

If it were the regex (.*)/([^/]*)/(.*) then what would the result be?  
Unless there's a compelling reason not to, it might as well behave 
similarly.  I can't test it myself right now, but I think that regex would 
give the third option (i.e. as greedy as possible as early as it can be).

However, if in fact that's not the case, shouldn't {3} include the trailing 
slash?


Andrew.