On 27 Jun 2003 at 9:34, Unico Hommes wrote:
> If I can make it that all parts of the system can share the same
> Cocoon object then I would definitely prefer that. Because apart from
> memory, there's also the cache that is shared.
Presumably you're referring to a cache in a transient store?
Let's discuss this in a moment...
> I don't think it is necessary to make it thread-safe though. Once we
> factor out the Cocoon creation code CocoonBean would become a
> lightweight object.
Yup. But again, it might not be that hard to make it thread safe. Presumably just an
object passed in that contains all of its configuration information.
> > Otherwise we work out a way to get hold of the Cocoon
> > instance of the servlet.
>
> Perhaps CocoonServlet could put it in the application Context object.
Let's wait until we've worked out what kind of component we're talking about - then
we can decide how that component gets hold of its Cocoon object.
> > Okay. So the bean needs to log to a particular logging
> > category what it is up to, so that you can tell whether it
> > succeeds or not, and then return to the next sitemap
> > component (as SAX events) either the results of the page
> > generation (if done
> > synchronously) or the fact that a request was successfully
> > made to the bean (if done asynchronously).
>
> Sounds good to me.
Great.
> > > > I would say there's two sides to the approach I would
> > > > recommend: small steps, and keep it compatible where
> > possible. Let's
> > > > identify small ways we can get the functionality we want, whilst
> > > > respecting the interfaces that others are quite possibly
> > using. So,
> > > > what first small steps would assist you in your work?
> > >
> > > Well, I'd like to use CocoonBean for publication runs, but
> > I want to
> > > reuse Cocoon instance. So as a start I think adding a
> > constructor to
> > > CocoonBean like you proposed would be a good start.
> >
> > Great. Send me a patch and I'll commit it.
>
> OK. I'll also have to rearrange initialize() for that because some
> stuff still needs to be executed either way (run related stuff) and
> some stuff shouldn't (Cocoon creation stuff).
That's stuff I've not personally touched. Can't say I really understand it all, so I'm
glad
you're prepared to do it!
> I don't agree that sitemap components are the way to go. Of course a
> set of sitemap components requires minimal or no changes to Cocoon
> core components and provides a lot of familiar plumbing. But the fact
> is that it's an awkward arrangement of responsibilities: Cocoon
> manages and runs sitemap components that in turn (manage and) run
> Cocoon.
If you don't want it to be a sitemap component, how else would you propose to do it?
Somehow it needs to be under the control of the sitemap so as to exist as a part of
the URI space.
> I think that the role of the sitemap and its components should
> be more or less constrained to creating documents.
Hmm. Not so sure - you've got Lucene that has a page to generate an index. Are
there not other examples too? The thing is, that if you create a sitemap component,
you can build around the publishing service a web site for deployment. Imagine a site
that you log onto (e.g. using the authentication framework). Then, Cocoon reads a
database to find out what sites you are allowed to publish, and offers you a drop down
list of those sites. Maybe pages need deploying in a specific sequence, so this
sequence can be managed by the flow. And when you want a page, pages or a site to
be generated, you click 'go', and off it goes, probably in the background, allowing
you
to get on with other stuff. Then you might have a 'status' page, based around a
'PublishServiceStatusGenerator' that can tell you how it's getting on. It allows the
site
designer to build a web interface to publish their site. That's why I would like to
see it
as a sitemap component, because I would like to use it in building sites to build
sites!
For poor people, they can stick the Cocoon site on an ADSL line, and have it publish
to a proper web server. Multiple authors can upload content and publish it, and the
world sees a decent web server.
> > (I've got some code (that doesn't yet work) that'll make the
> > bean only generate pages that haven't changed. That'd make
> > the publishing service even more powerful if we can get it working).
>
> Great! We could eventually also supply a way to delete remote
> resources when they no longer exist locally.
Should be possible. If you have some understanding of the Cocoon Cache, you can
probably help me get it to work.
Oh, I'm in the process of reworking Main.java and the bean to add a BeanListener
interface. That means that the bean does not do any outputting to System.out. It just
calls methods on the Listener interface - the bean caller needs to register a listener
with the bean. I've moved the broken link reporting into Main, so that the bean simply
reports a broken link, leaving it to the user to decide exactly what should happen
when a broken link is found. Here's the interface as it is at the moment:
public interface BeanListener {
public void pageGenerated(String uri, int linksInPage, int pagesRemaining);
public void messageGenerated(String msg);
public void warningGenerated(String uri, String warning);
public void brokenLinkFound(String uri, String message);
}
I look forward to your initialisation patch.
Regards, Upayavira
