You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/11/12 13:23:19 UTC
Re: Bastardized URL protocol (Re: [RT] ComponentizedProcessor)
Antonio Gallardo wrote:
> Sylvain Wallez dijo:
>
>>So since we _need_ to be able to specify URLs relative to the current
>>sitemap, what do you suggest? A subprotocol like what we have for
>>"cocoon:raw", another protocol like "current-sitemap:"?
>>
>>Just like Bruno, I'm happy with the "cocoon:/" and "cocoon://" we have
>>today. Moreover, I have not seen any of the people to which I explained
>>this behaviour complaining about URL syntax abuse.
>>
>>Also, I'm not following cocoon-users closely enough, but does this Q&A
>>you describe above come often about the "cocoon:" protocol?
>
>
> The answer is simple: With good documentation nobody will be losed. :-D
>
Hmm. Have you ever mentored someone who did this:
public class MyFirstClass
{
private String helloString;
public void setHello( String helloMessage )
{
String helloString = helloMessage;
}
public void printHello()
{
System.out.println(helloString);
}
}
and then wondered why it didn't work? I have.
All the good documentation in the world won't keep it from happening.
All that will happen is a bunch of embarassed folks who don't complain
about it because they don't want to look stupid.
Ok class, what happened wrong in the above example?
Re: Bastardized URL protocol
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 14:49, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>>> Sigh. I'm not going to force you guys not to make the same mistake
>>> again.
>>> It seems I am the only one who doesn't like it, even though I
>>> strongly
>>> encourage at least stripping out *one* of the forward slashes so
>>> that a
>>> relative URI has no forward slashes at the beginning at all.
>> and break all sitemaps out there?
>
> As far as I know this was all about adding new semantics to the
> "context:" protocol--so I wanted to encourage everyone not to
> do it in the same way as the "cocoon:" protocol. So no, not break
> all sitemaps out there.
Ah, ok. Lost the context, sorry.
But wouldn't it be even *more* confusing to have two different ways to
handle with protocols?
--
Stefano.
Re: Bastardized URL protocol
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
>> Sigh. I'm not going to force you guys not to make the same mistake
>> again.
>> It seems I am the only one who doesn't like it, even though I strongly
>> encourage at least stripping out *one* of the forward slashes so that a
>> relative URI has no forward slashes at the beginning at all.
>
>
> and break all sitemaps out there?
>
As far as I know this was all about adding new semantics to the
"context:" protocol--so I wanted to encourage everyone not to
do it in the same way as the "cocoon:" protocol. So no, not break
all sitemaps out there.
Re: Bastardized URL protocol
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Nov 2003, at 11:35, Berin Loritsch wrote:
> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>> Berin Loritsch wrote:
>>>
>>>> Just because we have one protocol that is messed up and we can't
>>>> change it
>>>> doesn't mean we should make the same mistakes.
>>>>
>>>
>>> True.
>>>
>>>
>>>> For the Context protocol, I highly recommend doing something other
>>>> than the one slash vs. two approach used for the "cocoon" protocol.
>>>>
>>>> *Something* doesn't have to mean using the xml:base approach
>>>> outlined above.
>>>> But it does mean that we shouldn't repeat the same mistake.
>>>>
>>>
>>> Sorry, I haven't followed the whole discussion, so this might have
>>> been already discussed: why can't we use a new protocol, e.g.
>>> "sitemap:", so context:// is the context :), and sitemap:// resolves
>>> relative to the current sitemap?
>>>
>>> Even using context:// and context:/ is fine for me. Users are used
>>> to it anyway, even if it might not be the most perfect syntax.
>>>
>> +1. And since it perfectly matches the "cocoon://" vs "cocoon:/"
>> difference, I think this will be the most easy to understand rather
>> than "context://" vs "sitemap://".
>
> Sigh. I'm not going to force you guys not to make the same mistake
> again.
> It seems I am the only one who doesn't like it, even though I strongly
> encourage at least stripping out *one* of the forward slashes so that a
> relative URI has no forward slashes at the beginning at all.
and break all sitemaps out there?
--
Stefano.
Re: Bastardized URL protocol
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Berin Loritsch wrote:
>>
>>
>>> Just because we have one protocol that is messed up and we can't
>>> change it
>>> doesn't mean we should make the same mistakes.
>>>
>>
>> True.
>>
>>
>>
>>> For the Context protocol, I highly recommend doing something other
>>> than the one slash vs. two approach used for the "cocoon" protocol.
>>>
>>> *Something* doesn't have to mean using the xml:base approach outlined
>>> above.
>>> But it does mean that we shouldn't repeat the same mistake.
>>>
>>
>> Sorry, I haven't followed the whole discussion, so this might have
>> been already discussed: why can't we use a new protocol, e.g.
>> "sitemap:", so context:// is the context :), and sitemap:// resolves
>> relative to the current sitemap?
>>
>> Even using context:// and context:/ is fine for me. Users are used to
>> it anyway, even if it might not be the most perfect syntax.
>>
>>
>
> +1. And since it perfectly matches the "cocoon://" vs "cocoon:/"
> difference, I think this will be the most easy to understand rather than
> "context://" vs "sitemap://".
Sigh. I'm not going to force you guys not to make the same mistake again.
It seems I am the only one who doesn't like it, even though I strongly
encourage at least stripping out *one* of the forward slashes so that a
relative URI has no forward slashes at the beginning at all.
Do what you will.
Re: Bastardized URL protocol
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Berin Loritsch wrote:
>
>
>>Just because we have one protocol that is messed up and we can't change it
>>doesn't mean we should make the same mistakes.
>>
>>
>True.
>
>
>
>>For the Context protocol, I highly recommend doing something other than the one slash vs. two approach used for the "cocoon" protocol.
>>
>>*Something* doesn't have to mean using the xml:base approach outlined above.
>>But it does mean that we shouldn't repeat the same mistake.
>>
>>
>Sorry, I haven't followed the whole discussion, so this might have been already discussed: why can't we use a new protocol, e.g. "sitemap:", so context:// is the context :), and sitemap:// resolves relative to the current sitemap?
>
>Even using context:// and context:/ is fine for me. Users are used to it anyway, even if it might not be the most perfect syntax.
>
>
+1. And since it perfectly matches the "cocoon://" vs "cocoon:/"
difference, I think this will be the most easy to understand rather than
"context://" vs "sitemap://".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Bastardized URL protocol
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Berin Loritsch wrote:
>
>>Just because we have one protocol that is messed up and we can't change it
>>doesn't mean we should make the same mistakes.
>>
>
> True.
>
>
>>For the Context protocol, I highly recommend doing something other than
>>the one slash vs. two approach used for the "cocoon" protocol.
>>
>>*Something* doesn't have to mean using the xml:base approach
>>outlined above.
>>But it does mean that we shouldn't repeat the same mistake.
>>
>
> Sorry, I haven't followed the whole discussion, so this might have been
> already discussed: why can't we use a new protocol, e.g. "sitemap:",
> so context:// is the context :), and sitemap:// resolves relative
> to the current sitemap?
>
> Even using context:// and context:/ is fine for me. Users are used
> to it anyway, even if it might not be the most perfect syntax.
>
> But I'm against a more complicated way of doing this.
IMNSHO, context: and context:/ are much clearer than context:/ and context://.
IOW a relative URI should never have a beginning slash. It is easier to spot
a mistake when it is between a character that is not there at all vs. not enough
characters.
RE: Bastardized URL protocol
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
> Just because we have one protocol that is messed up and we can't change it
> doesn't mean we should make the same mistakes.
>
True.
> For the Context protocol, I highly recommend doing something other than
> the one slash vs. two approach used for the "cocoon" protocol.
>
> *Something* doesn't have to mean using the xml:base approach
> outlined above.
> But it does mean that we shouldn't repeat the same mistake.
>
Sorry, I haven't followed the whole discussion, so this might have been
already discussed: why can't we use a new protocol, e.g. "sitemap:",
so context:// is the context :), and sitemap:// resolves relative
to the current sitemap?
Even using context:// and context:/ is fine for me. Users are used
to it anyway, even if it might not be the most perfect syntax.
But I'm against a more complicated way of doing this.
Carsten
Re: Bastardized URL protocol
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>
>
> <snip/>
>
>> The only potential solution I see is something like
>>
>> <generate src="cocoon:/path" xml:base="/">
>> <generate src="cocoon:/path" xml:base=".">
>
>
>
> I think that would not be correct usage of the xml:base... Correct usage
> would be something like:
> <generate src="path" xml:base="cocoon:/">
> <generate src="path" xml:base="cocoon:"> <!-- or xml:base="cocoon:." -->
>
> <snip/>
Wouldn't it be much more common to do something like this:
<pipelines xml:base="cocoon:">
<pipeline>
<match uri="**/foo">
<generate src="path"/>
<transform src="path"/>
<serialize/>
</match>
<match uri="**/bar" xml:base="context:/foo/bar">
<generate src="path"/>
<transform src="path"/>
<serialize/>
</match>
</pipeline>
</pipelines>
In other words, the xml:base attribute (according to spec) applies the the
URLs contained in the element it is declared in, as well as to all child
elements--unless a child element overrides it.
>
>> but I'm not sure this makes things any easier or bugs any more
>> evident. For sure, it's more verbose and for back compatibility, we
>> still need to support cocoon://
>>
>> Thoughts?
>
> Any of the above does not look neither elegant nor easier. I'd keep the
> approach we have right now.
>
Just because we have one protocol that is messed up and we can't change it
doesn't mean we should make the same mistakes.
For the Context protocol, I highly recommend doing something other than
the one slash vs. two approach used for the "cocoon" protocol.
*Something* doesn't have to mean using the xml:base approach outlined above.
But it does mean that we shouldn't repeat the same mistake.
Re: Bastardized URL protocol
Posted by Vadim Gritsenko <vg...@apache.org>.
Stefano Mazzocchi wrote:
> On 12 Nov 2003, at 17:18, Berin Loritsch wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Variable scoping aside, do you have any suggestion on how to solve
>>> the protocol issue?
>>> --
>>> Stefano, who reached a point where rants look like a very
>>> inefficient way of solving problems
>>
>>
>> As I mentioned in another email, leverage the xml:base="" attribute
>> part of
>> the XML spec. That provides the base URI with which all relative
>> URIs would
>> be resolved. It's dead simple, obvious, and less error prone than
>> one slash
>> vs. two. Best of all, we don't bastardize any specs.
>
>
> Now, we introduced the ** syntax for matchers and I think it was one
> of the greatest innovations in easy-to-use path-oriented query
> syntaxes, althought non standard. Nobody ever complained and I don't
> think it's because they are too shy to tell us.
<snip/>
> The only potential solution I see is something like
>
> <generate src="cocoon:/path" xml:base="/">
> <generate src="cocoon:/path" xml:base=".">
I think that would not be correct usage of the xml:base... Correct usage
would be something like:
<generate src="path" xml:base="cocoon:/">
<generate src="path" xml:base="cocoon:"> <!-- or xml:base="cocoon:." -->
<snip/>
> but I'm not sure this makes things any easier or bugs any more
> evident. For sure, it's more verbose and for back compatibility, we
> still need to support cocoon://
>
> Thoughts?
Any of the above does not look neither elegant nor easier. I'd keep the
approach we have right now.
Vadim
Re: Bastardized URL protocol
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 17:18, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>> Variable scoping aside, do you have any suggestion on how to solve
>> the protocol issue?
>> --
>> Stefano, who reached a point where rants look like a very inefficient
>> way of solving problems
>
> As I mentioned in another email, leverage the xml:base="" attribute
> part of
> the XML spec. That provides the base URI with which all relative URIs
> would
> be resolved. It's dead simple, obvious, and less error prone than one
> slash
> vs. two. Best of all, we don't bastardize any specs.
Now, we introduced the ** syntax for matchers and I think it was one of
the greatest innovations in easy-to-use path-oriented query syntaxes,
althought non standard. Nobody ever complained and I don't think it's
because they are too shy to tell us.
At the same time I agree that
cocoon:/blah
and
cocoon://blah
don't feel exactly as elegant. Actually
cocoon:foo/bar
and
cocoon:/blah/bar
would be better, IMO, but would be totally back-incompatible at this
point, so it's hard to change this syntax now.
The problem I see with your proposal is that xml:base doesn't really
solve anything: we need to be able to differentiate between
path -> relative to current sitemap
path -> relative to root sitemap
this discrimination has the granularity of the single cocoon:/context:
call, it's not global. The only potential solution I see is something
like
<generate src="cocoon:/path" xml:base="/">
<generate src="cocoon:/path" xml:base=".">
but I don't think xml:base works for this. An alternative is
<generate src="cocoon:/path" relative-to="/">
<generate src="cocoon:/path" relative-to=".">
which would allow to do
<pipeline relative-to="./path">
<match ...>
<generate src="cocoon:/blah"/>
...
that would be equivalent to what today is
<generate src="cocoon:/path/blah"/>
but I'm not sure this makes things any easier or bugs any more evident.
For sure, it's more verbose and for back compatibility, we still need
to support cocoon://
Thoughts?
--
Stefano.
Re: Bastardized URL protocol (Re: [RT] ComponentizedProcessor)
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> Variable scoping aside, do you have any suggestion on how to solve the
> protocol issue?
>
> --
> Stefano, who reached a point where rants look like a very inefficient
> way of solving problems
As I mentioned in another email, leverage the xml:base="" attribute part of
the XML spec. That provides the base URI with which all relative URIs would
be resolved. It's dead simple, obvious, and less error prone than one slash
vs. two. Best of all, we don't bastardize any specs.
The point of my "yawn" example is that braindead mistakes happen. It's best
to make it really obvious what the problem can be.
Re: Bastardized URL protocol (Re: [RT] ComponentizedProcessor)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 13:23, Berin Loritsch wrote:
> Antonio Gallardo wrote:
>> Sylvain Wallez dijo:
>>> So since we _need_ to be able to specify URLs relative to the current
>>> sitemap, what do you suggest? A subprotocol like what we have for
>>> "cocoon:raw", another protocol like "current-sitemap:"?
>>>
>>> Just like Bruno, I'm happy with the "cocoon:/" and "cocoon://" we
>>> have
>>> today. Moreover, I have not seen any of the people to which I
>>> explained
>>> this behaviour complaining about URL syntax abuse.
>>>
>>> Also, I'm not following cocoon-users closely enough, but does this
>>> Q&A
>>> you describe above come often about the "cocoon:" protocol?
>> The answer is simple: With good documentation nobody will be losed.
>> :-D
>
> Hmm. Have you ever mentored someone who did this:
>
> public class MyFirstClass
> {
> private String helloString;
>
> public void setHello( String helloMessage )
> {
> String helloString = helloMessage;
> }
>
> public void printHello()
> {
> System.out.println(helloString);
> }
> }
>
> and then wondered why it didn't work? I have.
>
> All the good documentation in the world won't keep it from happening.
> All that will happen is a bunch of embarassed folks who don't complain
> about it because they don't want to look stupid.
>
> Ok class, what happened wrong in the above example?
Yawn.
Variable scoping aside, do you have any suggestion on how to solve the
protocol issue?
--
Stefano, who reached a point where rants look like a very inefficient
way of solving problems