Orbeon Forms community mailing list

Implementing utility pipelines as custom processors, with a migration path to java implementation

Classic

List

Threaded

7 messages Options

Stephen Bayliss

Implementing utility pipelines as custom processors, with a migration path to java implementation

Scenario
--------
Our application has a number of utility pipelines, common
non-application-specific functions for which there is no functionality
within OPS at present (one example being base64 encoding).

They form good candidates for implementation as custom processors in
java.

Problem
-------
There's a maintenance overhead if a custom processor is written to
replace the utility pipeline:

Every instance of <p:processor name="oxf:pipeline" ...../> to "call" the
utility pipeline will need replacing with <p:processor
name="example:our-custom-processor" ...... />

Solution
--------
Here is a way you can declare an xpl pipeline as a custom processor, so
you can then reference it in your other pipelines as such, and if you
come to replace your xpl implementation with a java implementation, you
won't have to amend any of your pipelines that use it.

In this example, the utility pipeline is
/utilities/example-pipeline.xpl; and it is declared below as a processor
named example:example-processor

1) Create/update your /config/custom-processors.xml to include the
following:

<processor name="example:example-processor"
xmlns:example="http://your.processor.namespace/here">
<instantiation name="oxf:pipeline">
<input name="config"
href="oxf:/utilities/example-pipeline.xpl"/>
</instantiation>
</processor>

2) In your other xpl pipelines:

Instead of using this syntax:

<p:processor name="oxf:pipeline">
<p:input name="config" href="/utilities/example-pipeline.xpl"/>
<p:input name="my-pipeline-input" href="#something"/>
<p:output name="data" id="something-else/>
</p:processor>

You can use this (you will need
xmlns:example="http://your.processor.namespace/here" either in the
p:processor tag, or in the pipeline's p:config tag):

<p:processor name="example:example-processor>
<p:input name="my-pipeline-input" href="#something"/>
<p:output name="data" id="something-else/>
</p:processor>

So now it doesn't matter if you implement the functionality of
example:example-processor as an xpl pipeline, or as a java custom
processor!

Disadvantages with this approach
--------------------------------
- oxf:pipeline uses its config input to provide the xpl pipeline to
call. This means that the utility xpl pipeline cannot have a config
input (and if you want to avoid code changes later, your java
implementation will not have a config input), which is not great
(currently we use a naming convention of xconfig as the input to utility
pipelines to deal with this, but this is not ideal)
- maybe OPS's caching mechanism won't cope very well with this approach?

One suggestion I have is to change the code for the current oxf:pipeline
processor:
- have a new optional input called "pipeline"
- if this input is present, then use this in place of the current
"config" input
- if this input is not present, then use the config input as before

Thus existing behaviour is preserved, but usage of the config input in
called pipelines is also allowed.

The processor declaration in custom-processors.xml would use an input
named "pipeline" to reference the xpl pipeline to be called, and you are
then free to use the config input as per other processors.

What do people think of this approach?

Steve

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Erik Bruchez

Re: Implementing utility pipelines as custom processors, with a migration path to java implementation

Administrator

Stephen Bayliss wrote:

> Disadvantages with this approach
> --------------------------------
> - oxf:pipeline uses its config input to provide the xpl pipeline to
> call. This means that the utility xpl pipeline cannot have a config
> input (and if you want to avoid code changes later, your java
> implementation will not have a config input), which is not great
> (currently we use a naming convention of xconfig as the input to utility
> pipelines to deal with this, but this is not ideal)

Granted, that's a drawback.

> - maybe OPS's caching mechanism won't cope very well with this approach?

No, it should cope just fine.

> One suggestion I have is to change the code for the current oxf:pipeline
> processor:
> - have a new optional input called "pipeline"
> - if this input is present, then use this in place of the current
> "config" input
> - if this input is not present, then use the config input as before
>
> Thus existing behaviour is preserved, but usage of the config input in
> called pipelines is also allowed.
>
> The processor declaration in custom-processors.xml would use an input
> named "pipeline" to reference the xpl pipeline to be called, and you are
> then free to use the config input as per other processors.
>
> What do people think of this approach?

In the early days, we kind of decided to standardize on a "config"
name for certain inputs. Now it hasn't proven a perfect idea. Changing
to "pipeline" and implementing the above behavior would be probably
ok, but somebody would have to work on it ;-)

