You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Upayavira <uv...@upaya.co.uk> on 2002/12/10 14:04:17 UTC
[Proposal] A little reworking of the Cocoon Command Line
Dear All,
I would like to do some minor rewriting of the command line Main class, particularly
splitting it into classes:
1. org.apache.cocoon.Main: this is the class that is accessed from the command line. Its
functionality and command line options would remain the same. However, its
functionality would be provided by instantiating:
2. org.apache.cocoon.ProgrammaticInterface (or some such name): this would be a
programmatic interface to running Cocoon. To start with, it would just give an Interface
to the functionality currently provided within the Cocoon command line. So you could
have code such as:
ProgrammaticInterface cocoon = new ProgrammaticInterface();
cocoon.setFollowLinks(true);
cocoon.setLogLevel(DEBUG);
cocoon.process();
Once that simple split has been done, the second change I'd like to make is to create an
FTPWritingEnvironment class, and allow the Programmatic Interface (and thus the
command line) to use this. This would allow the command line to generate content and
then send that content by FTP up to a web server. I would code it to use checksums to
prevent unnecessary uploading, thus maintaining a static synchronised version of a
Cocoon driven site on a server that does not directly support Cocoon.
This for me, being able to publish Cocoon based sites by FTP is a bit of a holy grail. For
the personal projects I work on, all of which are now based upon Cocoon, I have to use
cheap servers that cannot run Java, and thus cannot run Cocoon. Therefore, FTP is the
only way.
Before I start doing anything, I would like to check my proposal out with those on this
list.
Upayavira
North London, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Upayavira wrote:
> Dear All,
>
> I would like to do some minor rewriting of the command line Main class, particularly
> splitting it into classes:
>
> 1. org.apache.cocoon.Main: this is the class that is accessed from the command line. Its
> functionality and command line options would remain the same. However, its
> functionality would be provided by instantiating:
>
> 2. org.apache.cocoon.ProgrammaticInterface (or some such name): this would be a
> programmatic interface to running Cocoon. To start with, it would just give an Interface
> to the functionality currently provided within the Cocoon command line. So you could
> have code such as:
>
> ProgrammaticInterface cocoon = new ProgrammaticInterface();
> cocoon.setFollowLinks(true);
> cocoon.setLogLevel(DEBUG);
> cocoon.process();
>
> Once that simple split has been done, the second change I'd like to make is to create an
> FTPWritingEnvironment class, and allow the Programmatic Interface (and thus the
> command line) to use this. This would allow the command line to generate content and
> then send that content by FTP up to a web server. I would code it to use checksums to
> prevent unnecessary uploading, thus maintaining a static synchronised version of a
> Cocoon driven site on a server that does not directly support Cocoon.
>
> This for me, being able to publish Cocoon based sites by FTP is a bit of a holy grail. For
> the personal projects I work on, all of which are now based upon Cocoon, I have to use
> cheap servers that cannot run Java, and thus cannot run Cocoon. Therefore, FTP is the
> only way.
>
> Before I start doing anything, I would like to check my proposal out with those on this
> list.
Your ideas are very interesting.
I suggest you to look in the scratchpad for the "ant" proposal, that
also does a refactoring of the CLI. Most of that code can do without
Ant, and can be the base for your Programmatic Interface.
If you could combine that approach with yours, it would be awesome :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Bean Design
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bernhard Huber wrote:
> hi,
>
>> Also, does anyone know of any decent java FTP client classes?
>
> what about http://www.savarese.org/oro/downloads/index.html#NetComponents
> ant uses it for its <ftp> ant task
> impl.
All this has moved to Jakarta, and the ftp client is now in
commons/sandbox/net.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Bean Design
Posted by Bernhard Huber <be...@a1.net>.
hi,
> Also, does anyone know of any decent java FTP client classes?
>
what about http://www.savarese.org/oro/downloads/index.html#NetComponents
ant uses it for its <ftp> ant task
impl.
best regards bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Bean Design
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
>I have been given some time at work during which I would like to implement a
>CocoonBean (name and much of the below suggested by Vadim). I should have time
>over the Christmas holiday. I would therefore like to try to pin down a spec for it before
>then.
>
>I would propose the following, as a code sample:
>
>CocoonBean cocoon = new CocoonBean("c:/working", "c:/context");
>
>/*** Set up Cocoon instance (optional) ***/
>cocoon.setConfigFile("WEB-INF/cocoon.xconf");
>cocoon.setBrokenLinkFile("c:/brokenlinks.txt");
>cocoon.setAcceptOptions("acceptoptions");
>cocoon.setAgentOptions("agentoptions");
>
>cocoon.setPrecompileOnly(false);
>cocoon.setRecursionOn();
>
>
Is it "follow-links"? Then it's better be
setFollowLinks(true);
setFollowLinks(false);
>/*** Set up logging (optional) ***/
>cocoon.setLogKit("logkitname");
>cocoon.setLogLevel("ERROR");
>cocoon.setLogger("loggername");
>
>/*** Process a single URI and pass results to an output stream ***/
>String URI = "cocoon:/blah/foobar.html?page=1";
>
>File f = new File("foobar.html");
>FileOutputStream fos = new FileOutputStream(f);
>
>cocoon.processURI(URI, fos);
>
>/*** Process a number of URIs, sending the results to a 'destination' ***/
>cocoon.addTarget("cocoon:/blah/foobar.html?page=2");
>cocoon.addTarget("cocoon:/blah/foobar.html?page=3");
>cocoon.setDestination(new FileDestination("c:/destination"));
>
>cocoon.process();
>
>cocoon.setDestination(new FTPDestination("c:/localfolder", "ftp.myhost.com", "bill",
>"myPassword", "foo/bar/"));
>cocoon.process();
>
>
There is another option - but I'm not sure that it is better. Just for
you consideration:
cocoon.process(ArrayList targets, Destination destination);
This way cocoon bean could be made thread safe (if the rest of it is
threadsafe).
>Unless I hear from anyone, I'll just get on and do it like this.
>
>
Go ahead.
>Also, does anyone know of any decent java FTP client classes?
>
>
sun.net.ftp.FtpClient has couple of bugs and limited functionality, but
it's Ok for many cases.
Vadim
>Regards, Upayavira
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Bean Design
Posted by Giacomo Pati <gi...@apache.org>.
On Tue, 17 Dec 2002, Upayavira wrote:
> I have been given some time at work during which I would like to implement a
> CocoonBean (name and much of the below suggested by Vadim). I should have time
> over the Christmas holiday. I would therefore like to try to pin down a spec for it before
> then.
>
> I would propose the following, as a code sample:
>
> CocoonBean cocoon = new CocoonBean("c:/working", "c:/context");
>
> /*** Set up Cocoon instance (optional) ***/
>
> cocoon.setConfigFile("WEB-INF/cocoon.xconf");
> cocoon.setBrokenLinkFile("c:/brokenlinks.txt");
> cocoon.setAcceptOptions("acceptoptions");
> cocoon.setAgentOptions("agentoptions");
>
> cocoon.setPrecompileOnly(false);
> cocoon.setRecursionOn();
>
> /*** Set up logging (optional) ***/
> cocoon.setLogKit("logkitname");
> cocoon.setLogLevel("ERROR");
> cocoon.setLogger("loggername");
>
> /*** Process a single URI and pass results to an output stream ***/
> String URI = "cocoon:/blah/foobar.html?page=1";
>
> File f = new File("foobar.html");
> FileOutputStream fos = new FileOutputStream(f);
>
> cocoon.processURI(URI, fos);
>
> /*** Process a number of URIs, sending the results to a 'destination' ***/
>
> cocoon.addTarget("cocoon:/blah/foobar.html?page=2");
> cocoon.addTarget("cocoon:/blah/foobar.html?page=3");
> cocoon.setDestination(new FileDestination("c:/destination"));
>
> cocoon.process();
>
> cocoon.setDestination(new FTPDestination("c:/localfolder", "ftp.myhost.com", "bill",
> "myPassword", "foo/bar/"));
> cocoon.process();
>
> Unless I hear from anyone, I'll just get on and do it like this.
>
> Also, does anyone know of any decent java FTP client classes?
Look into the jakarta-commons-sandbox/net repository for the FTPClient.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cocoon Bean Design
Posted by Upayavira <uv...@upaya.co.uk>.
I have been given some time at work during which I would like to implement a
CocoonBean (name and much of the below suggested by Vadim). I should have time
over the Christmas holiday. I would therefore like to try to pin down a spec for it before
then.
I would propose the following, as a code sample:
CocoonBean cocoon = new CocoonBean("c:/working", "c:/context");
/*** Set up Cocoon instance (optional) ***/
cocoon.setConfigFile("WEB-INF/cocoon.xconf");
cocoon.setBrokenLinkFile("c:/brokenlinks.txt");
cocoon.setAcceptOptions("acceptoptions");
cocoon.setAgentOptions("agentoptions");
cocoon.setPrecompileOnly(false);
cocoon.setRecursionOn();
/*** Set up logging (optional) ***/
cocoon.setLogKit("logkitname");
cocoon.setLogLevel("ERROR");
cocoon.setLogger("loggername");
/*** Process a single URI and pass results to an output stream ***/
String URI = "cocoon:/blah/foobar.html?page=1";
File f = new File("foobar.html");
FileOutputStream fos = new FileOutputStream(f);
cocoon.processURI(URI, fos);
/*** Process a number of URIs, sending the results to a 'destination' ***/
cocoon.addTarget("cocoon:/blah/foobar.html?page=2");
cocoon.addTarget("cocoon:/blah/foobar.html?page=3");
cocoon.setDestination(new FileDestination("c:/destination"));
cocoon.process();
cocoon.setDestination(new FTPDestination("c:/localfolder", "ftp.myhost.com", "bill",
"myPassword", "foo/bar/"));
cocoon.process();
Unless I hear from anyone, I'll just get on and do it like this.
Also, does anyone know of any decent java FTP client classes?
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by Upayavira <uv...@upaya.co.uk>.
> >2. org.apache.cocoon.ProgrammaticInterface (or some such name):
> The name of CocoonBean was proposed some time ago for the class with
> such functionality.
Sounds good. Better than my name. I'll switch.
> There are two levels to Main.java functionality:
> 1. Process one request
> 2. Process multiple requests, using multiple starting URLs and/or
> crawling.
>
> You suggest implementing programmatic interface for 2nd level. I think
> it is more important to have it for the 1st level. Example method can
> be:
>
> cocoon.process(input, output);
>
> Where input can be String - URL with Parameters (or Environment), and
> output is OutputStream.
I agree with you on your two levels of functionality. And I agree that I have reproduced
the second. This is not because that is what I want, it is rather because that is all I have
been able to work out how to do as yet. I have not found finding my way around the
Main.java code very easy so far. But I'm sure I'll get the hang of it.
I would suggest:
cocoon.processTargets();
to process multiple targets, including recursion, and:
cocoon.processPage(URI, outputStream);
Would achieve the two functions that you refer to. I would also like to suggest the
following:
cocoon.configureFTP(host, port, user, pass, rootPath, folderStripCount);
cocoon.processTargets();
The configureFTP has set up the details for the FTP server, including the root path for
the files on the server, and also details how many folder names should be stripped from
the front of a file path when it is sent to the server, such that:
cocoon:/sites/books/authors/smith.html, having a folder strip count of 1 would send up
the page as books/authors/smith.html.
Because the configureFTP function has been called, the processTargets() would
automatically do an FTP send as well as saving to disk.
Therefore, there are three functionalities that would be useful from a bean:
1) Have a page returned to the supplied output stream
2) Have a page saved or a site spidered and saved to the local disk.
3) Have a page saved or a site spidered and saved locally, and then sent to a remote
FTP server (making use of locally stored checksums to prevent unnecessary uploading
work).
Make sense?
Regards,
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
Hi,
if you are working on this, please have a look at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12154
and
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12158
Michael
Upayavira wrote:
>
> Dear All,
>
> I would like to do some minor rewriting of the command line Main class, particularly
> splitting it into classes:
>
> 1. org.apache.cocoon.Main: this is the class that is accessed from the command line. Its
> functionality and command line options would remain the same. However, its
> functionality would be provided by instantiating:
>
> 2. org.apache.cocoon.ProgrammaticInterface (or some such name): this would be a
> programmatic interface to running Cocoon. To start with, it would just give an Interface
> to the functionality currently provided within the Cocoon command line. So you could
> have code such as:
>
> ProgrammaticInterface cocoon = new ProgrammaticInterface();
> cocoon.setFollowLinks(true);
> cocoon.setLogLevel(DEBUG);
> cocoon.process();
>
> Once that simple split has been done, the second change I'd like to make is to create an
> FTPWritingEnvironment class, and allow the Programmatic Interface (and thus the
> command line) to use this. This would allow the command line to generate content and
> then send that content by FTP up to a web server. I would code it to use checksums to
> prevent unnecessary uploading, thus maintaining a static synchronised version of a
> Cocoon driven site on a server that does not directly support Cocoon.
>
> This for me, being able to publish Cocoon based sites by FTP is a bit of a holy grail. For
> the personal projects I work on, all of which are now based upon Cocoon, I have to use
> cheap servers that cannot run Java, and thus cannot run Cocoon. Therefore, FTP is the
> only way.
>
> Before I start doing anything, I would like to check my proposal out with those on this
> list.
>
> Upayavira
> North London, UK
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by David Crossley <cr...@indexgeo.com.au>.
Upayavira wrote:
<snip good stuff about a programmatic interface to Cocoon CLI/>
>
> This for me, being able to publish Cocoon based sites by FTP is
> a bit of a holy grail. For the personal projects I work on, all
> of which are now based upon Cocoon, I have to use cheap servers
> that cannot run Java, and thus cannot run Cocoon. Therefore, FTP
> is the only way.
>
> Before I start doing anything, I would like to check my proposal
> out with those on this list.
Your proposal seems fine and will bring some useful
functionality.
Now, about the separate concern of publishing a website to
a remote server. The new Apache Forrest project has tools to
do exactly that - generate a website using Cocoon and then
publish it to a remote website.
http://xml.apache.org/forrest/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by Stefano Mazzocchi <st...@apache.org>.
Upayavira wrote:
> Dear All,
>
> I would like to do some minor rewriting of the command line Main class, particularly
> splitting it into classes:
>
> 1. org.apache.cocoon.Main: this is the class that is accessed from the command line. Its
> functionality and command line options would remain the same. However, its
> functionality would be provided by instantiating:
>
> 2. org.apache.cocoon.ProgrammaticInterface (or some such name): this would be a
> programmatic interface to running Cocoon. To start with, it would just give an Interface
> to the functionality currently provided within the Cocoon command line. So you could
> have code such as:
>
> ProgrammaticInterface cocoon = new ProgrammaticInterface();
> cocoon.setFollowLinks(true);
> cocoon.setLogLevel(DEBUG);
> cocoon.process();
>
> Once that simple split has been done, the second change I'd like to make is to create an
> FTPWritingEnvironment class, and allow the Programmatic Interface (and thus the
> command line) to use this. This would allow the command line to generate content and
> then send that content by FTP up to a web server. I would code it to use checksums to
> prevent unnecessary uploading, thus maintaining a static synchronised version of a
> Cocoon driven site on a server that does not directly support Cocoon.
>
> This for me, being able to publish Cocoon based sites by FTP is a bit of a holy grail. For
> the personal projects I work on, all of which are now based upon Cocoon, I have to use
> cheap servers that cannot run Java, and thus cannot run Cocoon. Therefore, FTP is the
> only way.
>
> Before I start doing anything, I would like to check my proposal out with those on this
> list.
I think it's a good idea. Go for it and send us patches!
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by Litrik De Roy <co...@litrik.com>.
----- Original Message -----
From: "Upayavira" <uv...@upaya.co.uk>
To: <co...@xml.apache.org>
Sent: Tuesday, December 10, 2002 2:04 PM
Subject: [Proposal] A little reworking of the Cocoon Command Line
> I would like to do some minor rewriting of the command line Main class,
particularly
> splitting it into classes:
>
> ...
>
> Once that simple split has been done, the second change I'd like to make
is to create an
> FTPWritingEnvironment class, and allow the Programmatic Interface (and
thus the
> command line) to use this. This would allow the command line to generate
content and
> then send that content by FTP up to a web server. I would code it to use
checksums to
> prevent unnecessary uploading, thus maintaining a static synchronised
version of a
> Cocoon driven site on a server that does not directly support Cocoon.
>
> This for me, being able to publish Cocoon based sites by FTP is a bit of a
holy grail. For
> the personal projects I work on, all of which are now based upon Cocoon, I
have to use
> cheap servers that cannot run Java, and thus cannot run Cocoon. Therefore,
FTP is the
> only way.
>
Very good idea.
I have similar personal projects. They are also the playground for testing
cocoon functionality. But at the end they are "just" static websites that
are hosted on non-Java
> Before I start doing anything, I would like to check my proposal out with
those on this
> list.
Sounds like a very good idea. If you are looking for somebody to test your
code... count me in....
>
> Upayavira
> North London, UK
>
Litrik De Roy
www.litrik.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by Bernhard Huber <be...@a1.net>.
Hi,
>
> There are two levels to Main.java functionality:
> 1. Process one request
> 2. Process multiple requests, using multiple starting URLs and/or
> crawling.
>
I'm currently working on a SourceLinkStatusGenerator, it's like
LinkStatus but it will only generate links inside of cocoon,
launching a processor.process inside of the generator.
this way you have all the links available and use the cocoon sitemap
to define further processing steps for each link.
I hope to donate it soon, after some more testing....
bye bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
>Dear All,
>
>
...
>2. org.apache.cocoon.ProgrammaticInterface (or some such name):
>
The name of CocoonBean was proposed some time ago for the class with
such functionality.
> this would be a
>programmatic interface to running Cocoon. To start with, it would just give an Interface
>to the functionality currently provided within the Cocoon command line. So you could
>have code such as:
>
> ProgrammaticInterface cocoon = new ProgrammaticInterface();
> cocoon.setFollowLinks(true);
> cocoon.setLogLevel(DEBUG);
> cocoon.process();
>
>
There are two levels to Main.java functionality:
1. Process one request
2. Process multiple requests, using multiple starting URLs and/or
crawling.
You suggest implementing programmatic interface for 2nd level. I think
it is more important to have it for the 1st level. Example method can be:
cocoon.process(input, output);
Where input can be String - URL with Parameters (or Environment), and
output is OutputStream.
Vadim
...
>Before I start doing anything, I would like to check my proposal out with those on this
>list.
>
>Upayavira
>North London, UK
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] A little reworking of the Cocoon Command Line
Posted by Upayavira <uv...@upaya.co.uk>.
Vadim said:
> >I would suggest:
> >cocoon.processTargets();
>
> Or just process()
Fair enough.
> >to process multiple targets, including recursion, and:
> >cocoon.processPage(URI, outputStream);
>
> Or processURI or processRequest (it is not necessary page - it can be
> image or other resource).
Fair enough.
> Better yet something like: setEnvironment(new FTPDestination(...)).
> This way, CocoonBean does not depend on FTP, and File or RDBMS
> destinations could be implemented independently of Bean itself.
Sounds fair enough. Although, as an outsider, the Environment interface strikes me as a
bit complicated, and not something I'd like a user to need to understand (e.g. what is a
context, how do I split a URL into its constituent parts (can't the constructor do that for
me?), etc).
> I recommend to abstract destination from the Bean itself.
It appears that you recommend abstracting the destination from the Bean into the
Environment object. However, from what I can see, in the case of saving a file, it is
Main.java, that actually handles saving the file to disc, rather than the
FileSavingEnvironment object. How would you abstract out the destination from the
bean?
> In any case, if/when you get your Bean working, it can be added to the
> scratchpad and then it could be improved with the help and feedback of
> community.
When I'm ready, I'll find out how to do that.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org