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
On Wednesday 14 December 2005 09:31, Sylvain Wallez wrote:
Both make very much sense.
Which means cleaning up the mess everywhere ;-);-)
Granted. I just wanted to say that for me, improvemets in either is good.
But that the discussion left out who is most important now, and if that is
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
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object, e.g. to get the sitemap
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
Leszek Gawron schrieb:
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object, e.g.
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
Daniel Fagerstrom wrote:
It seem like we all agree about that the Cocoon core need to be
simplified, although we have different opinions about how to achieve
it. IMO it can be done in steps by refactoring of the trunk.
One of the complications with Cocoon is the environment abstraction:
--- 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
Carsten Ziegeler skrev:
Leszek Gawron schrieb:
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the
Daniel Fagerstrom wrote:
Look, Cocoons current messiness depends on a large amount of small
things. If we not are able to improve these areas one at a time Cocoon
will stay as messy as it is.
Sure, but I really think messiness is a very hard work here. From a
users perspective (= the
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
It seem like we all agree about that the Cocoon core need to be
simplified, although we have different opinions about how to achieve
it. IMO it can be done in steps by refactoring of the trunk.
One of the complications with Cocoon is the
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
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Look, Cocoons current messiness depends on a large amount of small
things. If we not are able to improve these areas one at a time Cocoon
will stay as messy as it is.
Sure, but I really think messiness is a very hard work here.
I know,
Daniel Fagerstrom wrote:
The servlet set of apis is allready an abstraction, we have due to
historical circumstances another abstraction of the same concepts. To
me the abstractions look fairly similar, except for the Cocoon
aditions that have been mentioned. What am I missing more
Ralph Goers wrote:
Daniel Fagerstrom wrote:
The servlet set of apis is allready an abstraction, we have due to
historical circumstances another abstraction of the same concepts. To
me the abstractions look fairly similar, except for the Cocoon
aditions that have been mentioned. What am I
Carsten Ziegeler wrote:
Ralph Goers wrote:
Daniel Fagerstrom wrote:
The servlet set of apis is allready an abstraction, we have due to
historical circumstances another abstraction of the same concepts. To
me the abstractions look fairly similar, except for the Cocoon
aditions that
On 13.12.2005 22:20, Carsten Ziegeler wrote:
I have the feeling that changing this does not buy us something and that
does it not make life easier - I might be wrong though. Now, I still
think we should make the request/response objects more easily accessible
somehow.
+1 to both.
Jörg
Sylvain Wallez wrote:
Which makes actually two different abstractions for the same purpose,
and makes blocking the outputstream on our own abstraction useless, as
people can access it anyway.
It would be better IMO to have a single abstraction, but _control_ how
the outputstream is
Ralph Goers wrote:
Sylvain Wallez wrote:
Which makes actually two different abstractions for the same purpose,
and makes blocking the outputstream on our own abstraction useless,
as people can access it anyway.
It would be better IMO to have a single abstraction, but _control_
how the
Ralph Goers wrote:
Sylvain Wallez wrote:
Which makes actually two different abstractions for the same purpose,
and makes blocking the outputstream on our own abstraction useless,
as people can access it anyway.
It would be better IMO to have a single abstraction, but _control_
how the
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
On Wednesday 14 December 2005 04:12, Carsten Ziegeler wrote:
From a
users perspective (= the average Cocoon developer), most of the
messiness is hidden. She does not have to deal with how the tree
processor works, or with implementing an own pipeline etc. All these
interfaces and components
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 wrote:
On Wednesday 14 December 2005 04:12, Carsten Ziegeler wrote:
From a users perspective (= the average Cocoon developer), most of the
messiness is hidden. She does not have to deal with how the tree processor
works, or with implementing an own pipeline etc. All these
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
Sylvain Wallez wrote:
So my opinion about ditching our abstraction is that, as we say in
France, it is urgent to wait. Along with the backwards compatibility
problems that ditching the abstraction in 2.2 may lead to, we should see
if that common abstraction comes to life and then consider
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!!!
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object, e.g. to get the sitemap
prefix and sitemap uri and
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object, e.g. to get the sitemap
Berin Loritsch wrote:
Carsten Ziegeler wrote:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem. Anyways, our current Request object has more
functionality as the servlet request object,
Carsten Ziegeler skrev:
In general I agree with this - it makes learning Cocoon internal a
little bit easier. But I think the current environment api is not our
biggest problem.
We have had quite a few threads about our problems, so I'm not going to
try to find our biggest problem in this
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
It seem like we all agree about that the Cocoon core need to be
simplified, although we have different opinions about how to achieve it.
IMO it can be done in steps by refactoring of the trunk.
One of the complications with Cocoon is the environment abstraction:
o.a.c.environment.Request,
Il giorno 11/dic/05, alle ore 18:56, Daniel Fagerstrom ha scritto:
snip/
WDYT?
/Daniel
Know what? I proposed the same some time ago (I've tried digging out
the reference, but couldn't), so a big +1 from me.
Ugo
Daniel Fagerstrom wrote:
It seem like we all agree about that the Cocoon core need to be
simplified, although we have different opinions about how to achieve it.
IMO it can be done in steps by refactoring of the trunk.
One of the complications with Cocoon is the environment abstraction:
55 matches
Mail list logo
