Pier Fumagalli wrote:
Suggestions?On 30/1/03 9:09, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:Starting the blocks walk done with microchanges.Yeah! :-)microstep 1: loading of components from blocks -------------------------------------------------- goal ------ The goal is that if I specify: <map:blocks> <map:block name="batik"/> </map:blocks> then the sitemap processor will * look in WEB_INF/blocks for the block jars * load the batik-block.jar classes * load the avalon components therein specified in a cocoon.xconf file in the block jar Note: All other features like versioning, download (of the block and realted jars), etc will be another microstep.The only thing I have "against" this is to start thinking about making "WEB-INF" an optional feature (all throughout the code)... It should be a configurable feature. The "web application" concept collides with a "full-server" concept... Web-Applications were designed to allow multiple web-applications in the same container... With blocks, web applications are "redundant" (not to say, obsolete). Sooo, let's try to think about a possible non-web-application layout...
The fact is that cocoon.xconf was moved to WEB-INF for security reasons. In that servlet environment I would surely move the blocks under WEB-INF. IMHO it's simple enough to imagine that in all other environments we have a COCOON-INF dir that mimics the WEB_INF one.
It's not the build system, it's that cocoon.jar now needs that all Avalon components be inserted in a property file in cocoon.jar. This is why I want to do this microstep ;-)benefits ---------- No more need to recreate the cocoon.jar after the blocks build. This will make cocoon.jar really indipendent from the blocks.Shall we think about layering better the build system?
issues --------- Small step, but already there are issues. 1. when we will enable versioning, we can have that a block uses a version of some libraries, and others another. This mean that we have to load the blocks with different classloaders, right?Correct... And each classloader should work in the "web-application" mode: check _HERE_ first, and _THEN_ go to the parent classloader... It's not a big issue though, it could be a problem if we want to start "live reloading" of blocks, or pass instances of the same class around between different blocks...
yup, let's KISS for now.
2. Where does the treeprocessor actually create these components? ;-P It seems that methods are calling methods that are... you get the picture... I've got not much time to dwelve into that code, but I looked at the DefaultTreeBuilder.java, but still I'm puzzled. Can someone please help me and explain how Cocoon uses-handles the ComponentManager(s), and how the TreeProcessor works?On that, I can't help you mate, but once you figure something out, I can help you writing some code for it! :-)
Sylvain? (the Source ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
