cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: Extending the Bean (non-HTML)
Date Thu, 14 Aug 2003 16:03:32 GMT
Upayavira wrote:

>[here's a non-HTML version - mailer misbehaved again :-( ]
>

OT: Have you tried mozilla mail client?


> * split the bean into a CocoonWrapper that handles configuring a Cocoon object  
>and handling a single request, and a CocoonBean which handles crawling 
>

What is the API of these new beans? Please do not forget that CocoonBean 
is out of the door with 2.1 release and people (might be) already 
building applications with CocoonBean, meaning, you can't change 
CocoonBean API in backward incompatible way without proper deprecating 
and support of released functionality.


> * Made the CocoonBean use a Crawler class (derived from the one in the  
>scratchpad Ant task)
>

Do you mean org.apache.cocoon.components.crawler.Crawler? I don't see 
how it can be used in CocoonBean. Can you elaborate?


> * Moved all of the URI logic (mangling URIs etc) into the Target class
>

Sounds good.


> * made it report the time taken to generate a single page
>

Ok.


>Next I want to: 
>
> * moving the member variables of the wrapper and bean into a Context object, so  
>that the Bean can be used in a ThreadSafe environment.
>

AFAIU, CocoonBean.processURI is already thread safe. All addTarget() 
methods are obviously not. addTarget() methods can easily be made 
threadsafe (in some sense -- call to addTarget in one thread does not 
break bean but affects process() running in another thread) by 
synchronyzing access to the targets collection. It can be thread safe in 
another sense too (calls to processTargets in different threads are 
independent of each other): you just need to add processTargets(targets) 
method.


> * rework the way the bean is configured (possibly using Configuration objects)
>

Why would you need those Configuration objects?


> * improve reporting so that it reports pages generated, time taken per page, the  
>links found in a page, stack trace from errors, pages that contain broken links, and 

>more.
>

Ok.


>  * Make this reporting use SAX (to a file), so that in future it can be the basis of
a  
>publishing service
>

I think that's overkill. Especially writing to the file part. Extend 
BeanListener interface if you like, implement FileBeanListener if you 
need, but I don't think SAX is really what you need here.


> * Get caching working properly, and make it use ifModifiedSince() to determine  
>whether to save the file or not.
>

Must-have feature. Top priority. I hope you've seen my emails on 
persistent store subject.


> * Build a simple Ant task to replace Main.java for ant driven processes
>

Good.


> * Make Cocoon work with an external Cocoon object, again for the sake of a  
>PublishingService
>

I don't get this. What Cocoon with which external Cocoon?


> * replace the contents of the cli.xconf file with correct settings for generating  
>documentation from the built webapp, keeping the documentation system working
>

Don't know what you mean.


> * implement exclude/include, a la Ant in the cli.xconf
>

Ok.


> * make it configurable as to which pages are scanned for links (why generate  
>/docs/logo.gif?cocoon-view=links)?
>

Set of extensions which are not quieried for the links (configuration 
parameter don't-follow-links=gif, jpg, png)?


> * work out how to implement Vadim's idea for a single pipeline with an  
>XMLTeePipe to generate both a link view and page view in one hit
>

Yep. Should increase performance and conformance!


> * improve the cli.xconf format to be more flexible, e.g: generate multiple pages to 

>a single destination, and to have links followed on some pages but not others, etc
>

Ok.


>Phew. More than I thought! And there's more I haven't mentioned...
>

I'm scared! :)

Vadim



Mime
View raw message