-Erik

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Stephen Bayliss

RE: Implementing utility pipelines as custom processors, with a migration path to java implementation

In reply to this post by Stephen Bayliss

Eric

I had a go at this, ie customising the existing pipeline processor so
that it would accept either a "config" input or a "pipeline" input; and
if it gets a "pipeline" input it uses that instead of the the "config"
input.

Got it working fine....

But...

The only way to get it working was to not have
addInputInfo(new ProcessorInputOutputInfo(INPUT_CONFIG,
PIPELINE_NAMESPACE_URI));
in the constructor (as at this point it's not known if a "config" input
or a "pipeline" input will be created).

However, this means that the XPL input is not validated, which is
obviously a Bad Thing.

And I can't work out any way of plugging validation into the correct
input at a later point, ie after it has been created and added (this
could be done in the start method).

Any ideas?

My fallback is to create a pipeline processor proxy, ie a new pipeline
processor that expects its XPL input on a "pipeline" input.

Steve

-----Original Message-----
From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez
Sent: 25 January 2006 23:16
To: [hidden email]
Subject: Re: [ops-users] Implementing utility pipelines as custom
processors, with a migration path to java implementation

Stephen Bayliss wrote:

> Disadvantages with this approach
> --------------------------------
> - oxf:pipeline uses its config input to provide the xpl pipeline to
> call. This means that the utility xpl pipeline cannot have a config
> input (and if you want to avoid code changes later, your java
> implementation will not have a config input), which is not great
> (currently we use a naming convention of xconfig as the input to
utility
> pipelines to deal with this, but this is not ideal)

Granted, that's a drawback.

> - maybe OPS's caching mechanism won't cope very well with this
approach?

No, it should cope just fine.

> One suggestion I have is to change the code for the current
oxf:pipeline
> processor:
> - have a new optional input called "pipeline"
> - if this input is present, then use this in place of the current
> "config" input
> - if this input is not present, then use the config input as before
>
> Thus existing behaviour is preserved, but usage of the config input
in
> called pipelines is also allowed.
>
> The processor declaration in custom-processors.xml would use an input
> named "pipeline" to reference the xpl pipeline to be called, and you
are
> then free to use the config input as per other processors.
>
> What do people think of this approach?

In the early days, we kind of decided to standardize on a "config"
name for certain inputs. Now it hasn't proven a perfect idea. Changing
to "pipeline" and implementing the above behavior would be probably
ok, but somebody would have to work on it ;-)

-Erik

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Alessandro Vernet

Re: Implementing utility pipelines as custom processors, with a migration path to java implementation

Administrator

Stephen,

I guess doing your own processor that uses the code of the Pipeline
processor is the way to go. You can then even call your own processor
"oxf:pipeline" and override the built-in Pipeline processor, if you
don't think that might be confusing.

Alex

On 1/27/06, Stephen Bayliss <[hidden email]> wrote:

