Unico, Replying to your other mail too:
> As you all know, there are currently two ways that Cocoon resources > are published: either over http or generated on the command line. The > way we use Cocoon at Hippo seems to be something of a combination of > these two approaches: an http server running an instance of Cocoon > functions as a CMS for content editors and explicit publishing > commands trigger the exportation of resources to a separate live > server that hosts the actual site. I had thought of something similar myself too... > I was wondering about whether or not this would be something that is > genarally useful for Cocoon either as a block or core component set. > And if so I'd like to know what others think would be the best > approach to implement this. I currently see several different > possibilities. Let me know your ideas. I can immediately think of uses: 1. Have a single Cocoon site (e.g. hosted on a broadband connection, or in a companies office) that can publish to 'dumb' web servers. Would be extremely useful for 'poorer' organisations. 2. Have a single Cocoon site that 'syndicates' content to other 'dumb' web servers, by sending ready built HTML to them. One of my sites has a list of addresses that I would like to syndicate to a network of web sites (each paying around £60pa for hosting). Their webmasters are not that technical, so XML pull syndication will be beyond most of them, so sending them a new HTML everytime an address changes would be absolutely splendid. > One that we are using at the moment is that of a separate webservice > that creates custom Environments for each resource to be published and > passes it to Cocoon to process. The target can be a local filesystem > or an FTP server. The client interface to this webservice is very > simple but still rather coarse and experimental: the only parameters > are the url of the resource to start publishing at and a max-depth > parameter that is passed to a crawler. The webservice is configured to > map these urls to target locations so that the same system running > several different websites can publish these to separate locations. The new (m3) CocoonBean can itself write to ModifiableSources, so your web service wouldn't need to worry about delivering the file. If someone wrote an FTP source, then all you'd need to say is deliver this url /folder/page.html to this destination ftp://u:[EMAIL PROTECTED]/folder/, and off it goes. All the web service needs to do is create the CocoonBean instance and ask it to generate. > In order for me to adapt the code so as to make it most useful to > Cocoon there are several things I would need to decide on. One > concerns the way clients make publication requests. My current > thinking is to trigger the publication of resources by specifying > some special query parameter after the basic url, similar to the way > views are currently requested. Another question is how publication > targets are chosen. One way is to let the client name a pre-configured > publication target to publish to, another is to indicate this in the > sitemap, perhaps by providing suplemental information on a pipeline. Look at the code in the Cocoon bean. The Target class does offer different ways to help with the decision as to how the destinations are generated. It can cater for single files being generated, or for whole sites being spidered (even from one target). There's much that could be done on the bean iteself to extend its functionality - and this would make it more useful to Bean and to CLI users alike. I'd love to have someone helping me on it! Regards, Upayavira
