Jorg Heymans wrote:
Ross Gardler wrote:
-1 over at Forrest one of our devs is experimenting with the Ajax block.
We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax
into the CForms block would prevent us from using it since we don't want
to bundle CForms for fear of
Antonio Gallardo wrote:
Also, please don't forget the ajax block. It is needed by forms. ;-)
Is ajax really a block on it's own ? I mean i know it can be plugged
into cforms to make forms ajax aware, but is it useable by other blocks
as well ? I'm not really uptodate with this stuff, just
Jorg Heymans wrote:
Antonio Gallardo wrote:
Also, please don't forget the ajax block. It is needed by forms. ;-)
Is ajax really a block on it's own ? I mean i know it can be plugged
into cforms to make forms ajax aware, but is it useable by other blocks
as well ? I'm not really uptodate
Ross Gardler wrote:
-1 over at Forrest one of our devs is experimenting with the Ajax block.
We have a demo in our forthcoming Dispatcher (aka views). Moving Ajax
into the CForms block would prevent us from using it since we don't want
to bundle CForms for fear of confusing the boundaries
Carsten Ziegeler wrote:
I strongly suggest that we start creating roadmaps. This also would make
the development of Cocoon for users much more transparent. Currently I
have only two points which I really think have to be finished for 2.2:
the build/deployment stuff and making the current
Jorg Heymans wrote:
Carsten Ziegeler wrote:
I strongly suggest that we start creating roadmaps. This also would make
the development of Cocoon for users much more transparent. Currently I
have only two points which I really think have to be finished for 2.2:
the build/deployment stuff
While I agree that it is OK to break compatibility to some degree
between 2.1 and 2.2, I think this is more of a change than I'd
really like to see between 2.1 and 2.2 as it will require
modifications to every Cocoon application.
Either we allow such required modifications or we need to
Jorg Heymans wrote:
snip/
Also: are we carrying forward all blocks to 2.2 or is this the time
where we ditch the obscure, rarely used and blocks that don't really
deserve to be a block blocks? I'ld say we choose the 10 most often used
and well known blocks and let the users voice their
Upayavira wrote:
For me, the absolute most important thing is getting the build working
again with the excalibur stuff. I'm here at ApacheCon with Maven chaps
around, and the easier it is for me to 'grok' the current Maven setup,
the more likely I am to be able to understand and explore
Daniel Fagerstrom wrote:
More seriously, it was an RT, I wanted to hear what people think and if
there was any problems that I hadn't thought about. I will of course
cast a vote before commiting anything. We could possibly provide some
optional back compability mode that puts the
--- Carsten Ziegeler [EMAIL PROTECTED] schrieb:
Daniel Fagerstrom wrote:
More seriously, it was an RT, I wanted to hear
what people think and if
there was any problems that I hadn't thought
about. I will of course
cast a vote before commiting anything. We could
possibly provide
Torsten Curdt wrote:
While I agree that it is OK to break compatibility to some degree
between 2.1 and 2.2, I think this is more of a change than I'd
really like to see between 2.1 and 2.2 as it will require
modifications to every Cocoon application.
Either we allow such required
Jorg Heymans skrev:
Carsten Ziegeler wrote:
I strongly suggest that we start creating roadmaps. This also would make
the development of Cocoon for users much more transparent. Currently I
have only two points which I really think have to be finished for 2.2:
the build/deployment stuff and
Upayavira skrev:
Jorg Heymans wrote:
snip/
Also: are we carrying forward all blocks to 2.2 or is this the time
where we ditch the obscure, rarely used and blocks that don't really
deserve to be a block blocks? I'ld say we choose the 10 most often used
and well known blocks and let the users
Reinhard Poetz skrev:
--- Carsten Ziegeler [EMAIL PROTECTED] schrieb:
Daniel Fagerstrom wrote:
More seriously, it was an RT, I wanted to hear
what people think and if
there was any problems that I hadn't thought
about. I will of course
cast a vote before commiting anything. We
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
That's a remarkable spirit ;o)
Just kidding...
I
Daniel Fagerstrom wrote:
Upayavira skrev:
I would also ask whether we should consider replacing the serializers in
core with those in the serializer block.
Better move the current core serializers to an own block. IMO we
should have a core that only contains the minimal infrastructure and
Upayavira wrote:
Jorg Heymans wrote:
snip/
Also: are we carrying forward all blocks to 2.2 or is this the time
where we ditch the obscure, rarely used and blocks that don't really
deserve to be a block blocks? I'ld say we choose the 10 most often used
and well known blocks and let the
Niclas Hedhman schrieb:
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
That's a remarkable
Niclas Hedhman wrote:
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
That's a remarkable spirit
Upayavira wrote:
I would also ask whether we should consider replacing the serializers in
core with those in the serializer block.
Why would you replace single class which works in 99% of cases with 4Mb of code?
Vadim
Vadim Gritsenko wrote:
Niclas Hedhman wrote:
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
Daniel Fagerstrom wrote:
And for me the most important question :) What is the suggested
timeframe/version for this? Do you want to do this for 2.2?
It depends on the timeframe for 2.2 ;) I will be offline for the next
two weeks (kitesurfing in Mexico :) ) after that I would like to ditch
the
Carsten Ziegeler wrote:
I strongly suggest that we start creating roadmaps. This also would make
the development of Cocoon for users much more transparent. Currently I
have only two points which I really think have to be finished for 2.2:
the build/deployment stuff and making the current
I agree that the main focus must be to get a 2.2 release. So the
question is what to do with the real blocks. They are currently rather
close to the specification, but we don't know if the specification is
good enough without getting experience from the blocks.
For ditching the environment
On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
I agree that the main focus must be to get a 2.2 release. So the
question is what to do with the real blocks. They are currently rather
close to the specification, but we don't know if the specification is
good enough without getting
Gianugo Rabellino wrote:
On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
I agree that the main focus must be to get a 2.2 release. So the
question is what to do with the real blocks. They are currently rather
close to the specification, but we don't know if the specification is
good
Gianugo Rabellino skrev:
On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
I agree that the main focus must be to get a 2.2 release. So the
question is what to do with the real blocks. They are currently rather
close to the specification, but we don't know if the specification is
good
Berin Loritsch skrev:
Gianugo Rabellino wrote:
On 12/13/05, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
I agree that the main focus must be to get a 2.2 release. So the
question is what to do with the real blocks. They are currently rather
close to the specification, but we don't know if
Gianugo Rabellino wrote:
I tend to disagree. The environment abstraction is to me part of the
underlying public contracts users rely upon: changing contracts
between minor versions is borderline but acceptable given the
cost/benefit ratio, but it's out of question between revision. Having
2.2
30 matches
Mail list logo