> Eric
>
> I had a go at this, ie customising the existing pipeline processor so
> that it would accept either a "config" input or a "pipeline" input; and
> if it gets a "pipeline" input it uses that instead of the the "config"
> input.
>
> Got it working fine....
>
> But...
>
> The only way to get it working was to not have
> addInputInfo(new ProcessorInputOutputInfo(INPUT_CONFIG,
> PIPELINE_NAMESPACE_URI));
> in the constructor (as at this point it's not known if a "config" input
> or a "pipeline" input will be created).
>
> However, this means that the XPL input is not validated, which is
> obviously a Bad Thing.
>
> And I can't work out any way of plugging validation into the correct
> input at a later point, ie after it has been created and added (this
> could be done in the start method).
>
> Any ideas?
>
> My fallback is to create a pipeline processor proxy, ie a new pipeline
> processor that expects its XPL input on a "pipeline" input.
>
> Steve
>
>
>
> -----Original Message-----
> From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez
> Sent: 25 January 2006 23:16
> To: [hidden email]
> Subject: Re: [ops-users] Implementing utility pipelines as custom
> processors, with a migration path to java implementation
>
> Stephen Bayliss wrote:
>
> > Disadvantages with this approach
> > --------------------------------
> > - oxf:pipeline uses its config input to provide the xpl pipeline to
> > call. This means that the utility xpl pipeline cannot have a config
> > input (and if you want to avoid code changes later, your java
> > implementation will not have a config input), which is not great
> > (currently we use a naming convention of xconfig as the input to
> utility
> > pipelines to deal with this, but this is not ideal)
>
> Granted, that's a drawback.
>
> > - maybe OPS's caching mechanism won't cope very well with this
> approach?
>
> No, it should cope just fine.
>
> > One suggestion I have is to change the code for the current
> oxf:pipeline
> > processor:
> > - have a new optional input called "pipeline"
> > - if this input is present, then use this in place of the current
> > "config" input
> > - if this input is not present, then use the config input as before
> >
> > Thus existing behaviour is preserved, but usage of the config input
> in
> > called pipelines is also allowed.
> >
> > The processor declaration in custom-processors.xml would use an input
> > named "pipeline" to reference the xpl pipeline to be called, and you
> are
> > then free to use the config input as per other processors.
> >
> > What do people think of this approach?
>
> In the early days, we kind of decided to standardize on a "config"
> name for certain inputs. Now it hasn't proven a perfect idea. Changing
> to "pipeline" and implementing the above behavior would be probably
> ok, but somebody would have to work on it ;-)
>
> -Erik
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

Stephen Bayliss

RE: Implementing utility pipelines as custom processors, with a migration path to java implementation

In reply to this post by Stephen Bayliss

Alex

I did try this approach, with some success.

The easiest way (in terms of coding) is to inherit off the existing
pipeline processor and override the values for the name of the config
input. That way any code changes, bug fixes etc in the main pipeline
processor don't require code changes in the new processor.

However there's a problem here, in that the config input name is given
as
public static final String INPUT_CONFIG = "config";
in ProcessorImpl.java; so we can't override it.

So what I did was implement a new method, PipelineConfigName() in the
PipelineProcessor class; change other code in the PipelineProcessor
class to use this instead of INPUT_CONFIG; then in my inherited class
override this method to use a different name for the config input.

However this does mean modifying the base OPS code, rather than just
adding to it.

This technique is very useful to us as it means that we can
- implement a new pipeline component as an XPL initially
- declare it in custom-processors.xml
- call it as if we were calling a custom processor
- if we decide to write our own custom processor to implement the
functionality we then need to make no application code changes.

It's also a useful way of declaring utility pipelines, so that if paths
to the xpl change in a new project we don't have to change any code,
just the custom-processors.xml declaration.

If you're interested I can submit the code changes I made; or maybe you
have an idea for a more elegant approach?

Steve

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Alessandro Vernet
Sent: 17 February 2006 01:19
To: [hidden email]
Subject: Re: [ops-users] Implementing utility pipelines as custom
processors, with a migration path to java implementation

Stephen,

I guess doing your own processor that uses the code of the Pipeline
processor is the way to go. You can then even call your own processor
"oxf:pipeline" and override the built-in Pipeline processor, if you
don't think that might be confusing.

Alex

On 1/27/06, Stephen Bayliss <[hidden email]> wrote:
> Eric
>
> I had a go at this, ie customising the existing pipeline processor so
> that it would accept either a "config" input or a "pipeline" input;
and

> if it gets a "pipeline" input it uses that instead of the the "config"
> input.
>
> Got it working fine....
>
> But...
>
> The only way to get it working was to not have
> addInputInfo(new ProcessorInputOutputInfo(INPUT_CONFIG,
> PIPELINE_NAMESPACE_URI));
> in the constructor (as at this point it's not known if a "config"

input

> or a "pipeline" input will be created).
>
> However, this means that the XPL input is not validated, which is
> obviously a Bad Thing.
>
> And I can't work out any way of plugging validation into the correct
> input at a later point, ie after it has been created and added (this
> could be done in the start method).
>
> Any ideas?
>
> My fallback is to create a pipeline processor proxy, ie a new pipeline
> processor that expects its XPL input on a "pipeline" input.
>
> Steve
>
>
>
> -----Original Message-----
> From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik

Bruchez

