Re: cvs commit: cocoon-2.1/src/blocks/javaflow/samples/forms form1.xml
Since the ojb and javaflow blocks are a bit unknown to me I would appreciate if somebody could cross-check these updates. regards, -marc= [EMAIL PROTECTED] wrote: mpo 2004/05/07 14:32:32 Modified:src/blocks/ojb/samples/forms success.xsp src/documentation/xdocs/userdocs/forms widget_row_action.xml src/blocks/javaflow/samples/forms form1.xml Log: Fixing some left-over references to the old getWidget() to the new lookupWidget() -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Stephan Michels wrote: Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [X] Move it into scratchpad [ ] Leave it where it is [ ] Rename it to ___ My opinion is to leave it where it is, because I heard too much the argument that flow is a great thing, but javascript?!. People already started to port the flow stuff for example to Struts, see http://www.rollerweblogger.org/page/roller/20040327#jsp_control_flow_engine I think the java flow thing is too important to go with it into scratchpad. For example you could also use Groovy to implement your flow, because Groovy also produces Java classes. I done a lot of afford to make it work like the javascript implementation. So that it is only a choise, which language you prefer. Your work is really appreciated! But I'm curious about our opinions, Stephan Michels. I think we shouldn't ship Javaflow as block because this gives our user base the wrong impression. I'd like to see it in scratchpad and as soon as it is stable (community, technology) it should become part of Cocoon core. BTW, this is the reason why we have a separate scratchpad block! Speaking in Cocoon 2.2 (3.0) semantics, it should be IMO (as the different environments, the Javascript-Flowinterpreter, ...?) in the middle between blocks and core. Avoiding balkanization I'm -1 on other implementation than JS and Java in the Cocoon CVS. But this shouldn't prevent people to provide them or to provide e.g. Groovy examples somewhere else. But please not in our CVS ... things are complicated and messed up enough ... -- Reinhard
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Marc Portier wrote: (though what I'd really like to see is a more clean separation of stable/unstable blocks, possibly with a clear directory hierarchy (src/blocks/stable, src/blocks/unstable), a default commented out -1 on dir structure, cvs hastle would kinda prevent blocks of becoming stable, right? Right (how I wish that we would switch to Subversion anytime soon...). unstable.blocks.properties that Joe User *has* to read to compile such stuff and some more warning around... just an idea popping up: why not reverse the default exclude.block.XXX setting for the unstable ones? then people will need to enable those and thus be more explicitely confronted? That is the main purpose, yes. Could be enough as a first step. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Stephan Michels wrote: [ ] Move it into scratchpad [X] Leave it where it is [ ] Rename it to ___ my argumentation is primarily short-term/pragmatic: starting at two observations: 1/ this is cool stuff and as far as I can see the reactions just about everyone here is salivating and wants to interact with that code 2/ the block-unit is the only thing our current infrastructure is offering to efficiently and atomically snap in and out certain functionality Taking this pragmatic view I can't see but a lot of similarity between this block and a lot of others... IMHO, were this block will take us in the future is not the question here and now.. regards, -marc= My opinion is to leave it where it is, because I heard too much the argument that flow is a great thing, but javascript?!. People already started to port the flow stuff for example to Struts, see http://www.rollerweblogger.org/page/roller/20040327#jsp_control_flow_engine I think the java flow thing is too important to go with it into scratchpad. For example you could also use Groovy to implement your flow, because Groovy also produces Java classes. I done a lot of afford to make it work like the javascript implementation. So that it is only a choise, which language you prefer. But I'm curious about our opinions, Stephan Michels. -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Le 30 mars 04, à 10:20, Marc Portier a écrit : ...just an idea popping up: why not reverse the default exclude.block.XXX setting for the unstable ones? then people will need to enable those and thus be more explicitely confronted?... I like the idea, and it's easy to do as blocks.properties are generated from gump.xml. Problem is, this means shipping with many blocks disabled. I think this would warrant a notice at the top of the blocks with samples page, something like see blocks.properties for a list of all available blocks. -Bertrand
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Le 30 mars 04, à 09:45, Gianugo Rabellino a écrit : ...(though what I'd really like to see is a more clean separation of stable/unstable blocks, possibly with a clear directory hierarchy (src/blocks/stable, src/blocks/unstable), a default commented out unstable.blocks.properties that Joe User *has* to read to compile such stuff and some more warning around... Maybe just naming the block scratchpad-javaflow would do? This would avoid the mess of adding yet more stuff to the current scratchpad block, yet make it very clear what's going on. -Bertrand
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Gianugo Rabellino wrote: Stephan Michels wrote: Hey, no problem - Stephan already contacted me and I think we have sorted everything out - if there was something to sort out at all between us. Now, as I still think that a new block gives the wrong impression (which user really reads that it's alpha?) I would prefer the scratchpad. I suggested to Stephan to start a vote about the place (block or scratchpad) and the majority wins. So everyone is happy and we all can enjoy the spring sun. Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [+1] Leave it where it is [ ] Rename it to ___ (though what I'd really like to see is a more clean separation of stable/unstable blocks, possibly with a clear directory hierarchy (src/blocks/stable, src/blocks/unstable), a default commented out -1 on dir structure, cvs hastle would kinda prevent blocks of becoming stable, right? unstable.blocks.properties that Joe User *has* to read to compile such stuff and some more warning around... just an idea popping up: why not reverse the default exclude.block.XXX setting for the unstable ones? then people will need to enable those and thus be more explicitely confronted? -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [x] Leave it where it is [ ] Rename it to ___ Hiding anything in scratchpad does not help anything IMO. The block is marked unstable and this should give the right perception. scratchpad = big mess It's good for single classes try-outs where a block does not make sense. But blocks are much more structured - which is good IMO. cheers -- Torsten
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Bertrand Delacretaz wrote: Le 30 mars 04, à 10:20, Marc Portier a écrit : ...just an idea popping up: why not reverse the default exclude.block.XXX setting for the unstable ones? then people will need to enable those and thus be more explicitely confronted?... I like the idea, and it's easy to do as blocks.properties are generated from gump.xml. Problem is, this means shipping with many blocks disabled. I think this would warrant a notice at the top of the blocks with samples page, something like see blocks.properties for a list of all available blocks. Deal. In any case, though, having those blocks excluded by default might boost us to take the unstable tag out. Right now there is little or no practical advantage, but just add some and you'll see us lazy butts start to work. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Stephan Michels wrote:
snip/
Okay here another vote(and I wait more than 24h)
Move java into scratchpad?
[ ] Move it into scratchpad
[X] Leave it where it is
[ ] Rename it to ___
IMO, this is a very much expected feature that a lot of people are
waiting for.
It needs to be marked as experimental though, to prevent people using it
until it's fully mature (the feedback on samples shows that a bit time
is needed).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Am Di, den 30.03.2004 schrieb Marc Portier um 10:32: my argumentation is primarily short-term/pragmatic: starting at two observations: 1/ this is cool stuff and as far as I can see the reactions just about everyone here is salivating and wants to interact with that code Yes, seems so. And I'm glad about it. 2/ the block-unit is the only thing our current infrastructure is offering to efficiently and atomically snap in and out certain functionality Taking this pragmatic view I can't see but a lot of similarity between this block and a lot of others... I have the same view, the current block intrastructure is the only way to make the build modular. Move all things, which are unstable, in one scratchpad-block doesn't help anyone. I can see Carsten's POV, and understand the fear that we get too much block during the time. But I think it's more the time to talk about to cut the CVS repository into cocoon-blocks and cocoon-core, which means a really small and slim core with the components, which are nessecary for a bootstrap system. Perhaps this time with svn ;-) Stephan.
RE: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Gianugo Rabellino [EMAIL PROTECTED] writes: Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [+1] Leave it where it is [ ] Rename it to ___ (though what I'd really like to see is a more clean separation of stable/unstable blocks, possibly with a clear directory hierarchy (src/blocks/stable, src/blocks/unstable), a default commented out unstable.blocks.properties that Joe User *has* to read to compile such stuff and some more warning around... That seems to be more-or-less the real way to handle this: put it in a block, but have the block not included in the build by default. That way, someone new to Cocoon isn't going to stumble across it by accident. More-over if they've got to go into the blocks.properties file (don't see the need for an extra prosperities file?) to add the block back into Cocoon it is easy to have a big comment very visible that says experimental. IOW, by forcing the user to modify the properties file you make it obvious the block is experimental...
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
On Tue, Mar 30, 2004 at 08:16:32AM -0800, Christopher Oliver wrote: Stephan Michels wrote: Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [+1 ] Leave it where it is [ ] Rename it to ___ Chris --Tim Larson
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Christopher Oliver wrote: Stephan Michels wrote: Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [+1 ] Leave it where it is [ ] Rename it to ___ Vadim
Re: cvs commit: cocoon-2.1/src/blocks/javaflow
Hello? I thought someone said: [X] nah... put it somewhere else Which is more or less a -1 on committing it to our CVS. So, please, why did you ignore it? Votes are useless if you ignore some voices whether you like Their opinion or not. Perhaps I'm changing my mind - perhaps not. Carsten
Re: cvs commit: cocoon-2.1/src/blocks/javaflow
Am Mo, den 29.03.2004 schrieb [EMAIL PROTECTED] um 19:27: Hello? I thought someone said: [X] nah... put it somewhere else Which is more or less a -1 on committing it to our CVS. So, please, why did you ignore it? Ohh, sorry, I won't to. We got no answer, so I thought you changed your mind. Votes are useless if you ignore some voices whether you like Their opinion or not. Perhaps I'm changing my mind - perhaps not. Your opinion is very important for us, especially for me, because I think you are every valuable for Cocoon. To be honest, I was a bit disappointed of your opinion. Please accept my apology, Stephan Michels.
Re: cvs commit: cocoon-2.1/src/blocks/javaflow
Le 29 mars 04, à 20:19, Stephan Michels a écrit : Am Mo, den 29.03.2004 schrieb [EMAIL PROTECTED] um 19:27: Hello? I thought someone said: [X] nah... put it somewhere else Which is more or less a -1 on committing it to our CVS. So, please, why did you ignore it? ...Please accept my apology, Stephan Michels. IMHO some kind of action is needed on this: either keep the javaflow block as is, move it to the scratchpad or move it somewhere else. Stephan, I understand the public pressure and excitement prompted you to do the commit this (which is great: I'm as impatient as anyone to play with javaflow), but this has been done without taking Carsten's advice into account, which is not right. Could you clarify this with Carsten, or maybe restart a [VOTE] about where to put javaflow? I don't want to rain on anyone's party, what Torsten and Stephan are doing is just great, but let's not allow disagreements to put clouds in this blue sky (hey I'm in Spring mood ;-) -Bertrand
RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Bertrand Delacretaz wrote: IMHO some kind of action is needed on this: either keep the javaflow block as is, move it to the scratchpad or move it somewhere else. Stephan, I understand the public pressure and excitement prompted you to do the commit this (which is great: I'm as impatient as anyone to play with javaflow), but this has been done without taking Carsten's advice into account, which is not right. Could you clarify this with Carsten, or maybe restart a [VOTE] about where to put javaflow? I don't want to rain on anyone's party, what Torsten and Stephan are doing is just great, but let's not allow disagreements to put clouds in this blue sky (hey I'm in Spring mood ;-) Hey, no problem - Stephan already contacted me and I think we have sorted everything out - if there was something to sort out at all between us. Now, as I still think that a new block gives the wrong impression (which user really reads that it's alpha?) I would prefer the scratchpad. I suggested to Stephan to start a vote about the place (block or scratchpad) and the majority wins. So everyone is happy and we all can enjoy the spring sun. Carsten
Re: cvs commit: cocoon-2.1/src/blocks/javaflow
Le 30 mars 04, à 09:07, Carsten Ziegeler a écrit : ...Hey, no problem - Stephan already contacted me and I think we have sorted everything out - if there was something to sort out at all between us... Great, thanks guys! -Bertrand
RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Stephan Michels wrote: Your opinion is very important for us, especially for me, because I think you are every valuable for Cocoon. Oh, thanks! But if that's true or not: my vote/voice isn't more important than other ones. We are all equal (at least when it comes to votes :) ). To be honest, I was a bit disappointed of your opinion. Yes, I understand that, no problem. Please accept my apology, Stephan Michels. Accepted. Carsten
[VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Am Di, den 30.03.2004 schrieb Carsten Ziegeler um 09:07: Bertrand Delacretaz wrote: IMHO some kind of action is needed on this: either keep the javaflow block as is, move it to the scratchpad or move it somewhere else. Stephan, I understand the public pressure and excitement prompted you to do the commit this (which is great: I'm as impatient as anyone to play with javaflow), but this has been done without taking Carsten's advice into account, which is not right. Could you clarify this with Carsten, or maybe restart a [VOTE] about where to put javaflow? I don't want to rain on anyone's party, what Torsten and Stephan are doing is just great, but let's not allow disagreements to put clouds in this blue sky (hey I'm in Spring mood ;-) Hey, no problem - Stephan already contacted me and I think we have sorted everything out - if there was something to sort out at all between us. Now, as I still think that a new block gives the wrong impression (which user really reads that it's alpha?) I would prefer the scratchpad. I suggested to Stephan to start a vote about the place (block or scratchpad) and the majority wins. So everyone is happy and we all can enjoy the spring sun. Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [ ] Leave it where it is [ ] Rename it to ___ My opinion is to leave it where it is, because I heard too much the argument that flow is a great thing, but javascript?!. People already started to port the flow stuff for example to Struts, see http://www.rollerweblogger.org/page/roller/20040327#jsp_control_flow_engine I think the java flow thing is too important to go with it into scratchpad. For example you could also use Groovy to implement your flow, because Groovy also produces Java classes. I done a lot of afford to make it work like the javascript implementation. So that it is only a choise, which language you prefer. But I'm curious about our opinions, Stephan Michels.
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Le 30 mars 04, à 09:37, Stephan Michels a écrit : Move java into scratchpad? you mean javaflow for sure ;-) [ ] Move it into scratchpad [+1 ] Leave it where it is [ ] Rename it to ___ But I'd add very visible mentions of the experimental status of this block: on the samples page at least (haven't looked at it yet, there might be such mentions already). -Bertrand
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Stephan Michels wrote: Hey, no problem - Stephan already contacted me and I think we have sorted everything out - if there was something to sort out at all between us. Now, as I still think that a new block gives the wrong impression (which user really reads that it's alpha?) I would prefer the scratchpad. I suggested to Stephan to start a vote about the place (block or scratchpad) and the majority wins. So everyone is happy and we all can enjoy the spring sun. Thank you that you didn't take it wrong :) Okay here another vote(and I wait more than 24h) Move java into scratchpad? [ ] Move it into scratchpad [+1] Leave it where it is [ ] Rename it to ___ (though what I'd really like to see is a more clean separation of stable/unstable blocks, possibly with a clear directory hierarchy (src/blocks/stable, src/blocks/unstable), a default commented out unstable.blocks.properties that Joe User *has* to read to compile such stuff and some more warning around... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
Re: [VOTE] Move javaflow into scratchpad was RE: cvs commit: cocoon-2.1/src/blocks/javaflow
Stephan Michels wrote: [ ] Move it into scratchpad [X] Leave it where it is [ ] Rename it to ___ Ugo
