Daniel Fagerstrom wrote:
Here I also would like to advertise a neat pattern (the whiteboard
pattern) that we use in the OSGi-blocks architecture, that we maybe
could use without OSGi in 2.2.
So, in the block architecture we set up a BlockServlet (or other
controllers) as a managed
Peter Hunsberger wrote:
Interesting. Sounds perhaps useful without the dual implementations
as just simplifying the core, but the ability to plug in your own base
processor also sounds interesting; if we ever go to the point where
all our processing is completely database driven I take it
Carsten Ziegeler wrote:
Some time ago we discussed very lengthy that our core interface, the
Processor, is not the best interface we ever invented. The processor
should be the main entrance to the Cocoon processing engine.
snip/
So, WDYT?
Interesting.
However, a few remarks:
- how
Carsten Ziegeler skrev:
Some time ago we discussed very lengthy that our core interface, the
Processor, is not the best interface we ever invented. The processor
should be the main entrance to the Cocoon processing engine.
As I need a simple way of adding my own processor in my project, I
On 7/11/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...Basically integrating Cocoon in another framework is then
a) get the cocoon spring bean container from the servlet context, b) get
the processor bean from the spring container and c) invoke the processor...
I like this, and pluggable
Daniel Fagerstrom wrote:
Often you are going to need the servlet configuration and/or context
and then you are back on the Servlet interface again. OTH, having a
Servlet as a managed component is slightly complicated as one need to
keep track on both its life cycle as a managed component and
Sylvain Wallez wrote:
However, a few remarks:
- how is Processor different from Servlet?
The interface is similar. The difference is configuration and who
manages the component. If a processor is a component we can use all nice
features of spring for that and I think the configuration is
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Often you are going to need the servlet configuration and/or context
and then you are back on the Servlet interface again. OTH, having a
Servlet as a managed component is slightly complicated as one need to
keep track on both its life cycle as a
Carsten Ziegeler skrev:
Sylvain Wallez wrote:
However, a few remarks:
- how is Processor different from Servlet?
The interface is similar. The difference is configuration and who
manages the component. If a processor is a component we can use all nice
features of spring for that and I
Daniel Fagerstrom wrote:
Don't think this is the best way to do it. The current
MountTableProcessor means that you only can mount SitemapProcessor and
no other kinds of controllers, as it explicitly manage the creation of
the SitemapProcessors. IMO it is better to let the component
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Don't think this is the best way to do it. The current
MountTableProcessor means that you only can mount SitemapProcessor and
no other kinds of controllers, as it explicitly manage the creation of
the SitemapProcessors. IMO it is better to
Daniel Fagerstrom wrote:
Are you using so many sitemap processors so that becomes a problem? We
have something like that today. The tree processor is configured as a
component, or will a Spring bean configuration be much more verbose?
No, the spring bean config might look the same (more or
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Are you using so many sitemap processors so that becomes a problem? We
have something like that today. The tree processor is configured as a
component, or will a Spring bean configuration be much more verbose?
No, the spring bean config
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Sylvain Wallez wrote:
However, a few remarks:
- how is Processor different from Servlet?
The interface is similar. The difference is configuration and who
manages the component. If a processor is a component we can use all nice
Some time ago we discussed very lengthy that our core interface, the
Processor, is not the best interface we ever invented. The processor
should be the main entrance to the Cocoon processing engine.
As I need a simple way of adding my own processor in my project, I
started to create new
On 7/11/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
snip/
I committed the new stuff as a prototype to the whiteboard
http://svn.apache.org/repos/asf/cocoon/whiteboard/processor/
snip/
Currently I have two Processor implementations. One of them is the
sitemap processor embedding the
16 matches
Mail list logo
