[FYI] xml.com article: Ten Favorite XForms engines
http://www.xml.com/lpt/a/2003/09/10/xforms.html Mozquito DENG (commercial and Flash-based) looks particularly impressive to me. -Bertrand
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 for both, welcome! David, you beat us again in proposing people who deserve it ;-) -Bertrand
Anteater tests (was Re: on better release and version management)
Bertrand Delacretaz [EMAIL PROTECTED] wrote: Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a écrit ...Would it be enough to extend our Anteater scripts (see Guido's mail) and add Anteater to our codebase and include it automatically to our build system? ... certainly a Good Thing it tests are not too hard to write - anteater tests things from the user's point of view which would make us very confident that things actually work. ...BTW, unfortunatly the latest Anteater release needs Java 1.4.x ... Not too big a problem IMHO, as tests will probably not be required to do a normal build. How about the following change to the build? Uncomment the anteater-tests and remove the dependency of the test target on the anteater-tests target, so that if you run 'build test' only the unit tests are run. To run the Anteater tests you have to run 'build anteater-tests'. This in turn has a dependency on the 'block-anteater-tests' target that copies all anteater tests (located in block/test/anteater) to 'build/test/anteater' where they are then executed. The anteater-tests target starts with a big attention message hinting to make sure the anteater.home property is correctly set. So we can see how Anteater usage develops and decide later whether to put Anteater into CVS. Guido
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Bertrand Delacretaz wrote: David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 for both, welcome! David, you beat us again in proposing people who deserve it ;-) :-) ... there are plenty more committed people out there for others to propose. --David
Re: Anteater tests
Le Jeudi, 11 sep 2003, à 08:41 Europe/Zurich, Guido Casper a écrit : ...How about the following change to the build? Uncomment the anteater-tests and remove the dependency of the test target on the anteater-tests target, so that if you run 'build test' only the unit tests are run. To run the Anteater tests you have to run 'build anteater-tests' I'd just add a warning to build test indicating that the anteater tests must be run separately. ..This in turn has a dependency on the 'block-anteater-tests' target that copies all anteater tests (located in block/test/anteater) to 'build/test/anteater' where they are then executed. The anteater-tests target starts with a big attention message hinting to make sure the anteater.home property is correctly set. So we can see how Anteater usage develops and decide later whether to put Anteater into CVS. Sounds good - make anteater tests fairly easy to run at first, then add anteater to CVS if people bite to it! - Bertrand
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley [EMAIL PROTECTED] wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 for both Guido
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. They have both been contributing lots of stuff and discussion on both cocoon-dev and cocoon-users since mid-2002. Here is my +1 for both. +1 Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. They have both been contributing lots of stuff and discussion on both cocoon-dev and cocoon-users since mid-2002. Here is my +1 for both. --David +1 Furthermore 2 really nice and (especially Antonio) compensational (is it the correct word?) guys. Joerg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Le Jeudi, 11 sep 2003, à 09:04 Europe/Zurich, Joerg Heinicke a écrit : Furthermore 2 really nice and (especially Antonio) compensational (is it the correct word?) guys. Totally agreed - it might be the correct word but I don't know it, could you explain? ;-) -Bertrand
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
to arbitrate between parties in community wars :-) Joerg Bertrand Delacretaz wrote: Le Jeudi, 11 sep 2003, à 09:04 Europe/Zurich, Joerg Heinicke a écrit : Furthermore 2 really nice and (especially Antonio) compensational (is it the correct word?) guys. Totally agreed - it might be the correct word but I don't know it, could you explain? ;-) -Bertrand -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
Re: Removing usage of LogKitManager / LogKitManagable
Joerg Heinicke wrote: Ok, with this change we should have satisfied Robert Simmons at the end. A day worthy of remembrance. Thanks, Peter! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
On Thu, 11 Sep 2003, David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 ... welcome, guys! Andrew. -- Andrew SavoryEmail: [EMAIL PROTECTED] Managing Director Tel: +44 (0)870 741 6658 Luminas Internet Applications Fax: +44 (0)700 598 1135 Orixo alliance: http://www.orixo.com/ Web:www.luminas.co.uk
RE: on better release and version management
On Wed, 2003-09-10 at 11:26, Reinhard Poetz wrote: From: Steven Noels snip/ 2) We need to break from the impasse of 2.1.1 vs 2.2 I suggested yesterday night that the reshuffling of docs that Carsten started really seems more apt for a 2.2 release. Also, the switch to Fortress and Real Blocks are destined towards that 2.2 release. I understand some Avalon peeps are glad to dive in and help us with that, which is great, but we should facilitate them. Yep, I have the same concerns. Some people want to start with a 2.2 CVS module right away, others seem more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to decide on this, since it's blocking progress. Carsten made a good proposal how we can continue having 3 repositories and how this can be done with only little code duplicating: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2 I'm +1 with his proposal - the reason is simple: Some people (and customers too!) asked me if we have gone crazy and how they can update Cocoon in the future without being alpha/beta-tester for 'real' blocks and Fortress. We *must* be able to maintain 2.1 without all new features like blocks and Fortress because IMNSHO these steps are to big for 2.1 and I'm -1 on the changes in the current repository. I'm also +1 for starting a new repository, but I don't like Carsten's proposal that much. I'd rather see the entire repository duplicated, and move all development effort to the 2.2 repository. Only bugfixes should be applied to the 2.1 repository, and occasional backports of new functionality if anyone wants to. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: on better release and version management
Le Jeudi, 11 sep 2003, à 11:33 Europe/Zurich, Bruno Dumon a écrit : I'd rather see the entire repository duplicated, and move all development effort to the 2.2 repository. Only bugfixes should be applied to the 2.1 repository, and occasional backports of new functionality if anyone wants to... +1 - if it is a new repository as opposed to branches, this is what makes the most sense IMHO. -Bertrand
RE: on better release and version management
From: Bruno Dumon Carsten made a good proposal how we can continue having 3 repositories and how this can be done with only little code duplicating: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2 I'm +1 with his proposal - the reason is simple: Some people (and customers too!) asked me if we have gone crazy and how they can update Cocoon in the future without being alpha/beta-tester for 'real' blocks and Fortress. We *must* be able to maintain 2.1 without all new features like blocks and Fortress because IMNSHO these steps are to big for 2.1 and I'm -1 on the changes in the current repository. I'm also +1 for starting a new repository, but I don't like Carsten's proposal that much. I'd rather see the entire repository duplicated, and move all development effort to the 2.2 repository. Only bugfixes should be applied to the 2.1 repository, and occasional backports of new functionality if anyone wants to. Let's look which new features are planned for the next time and when they will be ready for beta and for final release? - real blocks - virtual sitemap components - intercepted flowscript - use Fortress as container - Cocoon Forms (aka Woody) - Cocoon Portals (new portal block) IMO the first four items should be part of 2.2 but the two last items should be released earlier. Let's assume a szenario that the implementation of them takes very long (e.g. more than a year until we reach a stable version). Do you really want to wait with Cocoon Forms and Cocoon Portals such a long time (not to mention the many other blocks)? You can say now that you develop under 2.2 and you do occasional backports but IMO the problem is that e.g. Cocoon Forms is tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable branch! Additionally we get a great mess with all our blocks if they are duplicated, some are backported, some not and we developers have to do a lot of work twice, work which is not real fun. That's the reason why I'm +1 with Carstens proposal: - 2.1 repository containing all our blocks - 2.2 repository contains only the new stuff introduced by the first four points from above - the 2.2 build mechanism is 'clever' enough to get all sources from 2.1 that are missing What do you think? Reinhard
RE: on better release and version management
Reinhard Poetz dijo: From: Bruno Dumon Carsten made a good proposal how we can continue having 3 repositories and how this can be done with only little code duplicating: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2 I'm +1 with his proposal - the reason is simple: Some people (and customers too!) asked me if we have gone crazy and how they can update Cocoon in the future without being alpha/beta-tester for 'real' blocks and Fortress. We *must* be able to maintain 2.1 without all new features like blocks and Fortress because IMNSHO these steps are to big for 2.1 and I'm -1 on the changes in the current repository. I'm also +1 for starting a new repository, but I don't like Carsten's proposal that much. I'd rather see the entire repository duplicated, and move all development effort to the 2.2 repository. Only bugfixes should be applied to the 2.1 repository, and occasional backports of new functionality if anyone wants to. Let's look which new features are planned for the next time and when they will be ready for beta and for final release? - real blocks - virtual sitemap components - intercepted flowscript - use Fortress as container - Cocoon Forms (aka Woody) - Cocoon Portals (new portal block) IMO the first four items should be part of 2.2 but the two last items should be released earlier. Let's assume a szenario that the implementation of them takes very long (e.g. more than a year until we reach a stable version). Do you really want to wait with Cocoon Forms and Cocoon Portals such a long time (not to mention the many other blocks)? You can say now that you develop under 2.2 and you do occasional backports but IMO the problem is that e.g. Cocoon Forms is tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable branch! Additionally we get a great mess with all our blocks if they are duplicated, some are backported, some not and we developers have to do a lot of work twice, work which is not real fun. That's the reason why I'm +1 with Carstens proposal: - 2.1 repository containing all our blocks - 2.2 repository contains only the new stuff introduced by the first four points from above - the 2.2 build mechanism is 'clever' enough to get all sources from 2.1 that are missing What do you think? I think your proposal is OK. I was thinking for a while about this and for my point of view the 2.2 is a major relase (maybe it would be called 3.0). These 4 key points are a radical change of how we can see at cocoon. And as you pointed we can start the block construction and continue the improvement of the current 2.1 branch (in forms and portal) while starting a total new cocoon. Of course the user interface will be preserved the most. But from the internals these is really a great new shaking if the current code. Is this correct? Best Regards, Antonio Gallardo
RE: on better release and version management
From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Reinhard Poetz dijo: From: Bruno Dumon Carsten made a good proposal how we can continue having 3 repositories and how this can be done with only little code duplicating: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w= 2 I'm +1 with his proposal - the reason is simple: Some people (and customers too!) asked me if we have gone crazy and how they can update Cocoon in the future without being alpha/beta-tester for 'real' blocks and Fortress. We *must* be able to maintain 2.1 without all new features like blocks and Fortress because IMNSHO these steps are to big for 2.1 and I'm -1 on the changes in the current repository. I'm also +1 for starting a new repository, but I don't like Carsten's proposal that much. I'd rather see the entire repository duplicated, and move all development effort to the 2.2 repository. Only bugfixes should be applied to the 2.1 repository, and occasional backports of new functionality if anyone wants to. Let's look which new features are planned for the next time and when they will be ready for beta and for final release? - real blocks - virtual sitemap components - intercepted flowscript - use Fortress as container - Cocoon Forms (aka Woody) - Cocoon Portals (new portal block) IMO the first four items should be part of 2.2 but the two last items should be released earlier. Let's assume a szenario that the implementation of them takes very long (e.g. more than a year until we reach a stable version). Do you really want to wait with Cocoon Forms and Cocoon Portals such a long time (not to mention the many other blocks)? You can say now that you develop under 2.2 and you do occasional backports but IMO the problem is that e.g. Cocoon Forms is tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable branch! Additionally we get a great mess with all our blocks if they are duplicated, some are backported, some not and we developers have to do a lot of work twice, work which is not real fun. That's the reason why I'm +1 with Carstens proposal: - 2.1 repository containing all our blocks - 2.2 repository contains only the new stuff introduced by the first four points from above - the 2.2 build mechanism is 'clever' enough to get all sources from 2.1 that are missing What do you think? I think your proposal is OK. I was thinking for a while about this and for my point of view the 2.2 is a major relase (maybe it would be called 3.0). These 4 key points are a radical change of how we can see at cocoon. And as you pointed we can start the block construction and continue the improvement of the current 2.1 branch (in forms and portal) while starting a total new cocoon. Of course the user interface will be preserved the most. Yes, the external contracts (must) remain mainly stable: - the use of the sitemap and it's components - cocoon.xconf - hot to implement your custom components I think moving from 2.1 to 2.2(3.0) will not be more difficult (maybe easier) than moving from 2.0 to 2.1 which takes you a few hours. And IIUC the changes from the old to the new cocoon.xconf which is necessary for Fortress can be done automatically with a stylesheet. (This brings me to the point that we should publish which are our stable and external interfaces ...) But from the internals these is really a great new shaking if the current code. Is this correct? I expect this and that's the reason why I think that a stable 2.2 release will take some time (I think that's not a matter of a few months but much more) and why I like Carsten's proposal. Reinhard Best Regards, Antonio Gallardo
JX Template: setting attributes
I have already asked on users group with no response so I'm trying here : is there a way to set an attribute depending on xpath value? same in xslt would be : xsl:if test=model/property = 'abc' xsl:attribute name=selected/ xsl:if LG -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
RE: on better release and version management
On Thu, 2003-09-11 at 12:02, Reinhard Poetz wrote: From: Bruno Dumon Carsten made a good proposal how we can continue having 3 repositories and how this can be done with only little code duplicating: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2 I'm +1 with his proposal - the reason is simple: Some people (and customers too!) asked me if we have gone crazy and how they can update Cocoon in the future without being alpha/beta-tester for 'real' blocks and Fortress. We *must* be able to maintain 2.1 without all new features like blocks and Fortress because IMNSHO these steps are to big for 2.1 and I'm -1 on the changes in the current repository. I'm also +1 for starting a new repository, but I don't like Carsten's proposal that much. I'd rather see the entire repository duplicated, and move all development effort to the 2.2 repository. Only bugfixes should be applied to the 2.1 repository, and occasional backports of new functionality if anyone wants to. Let's look which new features are planned for the next time and when they will be ready for beta and for final release? - real blocks - virtual sitemap components - intercepted flowscript - use Fortress as container - Cocoon Forms (aka Woody) - Cocoon Portals (new portal block) IMO the first four items should be part of 2.2 but the two last items should be released earlier. Let's assume a szenario that the implementation of them takes very long (e.g. more than a year until we reach a stable version). Do you really want to wait with Cocoon Forms and Cocoon Portals such a long time (not to mention the many other blocks)? I expect Woody to also take another year or so before it can be considered stable (in terms of interfaces, not code). Fortress itself is already stable, and if all goes well its impact on Cocoon stability should be minimal. Real blocks will take some more time, though my impression is that it's mainly new stuff, and won't impact the stability of what we currently have that much. So people who want to get quick access to the latest and greatest will be able to use snapshots or milestone releases, just as before. But I get your point: it could be that e.g. Woody is finished halfway through 2.2 development. You can say now that you develop under 2.2 and you do occasional backports correction: I didn't say *I* will do occasional backports :-) These will only happen if someone's motivated to do so. but IMO the problem is that e.g. Cocoon Forms is tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable branch! You'll always have to test it on all releases that you make it available on, that's unavoidable. If you make a Windows app, you also have to test it on all different Windows releases. Additionally we get a great mess with all our blocks if they are duplicated, some are backported, some not and we developers have to do a lot of work twice, work which is not real fun. That's the reason why I'm +1 with Carstens proposal: - 2.1 repository containing all our blocks - 2.2 repository contains only the new stuff introduced by the first four points from above - the 2.2 build mechanism is 'clever' enough to get all sources from 2.1 that are missing What do you think? There's lots of value in that proposal, but some problems too. I see the 2.1.x releases as patch releases, which must be releasable on very short notice. (but maybe that's wrong in itself, and the 2.1.x.x releases should be patch releases). What if I want to do heavy development on a block that will make it unstable for a while? If it's then suddenly required to release a patch release, that block will be part of it in its unstable state. Another problem: what if in my block I want to make use of features only available in 2.2. Or what if we make backwards incompatible changes in Cocoon 2.2 that require some changes (even if only minimal) to some blocks (we don't have #ifdef's). A better solution might be to move the blocks to their own repository, give them their own release management, make each block define its own requirements in terms of required Cocoon version etc. But that will bring a whole lot of work with it too, and I'm not sure we really need that. Anyhow, lots of stuff to think about, though it'd be nice if we get some interim solution in the meantime so that we can get started on 2.2. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: on better release and version management
Reinhard Poetz wrote: I expect this and that's the reason why I think that a stable 2.2 release will take some time (I think that's not a matter of a few months but much more) and why I like Carsten's proposal. Grmbl. Bruno and I were just trying to argumentize against each other about both scenarios, and I'm stuck with a few issues that I would like the repository reshuffling see resolve. Here's some feelings (not facts) I want to share with this discussion: 1) There's a decent amount of (positive!) FUD about the new blocks. All in all, I don't think that the actual coding of the new classloading and block deployment architecture code is much more cumbersome that what Sylvain once did with the TreeProcessor, and Stefano did with the build system. Yes, it will take time, but it's just a matter of finding time, motivation and energy to do the job. We tend to discuss for a long time about such issues, possibly longer than the actual coding actually requires. In the end, it's about getting on with it, and someone (which we will be very grateful for) diving deep into it and resurfacing when it's done. Ditto with Fortress. I'm naively hoping that some F2F time during the GT will help in finding that energy, and getting some commitment from people who need to shift between for-pay and for-free work on a daily basis. 2) My main concern with all this restructuring is however release management, and the user-facing perspective of our community work. We need to arrive to a situation where blocks can be independently released from Cocoon core releases, so that people who feel a faster drive to work on specific features can get on with the job, without being demotivated by long periods of no releases due to one zillion dependencies. So maybe we should move all blocks code into a separate module, and establish an independent release schedule (at the whim of the actual block release manager) for them. 3) This brings us to the eternal discussion about the definition of core and non-core. Maybe, be splitting out block code from the main module, and actively trying to slim down the main one even more, we will end up with a better community sense of what can be considered 'core', and what should be consired a block. We could even consider the TraxTransformer a block on its own, if we restrict the core to the pipeline, caching, sitemap and flow machinery. We could envision a packaged stable build of Cocoon which includes the core and then some core blocks. The rest is developed and released on its own schedule, and can, given the dependency checking in the new blocks paradigm shift (yes, it's more about a shift of perception than actual rearchitecturing) be safely released outside the main release schedule. This is just a quick braindump of my current feelings about all this. Hopefully it can contribute positively to this recurring discussion. Ending on a filosophical note: in the end, we should be driven by hope, not by fear. If we manage to come up with a stable 2.1.2 release within some weeks, I'm pretty sure our users have plenty of new, stable releases to play with while we get our act together. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: on better release and version management
Reinhard Poetz wrote: From: Bruno Dumon Carsten made a good proposal how we can continue having 3 repositories and how this can be done with only little code duplicating: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2 I'm +1 with his proposal - the reason is simple: Some people (and customers too!) asked me if we have gone crazy and how they can update Cocoon in the future without being alpha/beta-tester for 'real' blocks and Fortress. We *must* be able to maintain 2.1 without all new features like blocks and Fortress because IMNSHO these steps are to big for 2.1 and I'm -1 on the changes in the current repository. I'm also +1 for starting a new repository, but I don't like Carsten's proposal that much. I'd rather see the entire repository duplicated, and move all development effort to the 2.2 repository. Only bugfixes should be applied to the 2.1 repository, and occasional backports of new functionality if anyone wants to. Let's look which new features are planned for the next time and when they will be ready for beta and for final release? - real blocks - virtual sitemap components - intercepted flowscript - use Fortress as container - Cocoon Forms (aka Woody) - Cocoon Portals (new portal block) IMO the first four items should be part of 2.2 but the two last items should be released earlier. Let's assume a szenario that the implementation of them takes very long (e.g. more than a year until we reach a stable version). Do you really want to wait with Cocoon Forms and Cocoon Portals such a long time (not to mention the many other blocks)? You can say now that you develop under 2.2 and you do occasional backports but IMO the problem is that e.g. Cocoon Forms is tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable branch! Additionally we get a great mess with all our blocks if they are duplicated, some are backported, some not and we developers have to do a lot of work twice, work which is not real fun. That's the reason why I'm +1 with Carstens proposal: - 2.1 repository containing all our blocks - 2.2 repository contains only the new stuff introduced by the first four points from above - the 2.2 build mechanism is 'clever' enough to get all sources from 2.1 that are missing I am undecided but something occurred to me in the shower this AM which made me wonder whether Carsten's proposal will work. As blocks evolve into real blocks, the changes will need to happen right in the src/blocks. Can we guarantee (or will it be too painful to ensure) that all changes will be back-compatible with 2.1? IOW, we will soon start having new configurations, etc. moving into the blocks source, possibly shuffling around of dir structure and probably deprecating some things currently necessary (like some of the configuration patching). Just thinking out loud... Geoff
Re: on better release and version management
Geoff Howard wrote: I am undecided but something occurred to me in the shower this AM which made me wonder whether Carsten's proposal will work. As blocks evolve into real blocks, the changes will need to happen right in the src/blocks. Can we guarantee (or will it be too painful to ensure) that all changes will be back-compatible with 2.1? IOW, we will soon start having new configurations, etc. moving into the blocks source, possibly shuffling around of dir structure and probably deprecating some things currently necessary (like some of the configuration patching). Just thinking out loud... Exactly, and also one of my concerns with Carsten's proposal. We can't demand backwards-compatibility from block developers, and if blocks are shared between version from inside the 2.1 workspace, this would be the case. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. They have both been contributing lots of stuff and discussion on both cocoon-dev and cocoon-users since mid-2002. +1 for both -- welcome! Geoff
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Joerg Heinicke wrote: ... Furthermore 2 really nice and (especially Antonio) compensational (is it the correct word?) guys. I've never heard of the word compensational but my interpretation of it would mean active or skilled in paying people. If Antonio is skilled at this, we should have voted him in long ago! ;) Geoff
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Geoff Howard dijo: Joerg Heinicke wrote: ... Furthermore 2 really nice and (especially Antonio) compensational (is it the correct word?) guys. I've never heard of the word compensational but my interpretation of it would mean active or skilled in paying people. If Antonio is skilled at this, we should have voted him in long ago! ;) lol. : Antonio Geoff
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
http://dict.tu-chemnitz.de/dings.cgi?lang=denoframes=0query=ausgleichendservice=optword=1optcase=1opterrors=0optpro=0self=1 or http://dict.leo.org/?search=ausgleichend Both know compensational. What's the correct word? Joerg Geoff Howard wrote: Joerg Heinicke wrote: Furthermore 2 really nice and (especially Antonio) compensational (is it the correct word?) guys. I've never heard of the word compensational but my interpretation of it would mean active or skilled in paying people. If Antonio is skilled at this, we should have voted him in long ago! ;) Geoff -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de
RE: on better release and version management
Hi Steven, Thank you very much for your answer. It opened my eyes in some respect (especially the point with positive FUD). I thought again about our goal and I found two of them: - make it possible to continue with 2.1.x releases - start ASAP with 2.2 without influencing 2.2 And the simplest solution (and probably the only that will work) is Bruno's. Find more comments in the answer to Bruno's posting. Best regards, Reinhard -Original Message- From: Steven Noels [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 1:39 PM To: [EMAIL PROTECTED] Subject: Re: on better release and version management Reinhard Poetz wrote: I expect this and that's the reason why I think that a stable 2.2 release will take some time (I think that's not a matter of a few months but much more) and why I like Carsten's proposal. Grmbl. Bruno and I were just trying to argumentize against each other about both scenarios, and I'm stuck with a few issues that I would like the repository reshuffling see resolve. Here's some feelings (not facts) I want to share with this discussion: 1) There's a decent amount of (positive!) FUD about the new blocks. All in all, I don't think that the actual coding of the new classloading and block deployment architecture code is much more cumbersome that what Sylvain once did with the TreeProcessor, and Stefano did with the build system. Yes, it will take time, but it's just a matter of finding time, motivation and energy to do the job. We tend to discuss for a long time about such issues, possibly longer than the actual coding actually requires. In the end, it's about getting on with it, and someone (which we will be very grateful for) diving deep into it and resurfacing when it's done. Ditto with Fortress. I'm naively hoping that some F2F time during the GT will help in finding that energy, and getting some commitment from people who need to shift between for-pay and for-free work on a daily basis. 2) My main concern with all this restructuring is however release management, and the user-facing perspective of our community work. We need to arrive to a situation where blocks can be independently released from Cocoon core releases, so that people who feel a faster drive to work on specific features can get on with the job, without being demotivated by long periods of no releases due to one zillion dependencies. So maybe we should move all blocks code into a separate module, and establish an independent release schedule (at the whim of the actual block release manager) for them. 3) This brings us to the eternal discussion about the definition of core and non-core. Maybe, be splitting out block code from the main module, and actively trying to slim down the main one even more, we will end up with a better community sense of what can be considered 'core', and what should be consired a block. We could even consider the TraxTransformer a block on its own, if we restrict the core to the pipeline, caching, sitemap and flow machinery. We could envision a packaged stable build of Cocoon which includes the core and then some core blocks. The rest is developed and released on its own schedule, and can, given the dependency checking in the new blocks paradigm shift (yes, it's more about a shift of perception than actual rearchitecturing) be safely released outside the main release schedule. This is just a quick braindump of my current feelings about all this. Hopefully it can contribute positively to this recurring discussion. Ending on a filosophical note: in the end, we should be driven by hope, not by fear. If we manage to come up with a stable 2.1.2 release within some weeks, I'm pretty sure our users have plenty of new, stable releases to play with while we get our act together. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: on better release and version management
From: Bruno Dumon [mailto:[EMAIL PROTECTED] snip/ I expect Woody to also take another year or so before it can be considered stable (in terms of interfaces, not code). ... that long? I expected it to be stable sooner (end of this year). What's open? (I already added this discussion point to http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon) Fortress itself is already stable, and if all goes well its impact on Cocoon stability should be minimal. I think so too. Real blocks will take some more time, though my impression is that it's mainly new stuff, and won't impact the stability of what we currently have that much. So people who want to get quick access to the latest and greatest will be able to use snapshots or milestone releases, just as before. But I get your point: it could be that e.g. Woody is finished halfway through 2.2 development. You can say now that you develop under 2.2 and you do occasional backports correction: I didn't say *I* will do occasional backports :-) These will only happen if someone's motivated to do so. but IMO the problem is that e.g. Cocoon Forms is tested with 2.2 but NOT with 2.1 and we say that 2.1 is our stable branch! You'll always have to test it on all releases that you make it available on, that's unavoidable. If you make a Windows app, you also have to test it on all different Windows releases. Yep, got your point. Additionally we get a great mess with all our blocks if they are duplicated, some are backported, some not and we developers have to do a lot of work twice, work which is not real fun. That's the reason why I'm +1 with Carstens proposal: - 2.1 repository containing all our blocks - 2.2 repository contains only the new stuff introduced by the first four points from above - the 2.2 build mechanism is 'clever' enough to get all sources from 2.1 that are missing What do you think? There's lots of value in that proposal, but some problems too. I see the 2.1.x releases as patch releases, which must be releasable on very short notice. (but maybe that's wrong in itself, and the 2.1.x.x releases should be patch releases). What if I want to do heavy development on a block that will make it unstable for a while? If it's then suddenly required to release a patch release, that block will be part of it in its unstable state. Another problem: what if in my block I want to make use of features only available in 2.2. Or what if we make backwards incompatible changes in Cocoon 2.2 that require some changes (even if only minimal) to some blocks (we don't have #ifdef's). Ok. We are back at the beginning of the discussion. I think all those points made Stefano to publish his blocks proposal. Only 'real' blocks will decouple block development from Cocoon development and that's the major point (at least for me) making worth all the efforts of discussion and implementation. A better solution might be to move the blocks to their own repository, give them their own release management, make each block define its own requirements in terms of required Cocoon version etc. But that will bring a whole lot of work with it too, and I'm not sure we really need that. Anyhow, lots of stuff to think about, though it'd be nice if we get some interim solution in the meantime so that we can get started on 2.2. Yep, this interims solution is necessary and after reading Geoff's and Steven's posts I changed my opinion because you are right that we can't force block developer's to be backward compatible. So what's our plan? From my POV it looks like: - create a 2.2 repository as copy (incl. history) of 2.1 including all the blocks (so if somebody changes 2.2 core in an incompatible way I see it if I monitor the changes of the block I'm interested in) - 2.1core only receives bug-fixes (like 2.0) - find consensus on What's Cocoon core? - find consensus on a road map (after we know where we want to go?) and having milestones and target dates (I know Cocoon is an OSS project and all those features and dates are never binding for anyone but we should give our user's a better overview about the project and when he/she can expect a new feature) - block developer's decide if they want to develop on 2.1 or 2.2 or when they want to switch - when the block implementation of 2.2 is useable we can think about how we continue developing our real blocks (AFAIK versioning is not a problem any more with real blocks) What do you think? Reinhard
[OT] when is software finished [was: Re: on better release and version management]
Reinhard Poetz wrote: From: Bruno Dumon [mailto:[EMAIL PROTECTED] snip/ I expect Woody to also take another year or so before it can be considered stable (in terms of interfaces, not code). ... that long? I expected it to be stable sooner (end of this year). What's open? (I already added this discussion point to http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon) On a lighter note: we have a running joke over here about when is software considered 'finished'. It can be because the community around it dies, or because the author considers it to be perfect, and not requiring any fixes, refactorings or feature additions anymore. The funny thing is that an author sometimes declares its child finished because the community has died. OTOH, 'ls', 'tar' or 'deltree' could well be considered finished software without any negative connotations. Oh well, this is all geek humor (which is another running joke around here [1]), which we all be glad to share with all of you on the 7th of October (hint hint ;-)) [1] Geek humor being the kind of humor that erupts from male IT professionals if they've spent too much time behind their terminals, thinking what they have been doing will effectively change the rotational direction of our green globe. Geek humor can have two side effects: 1) you make a joke of yourself, being aware of the fact that many other things in life can have much more effect on that rotation than the lines of code and email you have been creating during the day, or 2) others make fun of you since you, taking yourself to serious, passionately start to explain how much fun it would be to change the earth's rotation, just because you can. Continuously swapping both perspectives while working in an open source community caters for longer periods between burn-outs. :-D /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Joerg Heinicke wrote: http://dict.tu-chemnitz.de/dings.cgi?lang=denoframes=0query=ausgleichendservice=optword=1optcase=1opterrors=0optpro=0self=1 or http://dict.leo.org/?search=ausgleichend Both know compensational. What's the correct word? The word I would choose to use to express the quality of someone who to arbitrates between parties is 'harmonising'. They actively work to bring about harmony between people. From a Buddhist perspective, 'harmonising speech' is a quality that will build community, by bringing people together. I like the word 'harmonising' because it suggests that this is an activity that needs to be done continuously. You can always have more, or deeper, harmony. Hope that's not too off-topic! Regards, Upayavira
Re: Removing usage of LogKitManager / LogKitManagable
On Wed, 10 Sep 2003, Antonio Gallardo wrote: Peter Royal dijo: On Tuesday, September 9, 2003, at 03:30 PM, Joerg Heinicke wrote: Ok, done. The vote for the change was unambiguous. Please review my commits and change the code if necessary. Done. your changes mirrored mine for the most part, and I just layered a few more on top (complete eviction of LogKitManager/able from the codebase) as well as allowing logging in CocoonServlet to be replaces by a subclass (so now a Log4JCocoonServlet should be pretty easy, if someone wants to do it). Thanks for the nice work. A questions: 1- Why we does not use log4J as the default logger? AFAIK Log4J is part of Apache and still is alive because is better than the included log mechanism introduced in J2SDK 1.4.x 2- What we can win or lose if we change. I understand the answer...once upon a time there was no logger and then there was LogKit.. You probably missed the recent thread about it. Have a look at http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=106206358807904w=2 -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Joerg Heinicke wrote: to arbitrate between parties in community wars :-) Hmm, mediators? I hope we don't have big enough problems that require mediation :) Joerg Tony
RE: on better release and version management
On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote: From: Bruno Dumon [mailto:[EMAIL PROTECTED] snip/ I expect Woody to also take another year or so before it can be considered stable (in terms of interfaces, not code). ... that long? I expected it to be stable sooner (end of this year). What's open? (I already added this discussion point to http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon) for one thing, there's all the stuff Sylvain's been proposing (namespaces mixing, expression language switch, various other things, I'll try to make a list before the hackaton). snip/ Anyhow, lots of stuff to think about, though it'd be nice if we get some interim solution in the meantime so that we can get started on 2.2. Yep, this interims solution is necessary and after reading Geoff's and Steven's posts I changed my opinion because you are right that we can't force block developer's to be backward compatible. So what's our plan? From my POV it looks like: - create a 2.2 repository as copy (incl. history) of 2.1 including all the blocks (so if somebody changes 2.2 core in an incompatible way I see it if I monitor the changes of the block I'm interested in) yep - 2.1core only receives bug-fixes (like 2.0) I'd judge that on a case-by-case basis, i.e. if someone wants to backport a new 2.2 core feature to 2.1, that they simply propose that on the list and if nobody disagrees, they can go ahead. - find consensus on What's Cocoon core? - find consensus on a road map (after we know where we want to go?) and having milestones and target dates (I know Cocoon is an OSS project and all those features and dates are never binding for anyone but we should give our user's a better overview about the project and when he/she can expect a new feature) - block developer's decide if they want to develop on 2.1 or 2.2 or when they want to switch hmm, I think that every change made to 2.1 should also be done to 2.2 (but not vice versa of course). It would be strange that 2.1 has features that are not in 2.2. - when the block implementation of 2.2 is useable we can think about how we continue developing our real blocks (AFAIK versioning is not a problem any more with real blocks) yep. What do you think? I think we're almost there. Lets wait a few more days to give others a chance to comment, and then launch a vote. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Joerg Heinicke wrote: http://dict.tu-chemnitz.de/dings.cgi?lang=denoframes=0query=ausgleichendservice=optword=1optcase=1opterrors=0optpro=0self=1 or http://dict.leo.org/?search=ausgleichend Both know compensational. What's the correct word? Geoff Howard wrote: Joerg Heinicke wrote: Furthermore 2 really nice and (especially Antonio) compensational (is it the correct word?) guys. I've never heard of the word compensational but my interpretation of it would mean active or skilled in paying people. If Antonio is skilled at this, we should have voted him in long ago! ;) Ah, didn't realize we were dealing with a specific translation issue for ausgleichend. The problem is that the English word compensate has two shades of meaning: to adjust for a missing quality, and to pay money or a money-equivalent. Probably the first of those does get at what you were trying to say but compensational is such a rare form that it would probably in practice lead to the humorous interpretation. Of the options on the sites you mentioned, balancing is probably the closest, but the others are probably on the right track using a totally different word. By the way, I hope my original comment didn't feel like I was poking fun -- I am continually impressed by you and so many others communicating in English and if we had to do these lists in any other language (even French which I used to speak pretty well) I'd be totally lost probably along with most of the other ugly americans. Geoff
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
On Thursday, September 11, 2003, at 06:38 AM, David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. They have both been contributing lots of stuff and discussion on both cocoon-dev and cocoon-users since mid-2002. Here is my +1 for both. --David Nice one Guys ! :) My +1 regards Jeremy
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Geoff Howard wrote: David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. They have both been contributing lots of stuff and discussion on both cocoon-dev and cocoon-users since mid-2002. +1 for both -- welcome! I'd just like to thank everybody for the votes, and especially David for the proposal. I was very surprised, pleased, humbled, and of course honored when I learned of David's plot to nominate me (And Antonio, welcome!) for committership. Truly a surprise. Anyway, if you're curious, I have a mini-bio up at http://wiki.cocoondev.org/Wiki.jsp?page=TonyCollen which has lived there for a while. I'd just like to add a little history, too. I originally joined the mailing lists as a result of a project at my old job, where one of the architects had suggested we use Cocoon for the frontend. It was a funny coincidence, because I had been exploring different technologies after being big into the PHP development side of things, and had somehow gravitated towards Cocoon. I lurked for quite a bit, but eventually I warmed up to posting regularly on the list -- it makes me wonder how many lurkers we have on this list :) In the past 9 months or so, circumstances had changed, and so did my job. I was heartbroken to learn that just as my skills in Cocoon were needed, I had to change jobs. Fortunately, the Cocooon community is always here regardless of what my job is, which is why I love contributing. Regards, Tony
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
Bruno Dumon wrote: On Wed, 2003-09-10 at 09:54, Sylvain Wallez wrote: Christopher Oliver wrote: BTW that flowscript code was written with the intention of supporting multi-page Woody forms with automated back/forward navigation as in JXForms. However, when I looked into implementing this I discovered that Woody forms cannot be presented in multiple pages because apparently the entire form is submitted with each request. As a result the fields that are not presented in the first page fail validation because they have no values. Or am I missing something? No, you got it right : Woody always validates the whole form. Yep, though it is possible to make a container widget that only delegates request processing and validation to a subset of its widgets, ie something like: wd:multipage id=something wd:page id=1 wd:field / wd:field / /wd:page wd:page id=2 wd:field / wd:field / /wd:page /wd:multipage depending on the value of some request parameter, the wd:multipage widget would only let a certain group of widgets process the request. Another approach to collecting data over multiple pages would simply be to create multiple (different) forms, which is of course already possible today. What's the best solution probably depends on the use case, I didn't felt the need yet for the first one. Unfortunately that makes the current integration of Woody with Flowscript close to useless. How would you propose to handle multi-page forms? Chris
RE: on better release and version management
From: Bruno Dumon On Thu, 2003-09-11 at 14:19, Reinhard Poetz wrote: From: Bruno Dumon [mailto:[EMAIL PROTECTED] snip/ I expect Woody to also take another year or so before it can be considered stable (in terms of interfaces, not code). ... that long? I expected it to be stable sooner (end of this year). What's open? (I already added this discussion point to http://wiki.cocoondev.org/Edit.jsp?page=GT2003Hackathon) for one thing, there's all the stuff Sylvain's been proposing (namespaces mixing, expression language switch, various other things, I'll try to make a list before the hackaton). Steven pointed out when he was writing about blocks that the implementation is NOT the problem if we have the design. I think that after the GT2003 we all will have a much better understanding where we want to go to with Woody and implementation will be done very soon. Then I would try to finalize (= find stable contracts) Woody ASAP and release it with 2.1.x. snip/ Anyhow, lots of stuff to think about, though it'd be nice if we get some interim solution in the meantime so that we can get started on 2.2. Yep, this interims solution is necessary and after reading Geoff's and Steven's posts I changed my opinion because you are right that we can't force block developer's to be backward compatible. So what's our plan? From my POV it looks like: - create a 2.2 repository as copy (incl. history) of 2.1 including all the blocks (so if somebody changes 2.2 core in an incompatible way I see it if I monitor the changes of the block I'm interested in) yep - 2.1core only receives bug-fixes (like 2.0) I'd judge that on a case-by-case basis, i.e. if someone wants to backport a new 2.2 core feature to 2.1, that they simply propose that on the list and if nobody disagrees, they can go ahead. +1 - find consensus on What's Cocoon core? - find consensus on a road map (after we know where we want to go?) and having milestones and target dates (I know Cocoon is an OSS project and all those features and dates are never binding for anyone but we should give our user's a better overview about the project and when he/she can expect a new feature) Maybe this is a point for the GT? Steven? - block developer's decide if they want to develop on 2.1 or 2.2 or when they want to switch hmm, I think that every change made to 2.1 should also be done to 2.2 (but not vice versa of course). It would be strange that 2.1 has features that are not in 2.2. Ok, then we develop all our things in 2.2; what I want to see is more backports from 2.2 to 2.1 than backports from 2.1 to 2.0. If we consider Woody as stable I would really like to see it backported to 2.1 if 2.2 is not ready for prime time. This time it shouldn't be too difficult because our internal interfaces will not change so much as from 2.1 to 2.0 - at least I hope so ;) Then we have to decide if we need for every backport (not bugfix) a vote or not. What do you think? - when the block implementation of 2.2 is useable we can think about how we continue developing our real blocks (AFAIK versioning is not a problem any more with real blocks) yep. What do you think? I think we're almost there. Lets wait a few more days to give others a chance to comment, and then launch a vote. fine, go ahead when you think it's time for it. Cheers, Reinhard
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
On Thu, 2003-09-11 at 19:38, Christopher Oliver wrote:
Bruno Dumon wrote:
On Wed, 2003-09-10 at 09:54, Sylvain Wallez wrote:
Christopher Oliver wrote:
BTW that flowscript code was written with the intention of supporting
multi-page Woody forms with automated back/forward navigation as in
JXForms. However, when I looked into implementing this I discovered
that Woody forms cannot be presented in multiple pages because
apparently the entire form is submitted with each request. As a
result the fields that are not presented in the first page fail
validation because they have no values. Or am I missing something?
No, you got it right : Woody always validates the whole form.
Yep, though it is possible to make a container widget that only
delegates request processing and validation to a subset of its widgets,
ie something like:
wd:multipage id=something
wd:page id=1
wd:field /
wd:field /
/wd:page
wd:page id=2
wd:field /
wd:field /
/wd:page
/wd:multipage
depending on the value of some request parameter, the wd:multipage
widget would only let a certain group of widgets process the request.
Another approach to collecting data over multiple pages would simply be
to create multiple (different) forms, which is of course already
possible today.
What's the best solution probably depends on the use case, I didn't felt
the need yet for the first one.
Unfortunately that makes the current integration of Woody with
Flowscript close to useless.
if you use the woody() function as entrance point, yes.
How would you propose to handle multi-page
forms?
Something like this:
function myfunc()
{
var form1 = new Form(formDefinition1);
var form2 = new Form(formDefinition2);
var form3 = new Form(formDefinition3);
form1.show(...);
form2.show(...);
form3.show(...);
}
and call the myfunc function from the sitemap.
Haven't tried this though (I'm using apples), but I think it should
work.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 A warm welcome to both of you. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Real blocks: some thoughts and questions
I've been reading through the most recent block related threads: Cocoon Blocks 1.1 [1] and Implementing Cocoon Blocks [2]. These two documents pretty much complement each other, the first mostly focussing on the blocks itself (not just a package but also inheritence and polymorphism), the second one more focussing on the block manager and block deployer. What I've written below are partly summaries and partly questions. I'm posting it here, if anyone can offer clarifications on some of this than that would be great, and otherwise it'll serve as input for the hackaton. = The main features that cocoon blocks have that are not in pure packaging solutions like war's are: * block dependencies, including polymorphism * block inheritence The first I quite understand, the second not so much. Dependencies between blocks --- If I got it right, the only dependencies we got between block are: - a block can use a component from another block (either a sitemap component or a generic Avalon component) - a block can call a pipeline described in the sitemap of another block, using the block: protocol Some things that would thus explicitely not be possible (at this point) are: - classloading dependencies: a block cannot depend on classes or jars inside another block - resource dependencies: one block cannot directly access files (such as XSL's) in other blocks - other sitemap dependencies: using flows, views or resources from a sitemap in another block. One exception is that the yet-to-come virtual sitemap components (or whatever they're called) could be used across blocks. Extending blocks (block inheritence) Reading the Cocoon Blocks 1.1 proposal [1] makes me think that block inheritance is a file-based thing, i.e. files not found in the extending block are taken from the extended block. Though in some other post in the discussion following on it, Stefano writes: Here, when a sitemap *extends* another one, it's means of falling back: the two sitemaps are appended and if no matching happens in the first one, it falls back on the extended one. Which implies that the extending is more dynamic, i.e. there exist two sitemap interpreters at runtime etc. Other than that I couldn't find much information on block inheritence, so if anyone can shed more light on it, that would be very welcome. Component lookup I'm wondering how component lookup will work. For example, suppose I have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll make my block depend on the fop blok (or the more generic cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer work? I assume I won't have to declare it in the map:components section of my sitemap anymore, since the instances of that serializer will be managed by the component manager of the fop block. So I'll just be able to write somewhere: map:serialize type=fo2pdf/ Now how will the component manager know which of the depended blocks to ask for this component? Check them one by one? Up to now all component managers are in a parent-child relationship, but blocks will need to use components from sibling blocks. Hope my explanation is clear enough. Hmm, now that I think of it, with the block: protocol there is explicit block addressing: block:dependencyname:/something. Probably we'll have something similar for component lookups? Other various stuff --- * I assume the block's sitemaps won't have a parent sitemap, i.e. the Cocoon root sitemap will not be the parent sitemap for block sitemaps. * Currently sitemap components are managed by a sitemap component manager. I assume that with blocks, sitemap components will also have to be mangeable by the main block component managers? I.e. the fop block won't have to include a sitemap simply to declare the the fo2pdf serializer. That's it for now. [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=103619609805268w=2 [2] http://marc.theaimsgroup.com/?t=10613459123r=1w=2 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
On Thu, 2003-09-11 at 07:38, David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 for both -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: on better release and version management
On Thu, 2003-09-11 at 19:47, Reinhard Poetz wrote: snip/ What do you think? I think we're almost there. Lets wait a few more days to give others a chance to comment, and then launch a vote. fine, go ahead when you think it's time for it. ok. I'm not here though next week, so if it depends on me it will be the week after that. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[RT] Woody dynamic widgets design
Proposal to allow the declarative specification of dynamic widgets in Woody:
(Use case that is driving dynamic widgets: web-based form and report design gui)
Bruno, if you have a chance could you comment on this before you are gone for the week?
Make the form definition dynamic:
Rely on aggregation, etc. to ensure all widget definitions are in the same source.
Create a container wd:widgets/ for reusable widget definitions.
Create wd:include/ to reference the reusable widget containers.
Create a new discriminated union widget with methods:
setCase(id) to change the distriminant and corresponding widgets.
getCase() to return the current discriminant id.
Sample form definition:
wd:form xmlns:wd=http://apache.org/cocoon/woody/definition/1.0;
wd:widgets id=fullname
wd:field id=firstname required=true
wd:datatype base=string/
wd:labelFirst Name/wd:label
/wd:field
wd:field id=middlename required=true
wd:datatype base=string/
wd:labelMiddle Name/wd:label
/wd:field
wd:field id=lastname required=true
wd:datatype base=string/
wd:labelLast Name/wd:label
/wd:field
/wd:widgets
wd:union id=name default=noname
wd:case id=noname/
wd:case id=nickname
wd:field id=nickname required=true
wd:datatype base=string/
wd:labelNickname/wd:label
/wd:field
/wd:case
wd:case id=fullname
wd:include id=fullname/
/wd:case
/wd:union
/wd:form
Make the form template dynamic:
Rely on aggregation, etc. to ensure all templates are in the same source.
This will allow support for recursively nested unions.
Create a container wt:templates/ for reusable templates.
Create wt:include/ to reference the reusable template containers.
Create wt:union/ to select templates based on the widget instance discriminants.
The context in wt:union/ is the contained widgets so recursively included
templates will reference the proper widgets. We would need to introduce
xpath-like syntax (e.g. /widget, ../widget, and widget/widget) to allow
other widgets to be referenced from templates contained in a union.
Sample form template:
page xmlns:wt=http://apache.org/cocoon/woody/template/1.0;
titleThe Title/title
content
wt:form-template action=#{$continuation/id}.continue method=POST
wt:templates id=fullname
wt:widget-label id=firstname/: wt:widget id=firstname/
wt:widget-label id=middlename/: wt:widget id=middlename/
wt:widget-label id=lastname/: wt:widget id=lastname/
/wt:templates
wt:union id=name
wt:case id=noname/
wt:case id=nickname
wt:widget-label id=nickname/: wt:widget id=nickname/
/wt:case
wt:case id=fullname
wt:include id=fullname/
/wt:case
/wt:union
input type=submit/
/wt:form-template
/content
/page
Make the binding dynamic:
I have not worked on this yet, but it will probably follow the same pattern
as the definitions and templates sections.
Make the flowscript support the dynamic widgets:
I will look at this next, along with the binding.
Well, that is the preliminary view. Before the design gets finished and coded,
what do others think of this? Am I on the right track? What could be done better?
--Tim Larson
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: [RT] Woody dynamic widgets design
On Thu, 2003-09-11 at 21:06, Timothy Larson wrote: Proposal to allow the declarative specification of dynamic widgets in Woody: (Use case that is driving dynamic widgets: web-based form and report design gui) Bruno, if you have a chance could you comment on this before you are gone for the week? Make the form definition dynamic: Rely on aggregation, etc. to ensure all widget definitions are in the same source. Create a container wd:widgets/ for reusable widget definitions. Create wd:include/ to reference the reusable widget containers. Create a new discriminated union widget with methods: setCase(id) to change the distriminant and corresponding widgets. getCase() to return the current discriminant id. a first quick reaction (the rest will be for tomorrow, have to leave now): what exactly should be understood here with dynamic? AFAIU the wd:union is a sort of switch which allows to programatically enable a set of widgets. However, I thought in earlier mails you were also implying to dynamically add new widgets (possibly with dynamically created widget definitions) to form instances. Or does the wd:union solve all your use-cases? (will then comment on the rest later on). -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. +1 for both, Welcome on board! -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Woody dynamic widgets design
--- Bruno Dumon [EMAIL PROTECTED] wrote: a first quick reaction (the rest will be for tomorrow, have to leave now): what exactly should be understood here with dynamic? AFAIU the wd:union is a sort of switch which allows to programatically enable a set of widgets. The wd:union switch can default to having no child widgets and later switch to various sets of child widgets. Constrained only by the list of cases in the union, you can dynamically decide which widgets to create and when to create them. If you keep choosing to create sets of widgets which include union widgets, then you are giving yourself the option grow the widget tree as large as you like. However, I thought in earlier mails you were also implying to dynamically add new widgets (possibly with dynamically created widget definitions) to form instances. Or does the wd:union solve all your use-cases? I prefer to direct processes with data instead of code because data is is easier to manipulate. The dynamically created widget definitions were intended as a shortcut before I came up with this design. BTW, the idea of reusing groups of widget and template definitions was inspired by Marc's comments on the xReporter list [1]. I hope I did not mangle his idea too much. (will then comment on the rest later on). Thanks. --Tim Larson [1] http://lists.cocoondev.org/cgi-bin/ezmlm-cgi.py?1:msp:701:200307:olglmgpjpkocdbgobele growing a more dynamic structure as would be required in this case will call for some advanced flow-handling IMHO (it should probably assemble itself out of smaller fixed portions with their own woody-form) __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
[Revote] Hammett for committer
Let's do this right this time. I would like to propose Hamilton Oliveira as a committer to the Avalon project. I think he has proven to have a desire to work with our existing vision, and demonstrates competency in development. I value his input, and I think he can make a good addition to the Avalon community. VOTE: [ ] +1 [ ] -1 -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
IGNORE! Re: [Revote] Hammett for committer
OOPS! Wrong list. My oppologies. Berin Loritsch wrote: Let's do this right this time. I would like to propose Hamilton Oliveira as a committer to the Avalon project. I think he has proven to have a desire to work with our existing vision, and demonstrates competency in development. I value his input, and I think he can make a good addition to the Avalon community. VOTE: [ ] +1 [ ] -1 -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
DO NOT REPLY [Bug 23118] New: - SearchGenerator incorrectly counts previous-index
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23118. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23118 SearchGenerator incorrectly counts previous-index Summary: SearchGenerator incorrectly counts previous-index Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] /search:results/search:navigation/@search:previous-index is incorrectly counted on ON LAST PAGE ONLY (meaning: when has-next=false AND has-prevoius=true) example: navigation total-count=25 count-of-pages=9 has-next=false has- previous=true next-index=25 previous-index=19 navigation-page start-index=0/ navigation-page start-index=3/ navigation-page start-index=6/ navigation-page start-index=9/ navigation-page start-index=12/ navigation-page start-index=15/ navigation-page start-index=18/ navigation-page start-index=21/ navigation-page start-index=24/ /navigation previous-index should be 21 here. This is bug rather for sure.
Re: [RT] Woody dynamic widgets design
On Thu, 2003-09-11 at 22:32, Timothy Larson wrote: --- Bruno Dumon [EMAIL PROTECTED] wrote: a first quick reaction (the rest will be for tomorrow, have to leave now): what exactly should be understood here with dynamic? AFAIU the wd:union is a sort of switch which allows to programatically enable a set of widgets. The wd:union switch can default to having no child widgets and later switch to various sets of child widgets. Constrained only by the list of cases in the union, you can dynamically decide which widgets to create and when to create them. If you keep choosing to create sets of widgets which include union widgets, then you are giving yourself the option grow the widget tree as large as you like. Aha, now I get it. It's much better than I thought ;-) And you're probably going to use this in combination with a repeater to get a repeating structure which can contain different sets of widgets on each row? However, I thought in earlier mails you were also implying to dynamically add new widgets (possibly with dynamically created widget definitions) to form instances. Or does the wd:union solve all your use-cases? I prefer to direct processes with data instead of code because data is is easier to manipulate. yep, and that's a good decission. After all, the woody form definition is a sort of schema language, and by doing things this way everything remains described in the schema. (this also gives woody form definitions similar power to xml schemas with their sequence/choice combo) The dynamically created widget definitions were intended as a shortcut before I came up with this design. BTW, the idea of reusing groups of widget and template definitions was inspired by Marc's comments on the xReporter list [1]. I hope I did not mangle his idea too much. That doesn't matter; I find it great how people sometimes come up with clever ideas by misunderstanding someone else suggestions. (though I don't know if that was the case here) To touch some of the other topics in your previous mail: * If I understand it right the wd:widgets/wd:include functionality is quite orthogonal to the wd:union proposal? I.e. the one does not really have to do with the other? (just to know that I understood it right) * On the aggregation: it would be nice if we could keep the current functionality of storing filename/linumber information on each node in the configuration DOM-tree, so that error messages can point to the exact source locations. This would require doing the aggregation on the DOM-tree rather than in a Cocoon pipeline. I'm willing to help out on this if needed. * on the xpath-addressing: could you give a concrete example of when it's needed? BTW, this is all very good stuff you're coming up with here! -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. They have both been contributing lots of stuff and discussion on both cocoon-dev and cocoon-users since mid-2002. Here is my +1 for both. Late +1 Vadim
Re: [Revote] Hammett for committer
Berin Loritsch wrote: Let's do this right this time. I would like to propose Hamilton Oliveira as a committer to the Avalon project. Ummm... Wrong list? Vadim
Re: Real blocks: some thoughts and questions
I'm thinking aloud -- not claiming I've got the right answers... Bruno Dumon wrote: I've been reading through the most recent block related threads: Cocoon Blocks 1.1 [1] and Implementing Cocoon Blocks [2]. These two documents pretty much complement each other, the first mostly focussing on the blocks itself (not just a package but also inheritence and polymorphism), the second one more focussing on the block manager and block deployer. What I've written below are partly summaries and partly questions. I'm posting it here, if anyone can offer clarifications on some of this than that would be great, and otherwise it'll serve as input for the hackaton. = The main features that cocoon blocks have that are not in pure packaging solutions like war's are: * block dependencies, including polymorphism * block inheritence I'd add what seems to be generalized block services. A block is dependent on another block's service, so maybe they just go hand in hand with dependencies. The definition of exactly what that service is seems very general. In some cases, a file resource. In some a true component. In come, pipelines or pipeline fragments. Maybe more. The first I quite understand, the second not so much. Dependencies between blocks --- If I got it right, the only dependencies we got between block are: - a block can use a component from another block (either a sitemap component or a generic Avalon component) - a block can call a pipeline described in the sitemap of another block, using the block: protocol See above -- I'm not sure this is all there is. Some things that would thus explicitely not be possible (at this point) are: - classloading dependencies: a block cannot depend on classes or jars inside another block I think that's right - no direct dependency on them. - resource dependencies: one block cannot directly access files (such as XSL's) in other blocks Not sure if that's true or not. - other sitemap dependencies: using flows, views or resources from a sitemap in another block. I don't know. One exception is that the yet-to-come virtual sitemap components (or whatever they're called) could be used across blocks. Extending blocks (block inheritence) Reading the Cocoon Blocks 1.1 proposal [1] makes me think that block inheritance is a file-based thing, i.e. files not found in the extending block are taken from the extended block. Though in some other post in the discussion following on it, Stefano writes: Here, when a sitemap *extends* another one, it's means of falling back: the two sitemaps are appended and if no matching happens in the first one, it falls back on the extended one. Which implies that the extending is more dynamic, i.e. there exist two sitemap interpreters at runtime etc. Other than that I couldn't find much information on block inheritence, so if anyone can shed more light on it, that would be very welcome. I interpret it to be service-based. A block exposes services which are interited/overridden by extending blocks. Component lookup I'm wondering how component lookup will work. For example, suppose I have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll make my block depend on the fop blok (or the more generic cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer work? I assume I won't have to declare it in the map:components section of my sitemap anymore, since the instances of that serializer will be managed by the component manager of the fop block. So I'll just be able to write somewhere: map:serialize type=fo2pdf/ I think you'd have to use the block: protocol as you mention below? Now how will the component manager know which of the depended blocks to ask for this component? Check them one by one? Up to now all component managers are in a parent-child relationship, but blocks will need to use components from sibling blocks. Hope my explanation is clear enough. The block descriptor (block.xml, yet to be fleshed out) declares what a block exposes. The deploy process wires the dependencies of one block to the exposed services of another. What your example brings up is the question: how does this work when services/resources are called from outside a block, as in a plain sitemap. Hmm, now that I think of it, with the block: protocol there is explicit block addressing: block:dependencyname:/something. Probably we'll have something similar for component lookups? That may answer the above question. Other various stuff --- * I assume the block's sitemaps won't have a parent sitemap, i.e. the Cocoon root sitemap will not be the parent sitemap for block sitemaps. I think that's right. The block mount-points get first crack at requests. They're more like super-sitemaps (not parents because the root sitemap won't inherit from them). * Currently sitemap components are managed by a sitemap
Re: JX Template: setting attributes
There's nothing similar in JXTemplate. For such cases, you have to duplicate the whole element in both parts of the condition. Leszek Gawron wrote: I have already asked on users group with no response so I'm trying here : is there a way to set an attribute depending on xpath value? same in xslt would be : xsl:if test=model/property = 'abc' xsl:attribute name=selected/ xsl:if LG
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
In that case, the Woody flowscript api needs to be refactored. I'll
start doing this. If anyone's using the existing one, plan on seeing
some changes.
Chris
Bruno Dumon wrote:
On Thu, 2003-09-11 at 19:38, Christopher Oliver wrote:
Bruno Dumon wrote:
On Wed, 2003-09-10 at 09:54, Sylvain Wallez wrote:
Christopher Oliver wrote:
BTW that flowscript code was written with the intention of supporting
multi-page Woody forms with automated back/forward navigation as in
JXForms. However, when I looked into implementing this I discovered
that Woody forms cannot be presented in multiple pages because
apparently the entire form is submitted with each request. As a
result the fields that are not presented in the first page fail
validation because they have no values. Or am I missing something?
No, you got it right : Woody always validates the whole form.
Yep, though it is possible to make a container widget that only
delegates request processing and validation to a subset of its widgets,
ie something like:
wd:multipage id=something
wd:page id=1
wd:field /
wd:field /
/wd:page
wd:page id=2
wd:field /
wd:field /
/wd:page
/wd:multipage
depending on the value of some request parameter, the wd:multipage
widget would only let a certain group of widgets process the request.
Another approach to collecting data over multiple pages would simply be
to create multiple (different) forms, which is of course already
possible today.
What's the best solution probably depends on the use case, I didn't felt
the need yet for the first one.
Unfortunately that makes the current integration of Woody with
Flowscript close to useless.
if you use the woody() function as entrance point, yes.
How would you propose to handle multi-page
forms?
Something like this:
function myfunc()
{
var form1 = new Form(formDefinition1);
var form2 = new Form(formDefinition2);
var form3 = new Form(formDefinition3);
form1.show(...);
form2.show(...);
form3.show(...);
}
and call the myfunc function from the sitemap.
Haven't tried this though (I'm using apples), but I think it should
work.
'build forrest' broken?
cocoon 2.1m3-dev Copyright (c) 1999-2003 Apache Software Foundation. All rights reserved. * [0] - [broken page] index.html - D:\tony\dev\cocoon-2.1\build\cocoon-2.1.2-dev\tmp\context\men u.xmap (The system cannot find the file specified) Total time: 0 minutes 5 seconds -- Static site generated at: D:\tony\dev\cocoon-2.1/build/cocoon-2.1.2-dev/site Please check the file D:\tony\dev\cocoon-2.1\build\cocoon-2.1.2-dev\tmp\brokenlinks.txt for any broken links in the generated site. -- Anyone else seeing this? Tony
Link Site: Cocoon Hosting.
Hi: While surfing on the net I found this site that sell cocoon hosting services... Anyone know about this company? Here is the link. http://www.eroute.net/plan2.htm If suggest to include them into: http://cocoon.apache.org/link/hosting.html I already sent a mail to them asking the version of cocoon they are hosting. I will post the answer. Best Regards, Antonio Gallardo
Re: [Vote] Antonio Gallardo and Tony Collen as Cocoon committers
Vadim Gritsenko wrote: David Crossley wrote: I propose Antonio Gallardo and Tony Collen to be Cocoon committers. They have both been contributing lots of stuff and discussion on both cocoon-dev and cocoon-users since mid-2002. Here is my +1 for both. Oh, and I forgot to say +1 earlier. Welcome! Upayavira
