Sorry for dissapearing after having started this discussion.
Guido Casper wrote:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 15:49]:
Why Cocoon rocks for publishing
---
Cocoon is based on three great ideas: XML-adaptors, XML-pipelines and
the sitemap. Here we will discuss the first two.
If you have N different input formats
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 21:53]:
snip/
XML centric view on input
-
The most important part is not a code change but rather a design
principle: Input handling is controlled from flowscripts, the flowscript
typically adapt various input
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 22:06]:
Alan [EMAIL PROTECTED] writes:
snip/
There is already flow logic in the site map. The pipeline is a
select statement. It is a clear expression of the pipelines
intent.
Ok, that's where we differ. Our
Alan [EMAIL PROTECTED] writes:
snip/
I am using the matching facilities agressively. It is how I see a
web application. A GET are function calls, the URI's are the
function signatures, the pipelines are the function
bodies. Its
stateless functional programming to me.
Bertrand Delacretaz wrote:
Le Mercredi, 25 fév 2004, à 16:49 Europe/Zurich, Daniel Fagerstrom a
écrit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure i.e. DOM. This leads to flowscript components
that reads some
remove the map:call, or maybe use a select between the input and the
output part of the pipeline.
/Daniel
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [RT] Cocoon Input Model
Le
Le Lundi, 1 mars 2004, à 15:48 Europe/Zurich, Daniel Fagerstrom a écrit
:
...I meant something a little bit more explicit:
map:generate type=request/
map:transform src=prepare-query-for-user-preferences/
map:transform type=sql/
map:store type=xml dest=xmodule:request-attr:foo/
map:call
Steven Noels wrote:
On 25 Feb 2004, at 22:53, Daniel Fagerstrom wrote:
CForms should use typed DOM as form model
---
I also believe that making CForms use typed XML as data storage is
important. This obviously require some changes, among other things the
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-03-01 14:54]:
Bertrand Delacretaz wrote:
Le Mercredi, 25 f?v 2004, ? 16:49 Europe/Zurich, Daniel Fagerstrom a
?crit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure
* Ralph Goers [EMAIL PROTECTED] [2004-02-25 18:18]:
Just trying to understand from a practical point of view, does this
mean something like
map:generate type=request/
map:transform src=prepare-query-for-user-preferences/
map:transform type=sql/
map:call function=myFlow() dom-input=domIn/
Steve Krulewitz [EMAIL PROTECTED] writes:
I agree that more sophisticated input handing would make general web
applications much easier to write in Cocoon... here are some
more random
thoughts on the subject:
Input can come from many sources:
- http query string
- http post stream
as
long as the proper XML document is returned to the action at the end of the
pipeline.
Ralph
-Original Message-
From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]
Sent: Monday, March 01, 2004 8:17 AM
To: [EMAIL PROTECTED]
Subject:RE: [RT] Cocoon Input Model
So, bottom
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:17]:
Steve Krulewitz [EMAIL PROTECTED] writes:
1) in the flowscript the varible output has the complete contents of
this pipeline in it, it can be folded back into any handling you want
via flowscript variable passing (eg, as an XSLT
Hunsberger, Peter wrote:
So, bottom line, I don't think Cocoon needs any new sitemap constructs
to do what is being discussed, unless what is needed is a way to do this
without flow? However, trying to do this without flow seems to me to
mean going back to regular actions, so I can't see any
Alan wrote:
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:17]:
Steve Krulewitz [EMAIL PROTECTED] writes:
1) in the flowscript the varible output has the complete contents of
this pipeline in it, it can be folded back into any handling you want
via flowscript variable passing (eg, as an
On Mon, 2004-03-01 at 16:09, Daniel Fagerstrom wrote:
Steven Noels wrote:
On 25 Feb 2004, at 22:53, Daniel Fagerstrom wrote:
CForms should use typed DOM as form model
---
I also believe that making CForms use typed XML as data storage is
* Stefano Mazzocchi [EMAIL PROTECTED] [2004-03-01 18:32]:
Alan wrote:
* Hunsberger, Peter [EMAIL PROTECTED] [2004-03-01 16:17]:
So, bottom line, I don't think Cocoon needs any new sitemap constructs
to do what is being discussed, unless what is needed is a way to do this
without flow?
Alan [EMAIL PROTECTED] writes:
snip/
Look, nobody prevents you from doing this already today:
StreamGenerator - ValidateTransformer - StoreTransformer -
but then what happens if the validation is not complete? how to you
manage that? what is the logic?
As I said, the logic of a
Steve Krulewitz wrote:
I agree that more sophisticated input handing would make general web
applications much easier to write in Cocoon... here are some more random
thoughts on the subject:
Input can come from many sources:
- http query string
- http post stream
- http cookie
- user session
I agree that more sophisticated input handing would make general web
applications much easier to write in Cocoon... here are some more random
thoughts on the subject:
Input can come from many sources:
- http query string
- http post stream
- http cookie
- user session object (from disk?
Alan wrote:
* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too
* Guido Casper [EMAIL PROTECTED] [2004-02-27 08:02]:
Alan wrote:
* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry
Alan wrote:
What do you mean by strongly typed? Are we discussiong form posts
here?
Yes, form posts being the use case at hand, but there are other ways
input may be provided. Quoting Daniel:
Besides using request parameters and structured request parameters as
user input. XML is used for
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 15:49]:
Why Cocoon rocks for publishing
---
Cocoon is based on three great ideas: XML-adaptors, XML-pipelines and
the sitemap. Here we will discuss the first two.
If you have N different input formats and M
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 21:53]:
Stefano Mazzocchi wrote:
After a long silence, Daniel fights back :-)
:)
On Feb 25, 2004, at 10:49, Daniel Fagerstrom wrote:
[snip very good summary]
To sumarize: I think that we could make Cocoon considerably easier to
* Bertrand Delacretaz [EMAIL PROTECTED] [2004-02-25 16:46]:
Le Mercredi, 25 f?v 2004, ? 16:49 Europe/Zurich, Daniel Fagerstrom a
?crit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure i.e. DOM. This leads to
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too different from
those of outbound data flow.
For outbound data flow
* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too
Alan wrote:
* Guido Casper [EMAIL PROTECTED] [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow
could
then be used to populate a Java object or just be passed on to other
actions, etc.
Ralph
-Original Message-
From: Guido Casper [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 26, 2004 12:47 PM
To: [EMAIL PROTECTED]
Subject:Re: [RT] Cocoon Input Model
Daniel
After a long silence, Daniel fights back :-)
On Feb 25, 2004, at 10:49, Daniel Fagerstrom wrote:
[snip very good summary]
To sumarize: I think that we could make Cocoon considerably easier to
use for (web)apps and increase reuse of components by using the
XML-adaptor and pipes and filter
Daniel,
I have to say your post was well written and well thought out. I hadn't
considered the idea of using XML on the input side but it does have certain
advantages. For one, I could define an XML schema to do some, or all, of
the input validation.
In our application we take the input,
Le Mercredi, 25 fév 2004, à 16:49 Europe/Zurich, Daniel Fagerstrom a
écrit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need a data structure i.e. DOM. This leads to flowscript components
that reads some input format to DOM and from
: Wednesday, February 25, 2004 8:46 AM
To: [EMAIL PROTECTED]
Subject:Re: [RT] Cocoon Input Model
Le Mercredi, 25 fév 2004, à 16:49 Europe/Zurich, Daniel Fagerstrom a
écrit :
snip-plenty-of-good-stuff/
...But in many cases using SAX based XML as in pipelines is not enough
we need
Stefano Mazzocchi wrote:
After a long silence, Daniel fights back :-)
:)
On Feb 25, 2004, at 10:49, Daniel Fagerstrom wrote:
[snip very good summary]
To sumarize: I think that we could make Cocoon considerably easier to
use for (web)apps and increase reuse of components by using the
On 25 Feb 2004, at 22:53, Daniel Fagerstrom wrote:
CForms should use typed DOM as form model
---
I also believe that making CForms use typed XML as data storage is
important. This obviously require some changes, among other things the
widget objects need
37 matches
Mail list logo
