> > > Instead of extensions you could use custom URIResolvers to return the
> > result
> > > from anywhere (or just do something and return succes/fail) to an
> > representation
> > > usable by a transformation.
> >
> > That would work, but where I'm heading I essentially want the equivalent
of
>
Hi,
> -Original Message-
> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 9:34 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: XML input module (was: RE: Nice changes!)
>
>
> > > Maybe, maybe not. One would
> > Maybe, maybe not. One would need to use a lot extension functions to
> > achieve similar things (e.g. j2ee, databases and stuff) but that might
> > be portable to other pipeline systems (?). OTOH Apache Cocoon a lot
> > about SoC and it will need to be seen if that works as well with your
> >
> > This is likely an issue you're going to run into also; mapping XPath to
> > random session objects might be possible, but I suspect the two domains
> > aren't perfectly isomorphic :-(
>
> Yes, but since we don't need to work on strings, less so. All these
> modules work on Objects and only on
Hi,
> -Original Message-
> From: Christian Haul [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 12:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XML input module (was: RE: Nice changes!)
>
>
> On 02.Oct.2002 -- 09:47 AM, Hunsberger, Peter wrote:
>
On 02.Oct.2002 -- 09:47 AM, Hunsberger, Peter wrote:
> This is likely an issue you're going to run into also; mapping XPath to
> random session objects might be possible, but I suspect the two domains
> aren't perfectly isomorphic :-(
Yes, but since we don't need to work on strings, less so. All
>> This gets me to a pet issue of mine: If I ever get the time I'd really
like
>> to build a version of the site map pipeline handler based XSLT that has
all
>> context information available to it as XML; the request variables,
session
>> data, etc. The XSLT could either act as a filter to some
On 02.Oct.2002 -- 09:55 AM, Jens Lorenz wrote:
> Christian Haul wrote:
>
Jens,
> >Yes, but not just the pipeline but anywhere. Actions use it, so do
> >Matchers and Selectors. It would not be much of a problem to make it
> >accessible from XSP as well. It's just not done, yet.
>
> SCNR, follow
Christian Haul wrote:
Hi Christian,
> Yes, but not just the pipeline but anywhere. Actions use it, so do
> Matchers and Selectors. It would not be much of a problem to make it
> accessible from XSP as well. It's just not done, yet.
SCNR, following the discussion here we just thought about the g
On 01.Oct.2002 -- 04:09 PM, Hunsberger, Peter wrote:
> > Think of the various matchers and selectors in cocoon. What if you
> > could just plug-in the data source? There wouldn't be sources * match
> > type matchers.
>
> This gets me to a pet issue of mine: If I ever get the time I'd really like
> Say, you want to insert data to a database. Some data stems from request
> parameters, some from the session and some from request attributes set
> by another action. In order to make this possible, the database action
> needs to be flexible enough to do this. It used to read from request
> par
On 01.Oct.2002 -- 01:20 PM, Hunsberger, Peter wrote:
> >> I've been following this discussion for the last week or so and suddenly
> >> this morning I had to start questioning exactly what the true purpose of
> all
> >> this is? The idea of being able to dig out a value based on a precedence
> >>
>> I've been following this discussion for the last week or so and suddenly
>> this morning I had to start questioning exactly what the true purpose of
all
>> this is? The idea of being able to dig out a value based on a precedence
>> hierarchy makes sense, but XML and XSLT already have very good
On 02.Oct.2002 -- 01:32 AM, Jeff Turner wrote:
> On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:
> > The degree, to what they digest the data is not set to
> > stone. SessionModule could, for instance, just return the session
> > object.
>
> Yes, it would have to, to accommodate
On 01.Oct.2002 -- 09:46 AM, Hunsberger, Peter wrote:
> I've been following this discussion for the last week or so and suddenly
> this morning I had to start questioning exactly what the true purpose of all
> this is? The idea of being able to dig out a value based on a precedence
> hierarchy mak
On Tue, Oct 01, 2002 at 10:17:40AM +0200, Christian Haul wrote:
> On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
...
> > It is universally pluggable, only the plugin mechanism is inheritance,
> > not composition. The current model is:
> >
> > AbstractJXPathModule .
> > |
f
you have specific reasons why doing this via XML/XSLT is problematic I'd be
interested in hearing them.
-Original Message-
From: Christian Haul [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 3:18 AM
To: [EMAIL PROTECTED]
Subject: Re: XML input module (was: RE: Nice cha
On 01.Oct.2002 -- 01:31 AM, Jeff Turner wrote:
> On Mon, Sep 30, 2002 at 04:56:36PM +0200, Christian Haul wrote:
> > On 30.Sep.2002 -- 09:59 PM, Jeff Turner wrote:
> > > On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> > > > I would prefer that module to be a "meta" module that ca
On Mon, Sep 30, 2002 at 04:56:36PM +0200, Christian Haul wrote:
> On 30.Sep.2002 -- 09:59 PM, Jeff Turner wrote:
> > On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> > > I would prefer that module to be a "meta" module that can be
> > > configured to take input from any source (i.
On 30.Sep.2002 -- 03:38 PM, Piroumian Konstantin wrote:
> > From: Christian Haul [mailto:[EMAIL PROTECTED]]
> > I would prefer that module to be a "meta" module that can be
> > configured to take input from any source (i.e. another
> > InputModule) rather than do the reading itself.
> >
> > Th
On 30.Sep.2002 -- 09:59 PM, Jeff Turner wrote:
> On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> > I would prefer that module to be a "meta" module that can be
> > configured to take input from any source (i.e. another InputModule)
> > rather than do the reading itself.
>
> >Fro
> From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
>
> That would be nifty.
>
> > or document stored as session attribute.
>
> This might already be possible, since I think JXPath can
> traverse from the Session object to a DOM.
On Mon, Sep 30, 2002 at 01:19:04PM +0200, Christian Haul wrote:
> On 30.Sep.2002 -- 02:06 PM, Piroumian Konstantin wrote:
> > > From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> > > On Sun, Sep 29, 2002 at 09:37:39PM +0400, Konstantin Piroumian wrote:
> > > > From: "Jeff Turner" <[EMAIL PROTECTED]>
> From: Christian Haul [mailto:[EMAIL PROTECTED]]
> On 30.Sep.2002 -- 02:06 PM, Piroumian Konstantin wrote:
> > > From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> > > On Sun, Sep 29, 2002 at 09:37:39PM +0400, Konstantin
> Piroumian wrote:
> > > > From: "Jeff Turner" <[EMAIL PROTECTED]>
> >
> > (c
On 30.Sep.2002 -- 02:06 PM, Piroumian Konstantin wrote:
> > From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> > On Sun, Sep 29, 2002 at 09:37:39PM +0400, Konstantin Piroumian wrote:
> > > From: "Jeff Turner" <[EMAIL PROTECTED]>
>
> (cross-posting to cocoon-dev, cause it concerns more Cocoon than Fo
25 matches
Mail list logo
