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 l
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
document
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 implementat
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 t
-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 remo
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
Wid
-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
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 (us
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 de
-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
>> a
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 Com
-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/Data
12 matches
Mail list logo