> Sent: 25 January 2006 23:16
> To: [hidden email]
> Subject: Re: [ops-users] Implementing utility pipelines as custom
> processors, with a migration path to java implementation
>
> Stephen Bayliss wrote:
>
> > Disadvantages with this approach
> > --------------------------------
> > - oxf:pipeline uses its config input to provide the xpl pipeline to
> > call. This means that the utility xpl pipeline cannot have a

config

> > input (and if you want to avoid code changes later, your java
> > implementation will not have a config input), which is not great
> > (currently we use a naming convention of xconfig as the input to
> utility
> > pipelines to deal with this, but this is not ideal)
>
> Granted, that's a drawback.
>
> > - maybe OPS's caching mechanism won't cope very well with this
> approach?
>
> No, it should cope just fine.
>
> > One suggestion I have is to change the code for the current
> oxf:pipeline
> > processor:
> > - have a new optional input called "pipeline"
> > - if this input is present, then use this in place of the current
> > "config" input
> > - if this input is not present, then use the config input as before
> >
> > Thus existing behaviour is preserved, but usage of the config input
> in
> > called pipelines is also allowed.
> >
> > The processor declaration in custom-processors.xml would use an

input
> > named "pipeline" to reference the xpl pipeline to be called, and

you

> are
> > then free to use the config input as per other processors.
> >
> > What do people think of this approach?
>
> In the early days, we kind of decided to standardize on a "config"
> name for certain inputs. Now it hasn't proven a perfect idea. Changing
> to "pipeline" and implementing the above behavior would be probably
> ok, but somebody would have to work on it ;-)
>
> -Erik
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the

[hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page:

http://www.objectweb.org/wws
>
>
>

--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Alessandro Vernet

Re: Implementing utility pipelines as custom processors, with a migration path to java implementation

Administrator

Hi Stephen,

I am reluctant to make the code more complex and add this indirection
(protected method returning the name of the input for the pipeline).
One way to avoid adding the indirection and modifying the
PipelineProcessor code is to use composition instead of inheritance in
your processor.

In your new processor, use the PipelineReader to parse & analyze the
"pipeline" input. You will get an instance of ASTPipeline which
represents your pipeline. Then instantiate and run the
PipelineProcessor with that representation of the pipeline. You can
see code that does this in the IMProcessor.

Alex

On 2/23/06, Stephen Bayliss <[hidden email]> wrote:

> Alex
>
> I did try this approach, with some success.
>
> The easiest way (in terms of coding) is to inherit off the existing
> pipeline processor and override the values for the name of the config
> input. That way any code changes, bug fixes etc in the main pipeline
> processor don't require code changes in the new processor.
>
> However there's a problem here, in that the config input name is given
> as
> public static final String INPUT_CONFIG = "config";
> in ProcessorImpl.java; so we can't override it.
>
> So what I did was implement a new method, PipelineConfigName() in the
> PipelineProcessor class; change other code in the PipelineProcessor
> class to use this instead of INPUT_CONFIG; then in my inherited class
> override this method to use a different name for the config input.
>
> However this does mean modifying the base OPS code, rather than just
> adding to it.
>
> This technique is very useful to us as it means that we can
> - implement a new pipeline component as an XPL initially
> - declare it in custom-processors.xml
> - call it as if we were calling a custom processor
> - if we decide to write our own custom processor to implement the
> functionality we then need to make no application code changes.
>
> It's also a useful way of declaring utility pipelines, so that if paths
> to the xpl change in a new project we don't have to change any code,
> just the custom-processors.xml declaration.
>
> If you're interested I can submit the code changes I made; or maybe you
> have an idea for a more elegant approach?
>
> Steve
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Alessandro Vernet
> Sent: 17 February 2006 01:19
> To: [hidden email]
> Subject: Re: [ops-users] Implementing utility pipelines as custom
> processors, with a migration path to java implementation
>
> Stephen,
>
> I guess doing your own processor that uses the code of the Pipeline
> processor is the way to go. You can then even call your own processor
> "oxf:pipeline" and override the built-in Pipeline processor, if you
> don't think that might be confusing.
>
> Alex
>
> On 1/27/06, Stephen Bayliss <[hidden email]> wrote:
> > Eric
> >
> > I had a go at this, ie customising the existing pipeline processor so
> > that it would accept either a "config" input or a "pipeline" input;
> and
> > if it gets a "pipeline" input it uses that instead of the the "config"
> > input.
> >
> > Got it working fine....
> >
> > But...
> >
> > The only way to get it working was to not have
> > addInputInfo(new ProcessorInputOutputInfo(INPUT_CONFIG,
> > PIPELINE_NAMESPACE_URI));
> > in the constructor (as at this point it's not known if a "config"
> input
> > or a "pipeline" input will be created).
> >
> > However, this means that the XPL input is not validated, which is
> > obviously a Bad Thing.
> >
> > And I can't work out any way of plugging validation into the correct
> > input at a later point, ie after it has been created and added (this
> > could be done in the start method).
> >
> > Any ideas?
> >
> > My fallback is to create a pipeline processor proxy, ie a new pipeline
> > processor that expects its XPL input on a "pipeline" input.
> >
> > Steve
> >
> >
> >
> > -----Original Message-----
> > From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik
> Bruchez
> > Sent: 25 January 2006 23:16
> > To: [hidden email]
> > Subject: Re: [ops-users] Implementing utility pipelines as custom
> > processors, with a migration path to java implementation
> >
> > Stephen Bayliss wrote:
> >
> > > Disadvantages with this approach
> > > --------------------------------
> > > - oxf:pipeline uses its config input to provide the xpl pipeline to
> > > call. This means that the utility xpl pipeline cannot have a
> config
> > > input (and if you want to avoid code changes later, your java
> > > implementation will not have a config input), which is not great
> > > (currently we use a naming convention of xconfig as the input to
> > utility
> > > pipelines to deal with this, but this is not ideal)
> >
> > Granted, that's a drawback.
> >
> > > - maybe OPS's caching mechanism won't cope very well with this
> > approach?
> >
> > No, it should cope just fine.
> >
> > > One suggestion I have is to change the code for the current
> > oxf:pipeline
> > > processor:
> > > - have a new optional input called "pipeline"
> > > - if this input is present, then use this in place of the current
> > > "config" input
> > > - if this input is not present, then use the config input as before
> > >
> > > Thus existing behaviour is preserved, but usage of the config input
> > in
> > > called pipelines is also allowed.
> > >
> > > The processor declaration in custom-processors.xml would use an
> input
> > > named "pipeline" to reference the xpl pipeline to be called, and
> you
> > are
> > > then free to use the config input as per other processors.
> > >
> > > What do people think of this approach?
> >
> > In the early days, we kind of decided to standardize on a "config"
> > name for certain inputs. Now it hasn't proven a perfect idea. Changing
> > to "pipeline" and implementing the above behavior would be probably
> > ok, but somebody would have to work on it ;-)
> >
> > -Erik
> >
> >
> >
> >
> >
> >
> > --
> > You receive this message as a subscriber of the
> [hidden email] mailing list.
> > To unsubscribe: mailto:[hidden email]
> > For general help: mailto:[hidden email]?subject=help
> > ObjectWeb mailing lists service home page:
> http://www.objectweb.org/wws
> >
> >
> >
>
>
> --
> Blog (XML, Web apps, Open Source):
> http://www.orbeon.com/blog/
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>

--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet

Stephen Bayliss

RE: Implementing utility pipelines as custom processors, with a migration path to java implementation

In reply to this post by Stephen Bayliss

Hi Alex

Fair point!

Thanks for the pointer to IMProcessor, I'll check this out and try and
come up with something a bit more elegant.

Steve

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Alessandro Vernet
Sent: 28 February 2006 01:47
To: [hidden email]
Subject: Re: [ops-users] Implementing utility pipelines as custom
processors, with a migration path to java implementation

Hi Stephen,

I am reluctant to make the code more complex and add this indirection
(protected method returning the name of the input for the pipeline).
One way to avoid adding the indirection and modifying the
PipelineProcessor code is to use composition instead of inheritance in
your processor.

In your new processor, use the PipelineReader to parse & analyze the
"pipeline" input. You will get an instance of ASTPipeline which
represents your pipeline. Then instantiate and run the
PipelineProcessor with that representation of the pipeline. You can
see code that does this in the IMProcessor.

