Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vadim Gritsenko wrote:
> I think it is related to the refactoring. Trunk fails to build now with:
>
> [INFO] Building Javaflow Block Samples
> [INFO]task-segment: [install]
> [INFO]
>
>
> [INFO] [enforcer:enforce-once {execution: enforce-maven}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 2 source files to
> /Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-javaflow/cocoon-javaflow-sample/target/classes
During the refactorings I've found sample classes in the cocoon-forms-impl
block which I've moved
to the cocoon-forms-sample block which IMHO they belong to. Thus the dependency
of the
javaflow-sample block was wrong (which you've already found and fixed, thanks
Vadim).
There could be more samples not migrated to new CForms behaviour wrt pring bean
vs. Avalon
Component handling but the code in CForms will make it clear if there are such
"old" constructs ;-)
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHAAgyLNdJvZjjVZARAgMcAKDsunFclopxHvVqEp10i5tx4TArRACeKBPA
UR6jcxC1Zs5ITdfvgdv9OBw=
=dUs5
-END PGP SIGNATURE-
Re: Springifying CForms
I think it is related to the refactoring. Trunk fails to build now with:
[INFO] Building Javaflow Block Samples
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 2 source files to
/Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-javaflow/cocoon-javaflow-sample/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/Users/vgritsenko/Projects/Apache/cocoon/blocks/cocoon-javaflow/cocoon-javaflow-sample/src/main/java/org/apache/cocoon/samples/flow/java/FormFlow.java:[28,39]
package org.apache.cocoon.forms.samples does not exist
Vadim
Re: Springifying CForms
Felix Knecht wrote:
Do you know why we have these extra directories at all instead of flat
block directory?
Just my 2 cents
Why do some blocks have 'super' poms including api/impl/sample and
others don't?
I've removed those extra POM level from all blocks that I have to release
because this would double my work. Since not all blocks have seen a release yet,
not all extra POMs are removed.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
> Do you know why we have these extra directories at all instead of flat > block directory? > Just my 2 cents Why do some blocks have 'super' poms including api/impl/sample and others don't? Felix > Vadim >
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vadim Gritsenko wrote: > Giacomo Pati wrote: >>> BTW: Do we create a branch of cocoon-form-(sample|impl) so that we >>> will have a new version for the >>> sprinigied blocks? >> >> As nobody commented on this I'll going to branch cocoon-form before I >> commit the sprinified CForms, >> as soon as Reinhard has finished releasing. Do I have to branch each >> block (cocoon-forms-impl and >> cocoon-forms-sample) individually or is branching their upper >> directory (cocoon-forms) enough? > > I'd guess branching upper directory is enough, with editing of trunk > POMs to set versions to the next one. Sure. > Do you know why we have these extra directories at all instead of flat > block directory? Probably because of structuring purpose grouping the impl/api/sample into its own directory, but this is just a guess. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG+6TLLNdJvZjjVZARAivOAJ0UyRctz7Znh2GY28YPXZuQbsNTxwCdEpz5 X1nVIkJtEZRbaCK2K2G4oUA= =czZS -END PGP SIGNATURE-
Re: Springifying CForms
Giacomo Pati wrote:
Reinhard Poetz wrote:
As nobody commented on this I'll going to branch cocoon-form before I
commit the sprinified CForms,
as soon as Reinhard has finished releasing. Do I have to branch each
block (cocoon-forms-impl and
cocoon-forms-sample) individually or is branching their upper
directory (cocoon-forms) enough?
I think branching the upper directoy is the way to go.
Ok, what is the status of the releasing? Will you give e the OK to branch and
commit CForms?
The creation of the release artifacts should be finished by the end of the day.
I will let you know when it's definitly done.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
Giacomo Pati wrote: BTW: Do we create a branch of cocoon-form-(sample|impl) so that we will have a new version for the sprinigied blocks? As nobody commented on this I'll going to branch cocoon-form before I commit the sprinified CForms, as soon as Reinhard has finished releasing. Do I have to branch each block (cocoon-forms-impl and cocoon-forms-sample) individually or is branching their upper directory (cocoon-forms) enough? I'd guess branching upper directory is enough, with editing of trunk POMs to set versions to the next one. Do you know why we have these extra directories at all instead of flat block directory? Vadim
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > >> As nobody commented on this I'll going to branch cocoon-form before I >> commit the sprinified CForms, >> as soon as Reinhard has finished releasing. Do I have to branch each >> block (cocoon-forms-impl and >> cocoon-forms-sample) individually or is branching their upper >> directory (cocoon-forms) enough? > > I think branching the upper directoy is the way to go. Ok, what is the status of the releasing? Will you give e the OK to branch and commit CForms? Thanks and ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG+6M6LNdJvZjjVZARAtz2AKCszdlbkbpBjE2Ni1biPEaTHtzarwCeKgQt zGOKhuHKiee4AhesuZx9Nys= =BfxR -END PGP SIGNATURE-
Re: Springifying CForms
Giacomo Pati wrote:
Giacomo Pati wrote:
Giacomo Pati wrote:
Hi all
If there is nobody working on the subject I'll spend a few hours on doing that.
I'm done with it :-) but need an advice on a special case:
There are some special 'custom' stuff which had been referenced in form
definitions/bindings by the
mentioned 'class' attribute which is now replaced by a 'ref' attribute and must
be a Spring bean.
Those classes were handled by LifecycleHelper as Avalon Components (which I've
eliminated in that
block). Those custom classes could have implemented the Avalon Configurable
interface to get access
to the XML snippet in the definition/binding file as a Avalon Configuration
object. So how should
that be handled now as they are all managed by Spring?
I have 2 possibilities:
a) check the custom class/bean whether it has a 'setConfiguration' method by
reflection and pass
the DOM snipped to it
b) extend the base interfaces (WidgetValidator, etc) to a ie.
ConfigurableWidgetValidator, etc.)
that has that setConfiguration method to pass the DOM snipped to.
As Felix was the only one giving oppinion about stuff above, I'll implement b)
which leads to 2 new
interfaces ATM to conform semantically to Avalonian CForm version:
My favorite is also b)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
As nobody commented on this I'll going to branch cocoon-form before I commit
the sprinified CForms,
as soon as Reinhard has finished releasing. Do I have to branch each block
(cocoon-forms-impl and
cocoon-forms-sample) individually or is branching their upper directory
(cocoon-forms) enough?
I think branching the upper directoy is the way to go.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giacomo Pati wrote: > > > Giacomo Pati wrote: >> Hi all > >> If there is nobody working on the subject I'll spend a few hours on doing >> that. > > I'm done with it :-) but need an advice on a special case: > > There are some special 'custom' stuff which had been referenced in form > definitions/bindings by the > mentioned 'class' attribute which is now replaced by a 'ref' attribute and > must be a Spring bean. > Those classes were handled by LifecycleHelper as Avalon Components (which > I've eliminated in that > block). Those custom classes could have implemented the Avalon Configurable > interface to get access > to the XML snippet in the definition/binding file as a Avalon Configuration > object. So how should > that be handled now as they are all managed by Spring? > > I have 2 possibilities: > > a) check the custom class/bean whether it has a 'setConfiguration' method by > reflection and pass >the DOM snipped to it > > b) extend the base interfaces (WidgetValidator, etc) to a ie. > ConfigurableWidgetValidator, etc.) >that has that setConfiguration method to pass the DOM snipped to. As Felix was the only one giving oppinion about stuff above, I'll implement b) which leads to 2 new interfaces ATM to conform semantically to Avalonian CForm version: ConfigurableWidgetListener extends WidgetListener and ConfigurableWidgetValidator extends WidgetValidator each having a method of: void setConfiguration(org.w3c.Element) throws Exception; > So, a) could be said being black magic, and b) could be said being > overdesigned. > > So I'd like you guys give your oppinions so that I can polish that last thing > up and commit. > > BTW: Do we create a branch of cocoon-form-(sample|impl) so that we will have > a new version for the > sprinigied blocks? As nobody commented on this I'll going to branch cocoon-form before I commit the sprinified CForms, as soon as Reinhard has finished releasing. Do I have to branch each block (cocoon-forms-impl and cocoon-forms-sample) individually or is branching their upper directory (cocoon-forms) enough? Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG+5+tLNdJvZjjVZARAsIrAKDSAUdNQEal4ZgkxMfM2LS6me7CxACggF2/ wCKMumfazsMP8dozC9qrpiA= =q534 -END PGP SIGNATURE-
Re: Springifying CForms
Giacomo Pati schrieb: > I'm done with it :-) Great, I'm looking forward to make my first experiences with it :-) > but need an advice on a special case: > > There are some special 'custom' stuff which had been referenced in form > definitions/bindings by the > mentioned 'class' attribute which is now replaced by a 'ref' attribute and > must be a Spring bean. > Those classes were handled by LifecycleHelper as Avalon Components (which > I've eliminated in that > block). Those custom classes could have implemented the Avalon Configurable > interface to get access > to the XML snippet in the definition/binding file as a Avalon Configuration > object. So how should > that be handled now as they are all managed by Spring? > > I have 2 possibilities: > > a) check the custom class/bean whether it has a 'setConfiguration' method by > reflection and pass >the DOM snipped to it > > b) extend the base interfaces (WidgetValidator, etc) to a ie. > ConfigurableWidgetValidator, etc.) >that has that setConfiguration method to pass the DOM snipped to. > > So, a) could be said being black magic, and b) could be said being > overdesigned. > I'd preferre b) because it's more obvious how to implement your own WidgetValidator when having a look at the JavaDocs Package API. You can see the 2 Interfaces what should make you more sensible about the difference/choice you have to make. With a) it'll be probably 'hidden' somewhere in the documentation and therefore less obvious how to implement your own WidgetValidator. Felix
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giacomo Pati wrote: > Hi all > > If there is nobody working on the subject I'll spend a few hours on doing > that. I'm done with it :-) but need an advice on a special case: There are some special 'custom' stuff which had been referenced in form definitions/bindings by the mentioned 'class' attribute which is now replaced by a 'ref' attribute and must be a Spring bean. Those classes were handled by LifecycleHelper as Avalon Components (which I've eliminated in that block). Those custom classes could have implemented the Avalon Configurable interface to get access to the XML snippet in the definition/binding file as a Avalon Configuration object. So how should that be handled now as they are all managed by Spring? I have 2 possibilities: a) check the custom class/bean whether it has a 'setConfiguration' method by reflection and pass the DOM snipped to it b) extend the base interfaces (WidgetValidator, etc) to a ie. ConfigurableWidgetValidator, etc.) that has that setConfiguration method to pass the DOM snipped to. So, a) could be said being black magic, and b) could be said being overdesigned. So I'd like you guys give your oppinions so that I can polish that last thing up and commit. BTW: Do we create a branch of cocoon-form-(sample|impl) so that we will have a new version for the sprinigied blocks? Ciao and TIA - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG+mW3LNdJvZjjVZARAk3BAKDqaKJ8GxzvBCIi9DedQnm8JKyx+ACeKJU7 kY17g6yZTMwAK6YPX3GbE7c= =GwWB -END PGP SIGNATURE-
Re: Springifying CForms: How to solve LifecycleHelper stuff
Daniel Fagerstrom pisze: > Giacomo Pati skrev: >> Daniel Fagerstrom wrote: >> >> >> I think we should vote on this, shouldn't we? > Probably. I think we should start to use lazy votes for this kind of > stuff. While we are Springifying and refactoring Cocoon there will > probably continue to be lots of stuff that we should vote about. But > ordinary votes are IMO to much administration for things that might be > of minor interest for most people anyway. +1 -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Springifying CForms: How to solve LifecycleHelper stuff
Giacomo Pati pisze: > > I think we should vote on this, shouldn't we? I absolutely dislike having the > LifecycleHelper (and > thus Avalon classes) staying in the CForms code. > > What do otehrs think about it? +1 for removing this stuff as long as it's released as 1.1.0 AND migration documentation is provided. I'm very strong on both points here. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Springifying CForms: How to solve LifecycleHelper stuff
Giacomo Pati skrev: Daniel Fagerstrom wrote: Giacomo Pati skrev: Daniel Fagerstrom wrote: Giacomo Pati skrev: Again, how should deprecation be implemented: a) use deprecation logger but keep current implementation b) throw an exception and remove current implementation a) is probably the correct solution, but at least I would prefer b). To me, the class attribute in forms for creating components seem like some hack or workaround that hopefully very few depends on. I think we should vote on this, shouldn't we? Probably. I think we should start to use lazy votes for this kind of stuff. While we are Springifying and refactoring Cocoon there will probably continue to be lots of stuff that we should vote about. But ordinary votes are IMO to much administration for things that might be of minor interest for most people anyway. I absolutely dislike having the LifecycleHelper (and thus Avalon classes) staying in the CForms code. What do otehrs think about it? +1, remove it. /Daniel
Re: Springifying CForms: How to solve LifecycleHelper stuff
Giacomo Pati wrote:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Again, how should deprecation be implemented:
a) use deprecation logger but keep current implementation
b) throw an exception and remove current implementation
a) is probably the correct solution, but at least I would prefer b). To
me, the class attribute in forms for creating components seem like some
hack or workaround that hopefully very few depends on.
I think we should vote on this, shouldn't we? I absolutely dislike having the
LifecycleHelper (and
thus Avalon classes) staying in the CForms code.
What do otehrs think about it?
I don't like them either. I would vote +1.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms: How to solve LifecycleHelper stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Fagerstrom wrote: > Giacomo Pati skrev: >> Daniel Fagerstrom wrote: >> >>> Giacomo Pati skrev: >> Again, how should deprecation be implemented: >> >> a) use deprecation logger but keep current implementation >> b) throw an exception and remove current implementation >> > a) is probably the correct solution, but at least I would prefer b). To > me, the class attribute in forms for creating components seem like some > hack or workaround that hopefully very few depends on. I think we should vote on this, shouldn't we? I absolutely dislike having the LifecycleHelper (and thus Avalon classes) staying in the CForms code. What do otehrs think about it? > >>> What I also would like to see, but it might be outside you current >>> scope, is to get rid of the selectors. I would prefer a solution where >>> maps with widgets, data types and so on are created with the bean-map >>> and these maps are injected into the form manager. >>> >> >> This is absolutely in my scope. I don't want to see those Avalon >> ServiceSelector again ;-) >> > Great! > > /Daniel > - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG7o/mLNdJvZjjVZARAgxwAJ47WQP+2xYv3zgyjQIXhLnB76a+MwCfag8w G87uWKj8/klmCw9UdOymVq8= =Domv -END PGP SIGNATURE-
Re: Springifying CForms: How to solve LifecycleHelper stuff
Giacomo Pati skrev: Daniel Fagerstrom wrote: Giacomo Pati skrev: Giacomo Pati wrote: Hi all If there is nobody working on the subject I'll spend a few hours on doing that. My general tactic would be to first rewrite the xconf/rules into a spring config so that adding new Widgets/Converters/Datatypes will than be easily manageable (using bean-maps) and than see how the classes have to be rewritten to follow that. Any better ideas? Now that I'm trying to do it I have some qustions about how we can manage LifecycleHelper stuff in a Spring context. In CForm definition files there are constructs that accepted a class attribute to denote a Java class being instantiated and managed as it where a Avalon Component (Validators, SelectionLists, and more). Whats the oppinion of other on this subject. Deprecate it. It should be enough to define beans in the Spring container and refer to them in the form definition. Again, how should deprecation be implemented: a) use deprecation logger but keep current implementation b) throw an exception and remove current implementation a) is probably the correct solution, but at least I would prefer b). To me, the class attribute in forms for creating components seem like some hack or workaround that hopefully very few depends on. What I also would like to see, but it might be outside you current scope, is to get rid of the selectors. I would prefer a solution where maps with widgets, data types and so on are created with the bean-map and these maps are injected into the form manager. This is absolutely in my scope. I don't want to see those Avalon ServiceSelector again ;-) Great! /Daniel
Re: Springifying CForms: How to solve LifecycleHelper stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Fagerstrom wrote: > Giacomo Pati skrev: >> Giacomo Pati wrote: >> >>> Hi all >>> >>> If there is nobody working on the subject I'll spend a few hours on >>> doing that. >>> >>> My general tactic would be to first rewrite the xconf/rules into a >>> spring config so that adding new >>> Widgets/Converters/Datatypes will than be easily manageable (using >>> bean-maps) and than see how the >>> classes have to be rewritten to follow that. >>> >>> Any better ideas? >>> >> >> Now that I'm trying to do it I have some qustions about how we can >> manage LifecycleHelper stuff in >> a Spring context. >> >> In CForm definition files there are constructs that accepted a class >> attribute to denote a Java >> class being instantiated and managed as it where a Avalon Component >> (Validators, SelectionLists, >> and more). Whats the oppinion of other on this subject. >> > Deprecate it. It should be enough to define beans in the Spring > container and refer to them in the form definition. Again, how should deprecation be implemented: a) use deprecation logger but keep current implementation b) throw an exception and remove current implementation > What I also would like to see, but it might be outside you current > scope, is to get rid of the selectors. I would prefer a solution where > maps with widgets, data types and so on are created with the bean-map > and these maps are injected into the form manager. This is absolutely in my scope. I don't want to see those Avalon ServiceSelector again ;-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG7otRLNdJvZjjVZARAilDAJ9tKF49BH+Q8AXrOpy7d1U09ZguPwCgtRYQ cM974YYtkLL2vbMna0j7g80= =3/SP -END PGP SIGNATURE-
Re: Springifying CForms: How to solve LifecycleHelper stuff
Giacomo Pati skrev: Giacomo Pati wrote: Hi all If there is nobody working on the subject I'll spend a few hours on doing that. My general tactic would be to first rewrite the xconf/rules into a spring config so that adding new Widgets/Converters/Datatypes will than be easily manageable (using bean-maps) and than see how the classes have to be rewritten to follow that. Any better ideas? Now that I'm trying to do it I have some qustions about how we can manage LifecycleHelper stuff in a Spring context. In CForm definition files there are constructs that accepted a class attribute to denote a Java class being instantiated and managed as it where a Avalon Component (Validators, SelectionLists, and more). Whats the oppinion of other on this subject. Deprecate it. It should be enough to define beans in the Spring container and refer to them in the form definition. What I also would like to see, but it might be outside you current scope, is to get rid of the selectors. I would prefer a solution where maps with widgets, data types and so on are created with the bean-map and these maps are injected into the form manager. /Daniel
Re: Springifying CForms: How to solve LifecycleHelper stuff
Giacomo Pati wrote: > > > Vadim Gritsenko wrote: >> Giacomo Pati wrote: >>> Now that I'm trying to do it I have some qustions about how we can >>> manage LifecycleHelper stuff in >>> a Spring context. >>> >>> In CForm definition files there are constructs that accepted a class >>> attribute to denote a Java >>> class being instantiated and managed as it where a Avalon Component >>> (Validators, SelectionLists, >>> and more). Whats the oppinion of other on this subject. >> 1. Implement @role attribute (aka bean reference) > > shouldn't it be @ref? > >> 2. Deprecate @class attribute > > How to deprecate? Leaving LifecycleHelper in the code or throwing exception > because we remove that > handling? > I think we should just remove this stuff and provide the above mentioned @ref configuration. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Springifying CForms: How to solve LifecycleHelper stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vadim Gritsenko wrote: > Giacomo Pati wrote: >> Now that I'm trying to do it I have some qustions about how we can >> manage LifecycleHelper stuff in >> a Spring context. >> >> In CForm definition files there are constructs that accepted a class >> attribute to denote a Java >> class being instantiated and managed as it where a Avalon Component >> (Validators, SelectionLists, >> and more). Whats the oppinion of other on this subject. > > 1. Implement @role attribute (aka bean reference) shouldn't it be @ref? > 2. Deprecate @class attribute How to deprecate? Leaving LifecycleHelper in the code or throwing exception because we remove that handling? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG7nrWLNdJvZjjVZARAg7qAJ9nKEM2UkmSz46LQTolSnLrY9sOBgCfQx1z HmZzSFR4Fc+buq2fG14AIeI= =/JZq -END PGP SIGNATURE-
Re: Springifying CForms: How to solve LifecycleHelper stuff
Giacomo Pati wrote: Now that I'm trying to do it I have some qustions about how we can manage LifecycleHelper stuff in a Spring context. In CForm definition files there are constructs that accepted a class attribute to denote a Java class being instantiated and managed as it where a Avalon Component (Validators, SelectionLists, and more). Whats the oppinion of other on this subject. 1. Implement @role attribute (aka bean reference) 2. Deprecate @class attribute I don't think there is a better way to handle this... Vadim
Re: Springifying CForms: How to solve LifecycleHelper stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giacomo Pati wrote: > Hi all > > If there is nobody working on the subject I'll spend a few hours on doing > that. > > My general tactic would be to first rewrite the xconf/rules into a spring > config so that adding new > Widgets/Converters/Datatypes will than be easily manageable (using bean-maps) > and than see how the > classes have to be rewritten to follow that. > > Any better ideas? Now that I'm trying to do it I have some qustions about how we can manage LifecycleHelper stuff in a Spring context. In CForm definition files there are constructs that accepted a class attribute to denote a Java class being instantiated and managed as it where a Avalon Component (Validators, SelectionLists, and more). Whats the oppinion of other on this subject. I'd like to get rid of LifecycleHelpre at all (it is already deprecated) but this will probably lead to incompatabilities with the old CForm. WDOT? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG7mfvLNdJvZjjVZARAtXmAKDXjXllUV6QzNYUtpn1a+UQWk6TnwCcCtLu uAzfDYdggRUkYsH3fPKV8sw= =8Y/u -END PGP SIGNATURE-
Re: Springifying CForms
Joerg Heinicke pisze: > On 14.09.2007 10:46 Uhr, Grzegorz Kossakowski wrote: > >> Speaking more generally I don't think that whiteboard is a good place. >> What I would like to see is: >> 1. You create branch (like cocoon-forms-1.0.X) in our branches folder >> 2. We release subsequent candidates for 1.0.0 from that branch and >> maintain it for reasonably short >> time making few 1.0.1, 1.0.2, ..., releases. >> 3. Meanwhile you (and others) can work on implementing new features in >> trunk and when all (or most) >> features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and >> continue work in trunk on 1.2.X >> our 2.0.0. > > We used to branch as less as possible. This means we branch lazily and > only when it is needed, not eagerly. Maybe we are never going to have > 1.0.1 etc. It should be possible to create a branch from any revision > later on - that was even possible with CVS. Branching in Subversion is just making a copy of directory. You can copy directory from any revision you like. I understand your argument about branching as less as possible especially when our tools do not support very easy synchronization of branches. However, I think making svn copy is not that hard to do and would ease releasing work. Branching is a way to make things more visible, it's easier to show when we are done with particular feature set and letting our code to switch into maintenance mode. One important thing is that I would like to have short living branches (let's say max 4-5 months) and more frequent releases that make transition between minor version changes smoother. If there is other solution than branching I'm eager to listen but branching now or later is secondary detail, IMO. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Springifying CForms
On 14.09.2007 10:46 Uhr, Grzegorz Kossakowski wrote: Speaking more generally I don't think that whiteboard is a good place. What I would like to see is: 1. You create branch (like cocoon-forms-1.0.X) in our branches folder 2. We release subsequent candidates for 1.0.0 from that branch and maintain it for reasonably short time making few 1.0.1, 1.0.2, ..., releases. 3. Meanwhile you (and others) can work on implementing new features in trunk and when all (or most) features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and continue work in trunk on 1.2.X our 2.0.0. We used to branch as less as possible. This means we branch lazily and only when it is needed, not eagerly. Maybe we are never going to have 1.0.1 etc. It should be possible to create a branch from any revision later on - that was even possible with CVS. Joerg
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > Giacomo Pati pisze: >> I don't think I can manage that until release date. > > Ok, so the problem is "sovled" partly. > >>> Since moving towards Spring is not trivial step I wouldn't like to see it >>> done for Forms 1.0.0 but >> I'm quite familiar with Spring _and_ Avalon > > I didn't have your skills in mind because I'm sure they are great. ;-) > What I did have was that it's not trivial change to Forms code and it would > be desirable to bump > version number. > >>> for 1.1.0. That raises natural question: do we want to branch Forms block? >>> I would be in favour of >>> such solution if there is no other one. >> I could copy it to whiteboard but have to sync it with changes in trunk by >> hand (without help of >> Eclipse) > > That's more problem with Subversion in general than with Eclipse, IMO. It's > said that Subversion 1.5 > will be having some improvements in that area. As for now I recommend use of > Subversive instead of > Subclipse. Despite few bugs in Subversive it has much better support for > multi-project commits, > merging, etc. > > Speaking more generally I don't think that whiteboard is a good place. What I > would like to see is: > 1. You create branch (like cocoon-forms-1.0.X) in our branches folder > 2. We release subsequent candidates for 1.0.0 from that branch and maintain > it for reasonably short > time making few 1.0.1, 1.0.2, ..., releases. > 3. Meanwhile you (and others) can work on implementing new features in trunk > and when all (or most) > features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and continue > work in trunk on 1.2.X > our 2.0.0. > > This would demand a little disciple from us but I think it's good way to have > releases on time and > enough freedom for innovation. > > WDYT? Sounds like a plan :-) > >>> I think your plan is good and I will be happy to help if there are some >>> problems as I have been >>> Springifying some code in Cocoon, already. I'm curious if you want to >>> completely move away from >>> Avalon and convert whole code not only configuration handling? >> Sure, completely. > > Great! > - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG6qFcLNdJvZjjVZARAvdiAKDZFL2Bl0ufKPaTe/NXbNS+rBoEWACguxng xEHvd8VMxM2sfvcfv+VaYro= =So1G -END PGP SIGNATURE-
Re: Springifying CForms
Giacomo Pati pisze: > > I don't think I can manage that until release date. Ok, so the problem is "sovled" partly. >> Since moving towards Spring is not trivial step I wouldn't like to see it >> done for Forms 1.0.0 but > > I'm quite familiar with Spring _and_ Avalon I didn't have your skills in mind because I'm sure they are great. ;-) What I did have was that it's not trivial change to Forms code and it would be desirable to bump version number. >> for 1.1.0. That raises natural question: do we want to branch Forms block? I >> would be in favour of >> such solution if there is no other one. > > I could copy it to whiteboard but have to sync it with changes in trunk by > hand (without help of > Eclipse) That's more problem with Subversion in general than with Eclipse, IMO. It's said that Subversion 1.5 will be having some improvements in that area. As for now I recommend use of Subversive instead of Subclipse. Despite few bugs in Subversive it has much better support for multi-project commits, merging, etc. Speaking more generally I don't think that whiteboard is a good place. What I would like to see is: 1. You create branch (like cocoon-forms-1.0.X) in our branches folder 2. We release subsequent candidates for 1.0.0 from that branch and maintain it for reasonably short time making few 1.0.1, 1.0.2, ..., releases. 3. Meanwhile you (and others) can work on implementing new features in trunk and when all (or most) features and bug fixes for 1.1.0 are in we branch it to 1.1.X, and continue work in trunk on 1.2.X our 2.0.0. This would demand a little disciple from us but I think it's good way to have releases on time and enough freedom for innovation. WDYT? >> I think your plan is good and I will be happy to help if there are some >> problems as I have been >> Springifying some code in Cocoon, already. I'm curious if you want to >> completely move away from >> Avalon and convert whole code not only configuration handling? > > Sure, completely. Great! -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > Giacomo Pati pisze: >> Hi all > > Hi Giacomo > >> If there is nobody working on the subject I'll spend a few hours on doing >> that. > > I'm very pleased to see that you want to work on this as it has been on my > wish-list for quite long > time. However, I'm not sure if you remember that we are going to have next > release in a week[1]. I > just realized that Reinhard omitted CForms on that list but I guess it was > just oversight. I don't think I can manage that until release date. > Since moving towards Spring is not trivial step I wouldn't like to see it > done for Forms 1.0.0 but I'm quite familiar with Spring _and_ Avalon > for 1.1.0. That raises natural question: do we want to branch Forms block? I > would be in favour of > such solution if there is no other one. I could copy it to whiteboard but have to sync it with changes in trunk by hand (without help of Eclipse) >> My general tactic would be to first rewrite the xconf/rules into a spring >> config so that adding new >> Widgets/Converters/Datatypes will than be easily manageable (using >> bean-maps) and than see how the >> classes have to be rewritten to follow that. >> >> Any better ideas? > > I think your plan is good and I will be happy to help if there are some > problems as I have been > Springifying some code in Cocoon, already. I'm curious if you want to > completely move away from > Avalon and convert whole code not only configuration handling? Sure, completely. > > [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74996 > - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG6plkLNdJvZjjVZARAng9AJwM19SivZka2XUWPkRR8jn3JMyx4wCfQ3uQ yHwE8uiNwovd2NimmBvnuNQ= =hPZF -END PGP SIGNATURE-
Re: Springifying CForms
Giacomo Pati pisze: > Hi all Hi Giacomo > If there is nobody working on the subject I'll spend a few hours on doing > that. I'm very pleased to see that you want to work on this as it has been on my wish-list for quite long time. However, I'm not sure if you remember that we are going to have next release in a week[1]. I just realized that Reinhard omitted CForms on that list but I guess it was just oversight. Since moving towards Spring is not trivial step I wouldn't like to see it done for Forms 1.0.0 but for 1.1.0. That raises natural question: do we want to branch Forms block? I would be in favour of such solution if there is no other one. > My general tactic would be to first rewrite the xconf/rules into a spring > config so that adding new > Widgets/Converters/Datatypes will than be easily manageable (using bean-maps) > and than see how the > classes have to be rewritten to follow that. > > Any better ideas? I think your plan is good and I will be happy to help if there are some problems as I have been Springifying some code in Cocoon, already. I'm curious if you want to completely move away from Avalon and convert whole code not only configuration handling? [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74996 -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all If there is nobody working on the subject I'll spend a few hours on doing that. My general tactic would be to first rewrite the xconf/rules into a spring config so that adding new Widgets/Converters/Datatypes will than be easily manageable (using bean-maps) and than see how the classes have to be rewritten to follow that. Any better ideas? Ciao - -- Otego AG Tel: +41 (0)44 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG6jCiLNdJvZjjVZARAjW9AJ919YKFGKy/Z/C93cE0SsR8QtR3uQCg6ZyQ aO+BAyjSofaw674K0IGHwYU= =VZZS -END PGP SIGNATURE-
