On Thursday, Aug 14, 2003, at 16:02 Europe/Rome, Bertrand Delacretaz
wrote:
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into pipelines
? E.g :
If it's this way I'd prefer "unless-label" in map:read to make it
On Thursday, Aug 14, 2003, at 14:22 Europe/Rome, Sylvain Wallez wrote:
Jeff Turner wrote:
Isn't the problem there that a is a whole little pipeline
unto itself? If it were broken into two atomic operations:
then we could have a using a
content-aware pipeline, and everything would work.
On Thursday, Aug 14, 2003, at 21:44 Europe/Rome, Andreas Hochsteger
wrote:
Hi!
Sorry, but this discussion seems to tell us one thing:
The current sitemap syntax and cocoon processing model is not really
suitable for such kind of processing.
I completely agree.
All this reminds me of a proposal
On Thursday, Aug 14, 2003, at 21:10 Europe/Rome, Vadim Gritsenko wrote:
PS Keep sitemap syntax clean! Say "No!" to woodo!
Amen!
--
Stefano.
On Thursday, Aug 14, 2003, at 19:07 Europe/Rome, Miles Elam wrote:
Vadim Gritsenko wrote:
Here is another wild (or not?) thought.
Not so wild to me.
All this discussion comes down to the requirement of generating some
XML out of the content usually served by the reader, if that's
possible (a
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Here is another wild (or not?) thought.
All this discussion comes down to the requirement of generating
some XML out of the content usually served by t
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into pipelines ?
E.g :
If it's this way I'd prefer "unless-label" in map:read to make it clear.
Or maybe
would do, meaning "use this unless any views are requeste
On Wed, Aug 13, 2003 at 12:02:04PM +0200, Sylvain Wallez wrote:
> Frederic's question about search engine integration led me to
> questioning myself at how Cocoon's Lucene integration could be able to
> transparently index Word & PDF documents along with XML-produced documents.
>
> There exists
Sylvain Wallez wrote:
Miles Elam wrote:
In other words, the pipeline is full of side effects and dependant
upon things happening behind the curtain (to use a Wizard of Oz
reference). You'd be right in that it adds to the confusion. I
agree with Vadim. This is obfuscation in exchange for two
Vadim Gritsenko wrote:
Ummm... Quick question: What are the use cases for this that are
not handled by existing methods? I mean, couldn't this be handled
with an (as-yet unwritten) action?
Matcher *does* exist:
Heh heh... learning something new everyday.
- Miles Elam
Miles Elam wrote:
Not according to the code, they're not. Check out
AbstractProcessingPipeline.java. There are method bodies like:
public void setGenerator (String role, String source, Parameters
param, Parameters hintParam)
throws ProcessingException {
if (this.generator != nu
Miles Elam wrote:
In other words, the pipeline is full of side effects and dependant
upon things happening behind the curtain (to use a Wizard of Oz
reference). You'd be right in that it adds to the confusion. I agree
with Vadim. This is obfuscation in exchange for two lines of
verboseness.
Miles Elam wrote:
Ummm... Quick question: What are the use cases for this that are not
handled by existing methods? I mean, couldn't this be handled with an
(as-yet unwritten) action?
Go back to first post of this thread, where (last paragraph) I proposed
something sim
Ummm... Quick question: What are the use cases for this that are not
handled by existing methods? I mean, couldn't this be handled with an
(as-yet unwritten) action?
Jeff mentioned getting metainformation from binary data for searching,
but surely there are so many differ
Vadim Gritsenko wrote:
Here is another wild (or not?) thought.
Not so wild to me.
All this discussion comes down to the requirement of generating some
XML out of the content usually served by the reader, if that's
possible (and it is possible for some of the types of the content), in
order
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Here is another wild (or not?) thought.
All this discussion comes down to the requirement of generating some
XML out of the content usually served by the reader, if that's
po
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into
pipelines ? E.g :
If it's this way I'd prefer "unless-label" in map:read to make it
c
Jeff Turner wrote:
Isn't the problem there that a is a whole little pipeline unto itself? If it were broken into two atomic operations:
then we could have a using a content-aware pipeline, and everything would work.
I have the feeling that handling non-XML content in Cocoon is Just Wrong,
Hmm,
Frederic's question about search engine integration led me to
questioning myself at how Cocoon's Lucene integration could be able to
transparently index Word & PDF documents along with XML-produced
documents.
I have been wondering that too. At my company, we put together a simple
web mana
How about making it the other way round, by allowing Generators to read
from Readers?
Is that RT-ish enough?
-Bertrand
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Any other proposal or opinion on this subject before we start a vote ?
Can't you just enable generators in map:view in case when view
starts with reader?
No, since views "capture" the (XML) output
Sylvain Wallez wrote:
The functionality for all readers would obviously be the same: move
these bytes from here to there. But yes, the codified mapping I
think is important.
Please read carefully : I wrote *generators* !! This isn't about
moving bytes, but about producing an XML document.
Hi!
Sorry, but this discussion seems to tell us one thing:
The current sitemap syntax and cocoon processing model is not really
suitable for such kind of processing.
All this reminds me of a proposal (which was actually a RT) I've sent
back in January this year, where I proposed a more intuitiv
Nicola Ken Barozzi wrote:
Jeff Turner wrote, On 14/08/2003 14.17:
...
Isn't the problem there that a is a whole little pipeline
unto
itself? If it were broken into two atomic operations:
then we could have a using a
content-aware pipeline, and everything would work.
Well, why can't the
Bertrand Delacretaz wrote:
How about making it the other way round, by allowing Generators to
read from Readers?
Do you mean that the generator would be used if the
"xml-content-for-indexing" view is selected ? This doesn't fit with the
existing sitemap behaviour, since gene
Jeff Turner wrote, On 14/08/2003 14.17:
...
Isn't the problem there that a is a whole little pipeline unto
itself? If it were broken into two atomic operations:
then we could have a using a
content-aware pipeline, and everything would work.
Well, why can't the view simply start from a reader?
Upayavira wrote:
On 14 Aug 2003 at 15:34, Bertrand Delacretaz wrote:
I find this more understandable (but dunno about implementation):
Simplifying further:
Surely that'd do it?
this might be better, because what happens when someone comes along doing this:
Then the same request r
Sylvain Wallez wrote, On 14/08/2003 14.30:
Nicola Ken Barozzi wrote:
Jeff Turner wrote, On 14/08/2003 14.17:
...
Isn't the problem there that a is a whole little pipeline
unto
itself? If it were broken into two atomic operations:
then we could have a using a
content-aware pipeline, and ev
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Here is another wild (or not?) thought.
All this discussion comes down to the requirement of generating some
XML out of the content usually served by the reader, if that's
possible (and it is possibl
Sylvain Wallez wrote:
In other words,
must become valid for consistency. A reader becomes an exit point
and the rest of a pipeline is, by default, ignored. Is this an
intended consequence?
No consequence : this is how the sitemap works today, and the above is
valid,
No, that's
Miles Elam wrote:
Sylvain Wallez wrote:
Go back to first post of this thread, where (last paragraph) I
proposed something similar. The whole discussion is about how we
could have a syntax which doesn't introduce such verbosity in the
sitemap.
Verbosity is not necessarily a bad thing. If it
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into pipelines
? E.g :
If it's this way I'd prefer "unless-label" in map:read to make it clear.
Or maybe
would do, meaning "use this
Miles Elam wrote:
Sylvain Wallez wrote:
Go back to first post of this thread, where (last paragraph) I
proposed something similar. The whole discussion is about how we
could have a syntax which doesn't introduce such verbosity in the
sitemap.
Verbosity is not necessarily a bad thing. If it
On Thu, Aug 14, 2003 at 01:41:55PM +0200, Sylvain Wallez wrote:
> Jeff Turner wrote:
...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> Ah, ok, the "strongly type pipelines" are a different wording for
> "content-aware selectors" !
Ah yes. Strange
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into pipelines
? E.g :
If it's this way I'd prefer "unless-label" in map:read to make it clear.
Or maybe
woul
Miles Elam wrote:
Ummm... Quick question: What are the use cases for this that are not
handled by existing methods? I mean, couldn't this be handled with an
(as-yet unwritten) action?
Matcher *does* exist:
Vadim
Le Jeudi, 14 aoû 2003, à 15:24 Europe/Zurich, Sylvain Wallez a écrit :
...But what if we write it the other way around :
I find this more understandable (but dunno about implementation):
-Bertrand
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Any other proposal or opinion on this subject before we start a vote ?
Can't you just enable generators in map:view in case when view starts
with reader?
No, since views "capture" the (XML) output at certain points of th
Jeff Turner wrote:
On Wed, Aug 13, 2003 at 12:02:04PM +0200, Sylvain Wallez wrote:
Frederic's question about search engine integration led me to
questioning myself at how Cocoon's Lucene integration could be able to
transparently index Word & PDF documents along with XML-produced documents.
Sylvain Wallez wrote:
Go back to first post of this thread, where (last paragraph) I
proposed something similar. The whole discussion is about how we could
have a syntax which doesn't introduce such verbosity in the sitemap.
Verbosity is not necessarily a bad thing. If it were, would any of
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:24 Europe/Zurich, Sylvain Wallez a écrit :
...But what if we write it the other way around :
I find this more understandable (but dunno about implementation):
Interesting. This is looks like a more compact notation for the
view-s
On 14 Aug 2003 at 15:34, Bertrand Delacretaz wrote:
> I find this more understandable (but dunno about implementation):
>
>
>
>
>
Surely that'd do it?
Regards, Upayavira
42 matches
Mail list logo