Alex

On 2/23/06, Stephen Bayliss <[hidden email]> wrote:

paths
> to the xpl change in a new project we don't have to change any code,
> just the custom-processors.xml declaration.
>
> If you're interested I can submit the code changes I made; or maybe

you

> have an idea for a more elegant approach?
>
> Steve
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Alessandro Vernet
> Sent: 17 February 2006 01:19
> To: [hidden email]
> Subject: Re: [ops-users] Implementing utility pipelines as custom
> processors, with a migration path to java implementation
>
> Stephen,
>
> I guess doing your own processor that uses the code of the Pipeline
> processor is the way to go. You can then even call your own processor
> "oxf:pipeline" and override the built-in Pipeline processor, if you
> don't think that might be confusing.
>
> Alex
>
> On 1/27/06, Stephen Bayliss <[hidden email]> wrote:
> > Eric
> >
> > I had a go at this, ie customising the existing pipeline processor

so
> > that it would accept either a "config" input or a "pipeline" input;
> and
> > if it gets a "pipeline" input it uses that instead of the the

"config"

> > input.
> >
> > Got it working fine....
> >
> > But...
> >
> > The only way to get it working was to not have
> > addInputInfo(new ProcessorInputOutputInfo(INPUT_CONFIG,
> > PIPELINE_NAMESPACE_URI));
> > in the constructor (as at this point it's not known if a "config"
> input
> > or a "pipeline" input will be created).
> >
> > However, this means that the XPL input is not validated, which is
> > obviously a Bad Thing.
> >
> > And I can't work out any way of plugging validation into the correct
> > input at a later point, ie after it has been created and added (this
> > could be done in the start method).
> >
> > Any ideas?
> >
> > My fallback is to create a pipeline processor proxy, ie a new

pipeline

> > processor that expects its XPL input on a "pipeline" input.
> >
> > Steve
> >
> >
> >
> > -----Original Message-----
> > From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik
> Bruchez
> > Sent: 25 January 2006 23:16
> > To: [hidden email]
> > Subject: Re: [ops-users] Implementing utility pipelines as custom
> > processors, with a migration path to java implementation
> >
> > Stephen Bayliss wrote:
> >
> > > Disadvantages with this approach
> > > --------------------------------
> > > - oxf:pipeline uses its config input to provide the xpl pipeline

> > > call. This means that the utility xpl pipeline cannot have a
> config
> > > input (and if you want to avoid code changes later, your java
> > > implementation will not have a config input), which is not great
> > > (currently we use a naming convention of xconfig as the input to
> > utility
> > > pipelines to deal with this, but this is not ideal)
> >
> > Granted, that's a drawback.
> >
> > > - maybe OPS's caching mechanism won't cope very well with this
> > approach?
> >
> > No, it should cope just fine.
> >
> > > One suggestion I have is to change the code for the current
> > oxf:pipeline
> > > processor:
> > > - have a new optional input called "pipeline"
> > > - if this input is present, then use this in place of the current
> > > "config" input
> > > - if this input is not present, then use the config input as

before
> > >
> > > Thus existing behaviour is preserved, but usage of the config

input

> > in
> > > called pipelines is also allowed.
> > >
> > > The processor declaration in custom-processors.xml would use an
> input
> > > named "pipeline" to reference the xpl pipeline to be called, and
> you
> > are
> > > then free to use the config input as per other processors.
> > >
> > > What do people think of this approach?
> >
> > In the early days, we kind of decided to standardize on a "config"
> > name for certain inputs. Now it hasn't proven a perfect idea.

Changing

> > to "pipeline" and implementing the above behavior would be probably
> > ok, but somebody would have to work on it ;-)
> >
> > -Erik
> >
> >
> >
> >
> >
> >
> > --
> > You receive this message as a subscriber of the
> [hidden email] mailing list.
> > To unsubscribe: mailto:[hidden email]
> > For general help: mailto:[hidden email]?subject=help
> > ObjectWeb mailing lists service home page:
> http://www.objectweb.org/wws
> >
> >
> >
>
>
> --
> Blog (XML, Web apps, Open Source):
> http://www.orbeon.com/blog/
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the

[hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: