Jeff Turner wrote:
> > That's an issue I've come up against too - it seems that views are
> > still too "tangled" up with labels and can't cut across pipelines
> > properly. At least, that's how I understand it - maybe I'm missing
> > something?
>
> I think labels and Views are independent of each
Jeff Turner wrote:
> Also, it resolves another little dilemma I've had with link
> views. It's
> all very well having the notion of a cross-cutting 'view',
> but there's no
> way to override the 'view' for a specific pipeline. With an explicit
> gather-links transformer, one could have differe
Joerg Heinicke wrote:
> Ok, reason accepted :) But what about an extra validating
> transformer as
> last pipeline step? Seems to make more sense IMO.
YES! This could be VERY useful: a transfomer that could validate the output
of some pipeline stage against a DTD or other schema could be a great
> Torsten Knodt wrote:
> > Hello,
> > I'm currently working on my patchset of the week ;). One
> part is a modularized
> > DirectoryGenerator. The only what is currently not included is the
> > XPathDirectoryGenerator. As it can simply be simulated by
> XInclude, why
> > having the code double
Torsten Knodt wrote:
> Hello,
> I'm currently working on my patchset of the week ;). One part
> is a modularized
> DirectoryGenerator. The only what is currently not included is the
> XPathDirectoryGenerator. As it can simply be simulated by
> XInclude, why
> having the code doubled? Or have I und
Jeremy, you could try just generating the entire linkmap, then use a
transformer to select just the part that interests you (i.e. 2 steps instead
of combined into 1 step).
> -Original Message-
> From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
> Sent: Sunday, 30 March 2003 05:33
> To: [EMAIL P
some other way then you
also need another pipeline to convert it into a call using
"?cocoon-view=view-name"
Can anyone confirm or deny this?
Cheers
Con
>
> -Original Message-
> From: Conal Tuohy [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 04, 2003 2:22 PM
>
I had no luck with this message on Cocoon Users ... I'm wondering if anyone
here can answer this question about other ways to call a view?
Thanks!
-Original Message-
From: Conal Tuohy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 4 March 2003 20:01
To: Cocoon Users (E-mail)
Subject: h
> The occam razor is most commonly translared as: "between more
> choices,
> the simplest is normally right one". Goes along with
> Einstein's thoughts
> about 'between two theories, the most elegant is probably the
> right one'.
I read another Einstein version of Ockham's razor: (from memory) "th
Hi Peter
Peter wrote:
> >> Hmm, I guess I've been exploring this long enough that I
> thought it
> >> was somewhat intuitively obvious, sorry... (Someone has
> also remarked
> > that this sounded somewhat like a capability that was in C1.)
> >
Stefano(?) wrote:
> > yeah, you could implement what
> -Original Message-
> From: Litrik De Roy [mailto:cocoon-dev@;litrik.com]
> Sent: Wednesday, 30 October 2002 09:20
> To: [EMAIL PROTECTED]
> Subject: Re: Another XSP?
>
>
> I just don't get it. Don't these guys do any kind of research
> before naming
> their product?
That's not the only r
> -Original Message-
> From: Andrew C. Oliver [mailto:andy@;superlinksoftware.com]
> The correct form of YOU (pl) is Y'all. This is a contraction
> of You and
> ALL. If you want to be less casual you can say "You all".
Here in New Zealand we have "yous" (or "yous guys"). I think this fo
I think we all hate table-based layouts and would prefer to use CSS. It
would be much easier to design and specify the look and feel using CSS. It's
more concise ... there are a thousand reasons.
But Nicola's point is valid: if browsers are going to CRASH (even a few
browsers) then that's one BIG
> > But Nicola's point is valid: if browsers are going to CRASH
> (even a few
> > browsers) then that's one BIG reason against it :-(
Robert Koberg:
> even if it is about .1% of the general Internet users? There
> might be an
> argument if stats could be provided for the user base, but
> that doe
> -Original Message-
> From: Geoff Howard [mailto:[EMAIL PROTECTED]]
> How would this name overloading work with respect to:
> - references from resources back to their calling
> pipeline
> - from a subsitemap back to the mounting reference
>
> Seems these cases may make overloading desir
Stefano wrote:
>
>
>
>
>
>
>
>
>
>
> where the only problem is the nesting of two components of
> the same type
> (but I don't really see a need for this and I would think
> it's a design
> mistake of the component if you need to do it!)
Yes it probably
> Ola Berg wrote:
> > Personally, I like either \"flow\" and \"use-flow\" or
> \"director\" and \"direct\". On second thougt \"flow\" and
> \"use-flow\" is what I like best. (Part of the problem is
> that \"flow\" can be used both as a noun (the component) and
> as a verb (the action). \"use-flow
Torsten wrote:
> Guys, isn't it obvious we cannot realy provide errors in a
> user friendly
> manner since we are delivering the page on-the-fly via SAX?
> Buffering the
> whole page seems to reduce the positve aspects we get from
> using SAX and we
> get closer to Cocoon1.
>
> Maybe we should ha
> Question: when using the aggregator, is it possible to
> specify an attribute as
> well as the name of the parent element, eg if I have:
>
>
>
>
>
>
>
>
>
>
>
>
> it will give me something like
>
>
>
>
>
>
> whereas I would like
>
>
>
>
>
>
>
> Is this possible? I'm usi
I'm working on a set of email components for Cocoon (mostly finished), and
there's one part I'd appreciate comments or advice on.
A MIME message can contain a number of parts of different types (including
binary attachments), and these have to be extracted from the message.
Currently I've written
Hi Giacomo
> Well, the intent of Stefanos RT about blocks was that even
> such "modules"
> would be implemented as Blocks because the provide specialized
> functionallity
Oh good ... that's what I thought :-)
But the main point I wanted to discuss (when I forked this thread) was only
a MINOR, n
I realise that "blocks" are still vapour-ware, whereas "optional modules"
are at least imminent vapour-ware ;-) but I'm still not entirely clear on
how the relationship between these "optional build modules" and the planned
"blocks" is supposed to develop. Can someone comment on how they see these
There's been a lot of discussion about "Cocoon Blocks" and "Extending the
build system for modules" recently. It seems to me that (whatever they're
called) they are essentially the same thing (or should be). At least,
ideally these optional build modules should include the necessary metadata
(WSDL
My comments on terminology:
> > > portion
implies a part taken from a whole, a "share", not a unit of *construction*
> > > element
good, but XML also has elements
> > > ingredient
my favourite! Is it just because I like food? ;-)
> > > unit
a unit is just a single thing ... too vag
> > org.apache.cocoon.mail ? (this is what I'm using at present)
> > org.apache.cocoon.components.mail ?
> > org.apache.cocoon.components.source.impl.mail ?
Carsten wrote:
> If your implementing consists only of a source then I think the third
> package name is the best to use. I would discourag
I've written some components for dealing with javamail stores: MailSource
and MailSourceFactory, and a few associated (helper) classes which will
probably also include an XMLizer when I factor out the XMLizing code. I'd
like to commit them to the scratchpad, but first I want to know the correct
lo
> > session), but in any case, it seems to me that a Source can keep a
> > cache of open Connections itself if necessary - it doesn't
> really have
> > to be stored in the Session.
>
> You can do this (connection pooling) in MailSourceFactory, or, if such
> connection pool can be reused somewhere
Justin wrote:
>I think that putting all the functionality of logging into
> a server,
> retreiving messages and folders, and turning that data into XML is a
> little too much for a Source. If you have to pass parameters to the
> generator to specify servers and passwords, etc.. then why
> not
> > > Context is one per application, Configuration and Parameters
> > > are one per
> > > Source type (in your case - one configuration per all instances of
> > > MailSource).
> > Just to get this clear though - if my Source was a
> Generator instead,
> could
> > I pass parameters to it on a per
> > It seems to me that the Source can implement Configurable,
> Contextualizable,
> > or Parameterizable, and then extract the credentials from its
> Configuration,
> > Context, or Parameter. Is that right? Any suggestions? Can anyone
> point me
> > at some code which implements something similar
I am writing a Source or Sources to provide access to mail stored on pop3,
imap, etc servers. In some cases the Source will need to log in to the mail
server, so I need a way to pass the credentials to my Source.
It seems to me that the Source can implement Configurable, Contextualizable,
or Para
Whoops!
> Currently I have a MIMEMessageGenerator which parses "message/rfc822"
> content from a Source by getting its InputStream. Should I
> just write a
> JavaMailSource which is also XMLizable? Then I can use my existing
> MIMEMessageGenerator without changes?
I meant to say "...JavaMailSou
I'm writing an email generator component, and I've been struggling to
understand the object interaction involved with Generator, Source,
XMLizable, XMLizer, etc.
At present the documentation of this part of the object model is really
terrible ... quite a bit of the model is deprecated, there's n
> -Original Message-
> From: Steven Noels [mailto:[EMAIL PROTECTED]]
> In terms of implementation, this could be a pipeline configuration
> component, a Matcher of Selector. It would require to 'parse' the XML
> document upto a level it can detect its grammar (for DTDs the doctype
> state
Hi Justin
About 6 months ago I started on a related idea: a web mail archive. I didn't
get very far, and had to stop work on it while I did some paid work ;-) but
I've just downloaded C2 sources and started again.
My main idea was to implement webmail in Cocoon on top of a mail-server,
such as J
> -Original Message-
> From: Morrison, John [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 25 July 2002 19:18
> Subject: RE: problem with xerces jar in HEAD
>
>
> What version of tomcat? What JVM?
JVM 1.3.1_03
Tomcat 4.0.4-b2
> > From: Conal Tuo
Looks to me like there's some version incompatiblity problem.
Last night I got the source (HEAD) from CVS. Today I built the webapp, and
installed it under Tomcat, but cocoon wouldn't run: I eventually found the
classloader error in the Tomcat logs (see below for the error).
I checked the xmlapi
I haven't yet used the flowmap stuff myself, so I have a possibly naive
question: what would be the flowmap (flowscript?) syntax to return a
continuation to the client as an http cookie? Is this relatively easy
compared to url-rewriting?
--
Carsten wrote:
> Ok, first question: for what version are you planning to add
> the caching?
> If for 2.0.2/2.0.3 than the Cacheable interface is the right
> one, if you
> are planning it for 2.1 than CacheableProcesingComponent is
> the correct
> one.
Hmmm ... I haven't looked at 2.1 ... I t
I've just been looking at "inclusion" recently and noticed that the cinclude
transformer had caching but the xinclude transformer didn't, and I wondered
if there was some arcane reason or was it just a historial accident ;-) And
BTW I think Carsten is right - the inclusion code should be united.
s Open eBook
>
>
>
> So do you have preferences between Open eBook and simplified DocBook?
>
>
> - Original Message -
> From: "Conal Tuohy" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 03, 2002 1:01 AM
> Subject: RE
> -Original Message-
> From: Bernhard Huber [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 3 June 2002 04:18
> To: [EMAIL PROTECTED]
> Subject: Re: DocBook vs Open eBook
>
>
> Hi
> I think the reason for using Apache DTD is more historic, as at the
> beginning
> the DocBook was not that much m
> >Put the image url in a commented link tag, and I think it
> will be picked up.
> >
>
> Just tested it, they are not picked up. Without the comment
> tags it works.
> Bert
Try .
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Yes you can insert a processing instruction in your XML and set up Cocoon 2
to respect it.
In short, you create a "bootstrap" stylesheet which finds the stylesheet you
want, and you call it using the "cocoon:" protocol.
See http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102003720732535&w=2
It'
> From: Diana Shannon [mailto:[EMAIL PROTECTED]]
> On May 5, 2002, David Crossley wrote:
>
> > Another issue to add to the list is standard spelling.
> > Considering that we are talking English, i would prefer
> > to see British English spelling rather than a dialect,
> > such as Americanization.
altogether!! ;-)
Cheers
Conal
> -Original Message-
> From: Andrew John Savory [mailto:[EMAIL PROTECTED]]On Behalf
> Of Andrew
> Savory
> Sent: Monday, 22 April 2002 20:11
> To: Conal Tuohy
> Cc: [EMAIL PROTECTED]
> Subject: RE: SVG BUG?: The attribute 'xlink:href&
Andrew John Savory wrote:
> On Sun, 21 Apr 2002, Conal Tuohy wrote:
>
> > http://www.w3.org/1999/xlink";
> xlink:href="Ba01S000.jpg"
>
> Try using an absolute URL for the href. I've had problems
> with relative
> hrefs.
Cheers, Andrew. I'
Generator.java:142)
at
org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEv
entPipeline.java:251)
at
org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingS
treamPipeline.java:399)
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 19 April 2002 08:33
> To:
Are you sure, Bert? I can see how a search engine would be suspicious of a
META REFRESH tag because the search engine would be ranking the page which
contained the META tag (and a whole lot of key words), but the user will be
sent to some different page. So I certainly wouldn't recommend using a h
Don't use a 404 to signal that a URL has changed: use a 301 "Moved
Permanently".
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2
> -Original Message-
> From: Bert Van Kets [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, 14 April 2002 08:57
> To: [EMAIL PROTECTED]
> Subject: Re
, I notice that in XSLT 1.1 the W3C intended to make this feature
standard, but XSLT 1.1 was abandoned, and the feature has been removed from
the XSLT 2 Requirements document http://www.w3.org/TR/xslt20req
---
Conal Tuohy
[EMAIL PROTECTED]
-
51 matches
Mail list logo
