On 12.04.2005 12:23, Jochen Kuhnle wrote:
So do I enter the context patch into bugzilla now?
What's the progress on this? Though I found the bug [1] I can not read
it, bugzilla has problems at the moment.
Joerg
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=34781
Stefano Mazzocchi [EMAIL PROTECTED] wrote on 11.04.2005 17:57:54:
Upayavira wrote:
FWIW, stefano's -1 was for dynamic sitemaps, not for a context
attribute
to map:mount.
correct.
--
Stefano.
So do I enter the context patch into bugzilla now?
Regards,
Jochen
On Mar, 12 de Abril de 2005, 5:23, Jochen Kuhnle dijo:
Stefano Mazzocchi [EMAIL PROTECTED] wrote on 11.04.2005 17:57:54:
Upayavira wrote:
FWIW, stefano's -1 was for dynamic sitemaps, not for a context
attribute
to map:mount.
correct.
--
Stefano.
So do I enter the context patch into
On Apr 11, 2005 5:44 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
what about describing the sitemap in LDAP directly, you could use
netinfo to edit it! hmmm, no, wait, what about sitemap via email? you
post the sitemap
Gianugo Rabellino wrote:
On Apr 11, 2005 5:44 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I mean, look at you: sitemap via webdav? via JCR170? what's next? SOAP?
what about describing the sitemap in LDAP directly, you could use
netinfo to edit it! hmmm, no, wait, what about sitemap via email?
Sylvain Wallez wrote:
Well, as long as there is the http route, blocking cocoon: will just
lead people to use an uglier workaround which you just engraved in the
archives for posterity ;-)
So if we're to enforce something, it should be that a sitemap is a file,
or a classpath resource
Gianugo Rabellino wrote:
On Apr 10, 2005 10:17 PM, Sylvain Wallez [EMAIL PROTECTED] wrote:
So if we're to enforce something, it should be that a sitemap is a file,
or a classpath resource (yes, I have this usecase).
Yep. Tricky, though: I sure can imagine sitemaps stored anywhere (why
not
Jochen Kuhnle wrote:
Hi Sylvain,
I agree that generated sitemaps are a somewhat more sophisticated use of
Cocoon. However, I think it is a nice feature to have. My main reason for
this is that I want to hide the nuts and bolts of sitemaps from site
maintainers and just want to give them a
Stefano Mazzocchi wrote:
So, if you think there is a functionality missing in the sitemap,
propose a way to fix it, don't propose a way for you to route around it.
I agree with Stefano. And AFAIU the problem that has led to this discussion will
go away with real blocks and virtual sitemap
Gianugo Rabellino wrote:
On Apr 10, 2005 10:17 PM, Sylvain Wallez [EMAIL PROTECTED] wrote:
So if we're to enforce something, it should be that a sitemap is a file,
or a classpath resource (yes, I have this usecase).
Yep. Tricky, though: I sure can imagine sitemaps stored anywhere (why
not a
And I thought nobody would care about this small change :) Since Cocoon is
all about access to many sources and generated XML, I as a developer am
actually surprised that what works with URLs everywhere does not work with
sitemap URLs. I think this is inconsistent, and when writing my initial
Jochen Kuhnle wrote:
map:mount src=usersitemap.xmap prefix=~{1}/
context=/home/{1}/pages//
I'm +1 for this form; and IIUC Antonio has similar use case: same sitemap for
different directories.
Vadim
On Lun, 11 de Abril de 2005, 8:09, Vadim Gritsenko dijo:
Jochen Kuhnle wrote:
map:mount src=usersitemap.xmap prefix=~{1}/
context=/home/{1}/pages//
I'm +1 for this form; and IIUC Antonio has similar use case: same sitemap
for
different directories.
Yep. I have thesame sitemap for diferent
Antonio Gallardo wrote:
On Lun, 11 de Abril de 2005, 8:09, Vadim Gritsenko dijo:
Jochen Kuhnle wrote:
map:mount src=usersitemap.xmap prefix=~{1}/
context=/home/{1}/pages//
I'm +1 for this form; and IIUC Antonio has similar use case: same sitemap
for
different directories.
Yep. I have thesame
Reinhard Poetz wrote:
Stefano Mazzocchi wrote:
So, if you think there is a functionality missing in the sitemap,
propose a way to fix it, don't propose a way for you to route around it.
I agree with Stefano. And AFAIU the problem that has led to this
discussion will go away with real blocks and
Upayavira wrote:
Antonio Gallardo wrote:
On Lun, 11 de Abril de 2005, 8:09, Vadim Gritsenko dijo:
Jochen Kuhnle wrote:
map:mount src=usersitemap.xmap prefix=~{1}/
context=/home/{1}/pages//
I'm +1 for this form; and IIUC Antonio has similar use case: same
sitemap
for
different directories.
Yep.
On Apr 10, 2005 4:24 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Sylvain Wallez wrote:
So, although we may accept a new context attribute (I'm currently -0.9
for this), I'm -1 for accepting dynamically generated sitemaps.
I'm -1 as well. (that was easy to guess ;-)
Uhm, first of all
Gianugo Rabellino wrote:
useful in contexts other than dynamic sitemaps, so I'd welcome that
addition. WRT dynamic sitemaps, I don't quite have a real opinion, I
can clearly see how it might lead to abuse, but I also tend to think
that Cocoon, as a framework, should allow applications built
Le 10 avr. 05, à 17:54, Gianugo Rabellino a écrit :
...A check failing with an error message would
be enough to prevent stupid people like me to try it again in the
future (even though there will always be the http route...).
And making it a configurable switch with a big warning on it would
Antonio Gallardo wrote:
On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo:
Sylvain Wallez [EMAIL PROTECTED] wrote on 09.04.2005 20:51:41:
In other words, should it be:
map:mount src=foo/bar/ context=baz/
and
map:sitemap
or
map:mount src=foo/bar//
and
map:sitemap context=baz/
My
Gianugo Rabellino wrote:
On Apr 10, 2005 4:24 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
Sylvain Wallez wrote:
So, although we may accept a new context attribute (I'm currently -0.9
for this), I'm -1 for accepting dynamically generated sitemaps.
I'm -1 as well. (that was easy to
On Apr 10, 2005 10:17 PM, Sylvain Wallez [EMAIL PROTECTED] wrote:
Gianugo Rabellino wrote:
However, if it's agreed once and for all that
dynamic sitemaps are to be considered harmful, so be it and let's
enforce it: it slipped through already, and now it doesn't work
anymore because of a
On Dom, 10 de Abril de 2005, 15:12, Sylvain Wallez dijo:
Antonio Gallardo wrote:
On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo:
Sylvain Wallez [EMAIL PROTECTED] wrote on 09.04.2005 20:51:41:
In other words, should it be:
map:mount src=foo/bar/ context=baz/
and
map:sitemap
or
Hi Jochen,
your idea sounds good to me. Can you please add a feature request to
bugzilla with your patch?
Thanks
Carsten
[EMAIL PROTECTED] wrote:
Hi, I suggest a new parameter for map:mount that specifies the context of
the sitemap, i.e. the URL against which all relative URLs are resolved.
Carsten Ziegeler wrote:
Hi Jochen,
your idea sounds good to me. Can you please add a feature request to
bugzilla with your patch?
Well, having dynamically generated sitemaps doesn't seem that good to me.
About Gianugo's problem: we had a discussion where it appears the
sitemap is the
Sylvain Wallez wrote:
So, although we may accept a new context attribute (I'm currently -0.9
for this), I'm -1 for accepting dynamically generated sitemaps.
Hmm, really? And what if I don't use the cocoon protocol but the http
and address Cocoon externally? The sitemap is created dynamically
Le 9 avr. 05, à 19:21, Sylvain Wallez a écrit :
...Cocoon is sometimes too much powerful and people use too much
cocoon: dynamic URLs when other systems would require to dump
something on disk, and this can lead to overly complex and and very
unefficient architectures.
So, although we may
and every
file.
Regards,
Jochen
Sylvain Wallez [EMAIL PROTECTED]
09.04.2005 19:21
Please respond to
dev@cocoon.apache.org
To
dev@cocoon.apache.org
cc
Subject
Re: Manually specifying a mounted sub sitemap's context
Carsten Ziegeler wrote:
Hi Jochen,
your idea sounds good to me. Can you
Bertrand Delacretaz wrote:
Le 9 avr. 05, à 19:21, Sylvain Wallez a écrit :
...Cocoon is sometimes too much powerful and people use too much
cocoon: dynamic URLs when other systems would require to dump
something on disk, and this can lead to overly complex and and very
unefficient
29 matches
Mail list logo
