Re: [Plan] The future of Cocoon

2004-06-14 Thread gounis
On Wed, 26 May 2004, Pier Fumagalli wrote: On 26 May 2004, at 10:17, Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) many people talking about deprecate XSP but can i ask something?

Re: [Plan] The future of Cocoon

2004-06-14 Thread Upayavira
[EMAIL PROTECTED] wrote: On Wed, 26 May 2004, Pier Fumagalli wrote: On 26 May 2004, at 10:17, Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) many people talking about deprecate

RE: [Plan] The future of Cocoon

2004-05-27 Thread Carsten Ziegeler
Pier Fumagalli wrote: On 26 May 2004, at 10:17, Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) - cleaning up the caching/store mess - remove deprecated blocks etc. I like it,

Re: [Plan] The future of Cocoon

2004-05-27 Thread Sylvain Wallez
Carsten Ziegeler wrote: Now as we have 2.1.5 out, I think we should talk about the future a little bit - we already have discussed several things in the past and I want to try to summarize things. First, I heard in the past complains from users at conferences where I presented Cocoon, that it's

RE: [Plan] The future of Cocoon

2004-05-27 Thread Carsten Ziegeler
Sylvain Wallez wrote: -1: XSP has been moved to its own block meaning it's no more core, but hundreds (if not thousands) or people are using it on a daily basis. We can drive people towards new techniques such as flow/jxtemplate, but cannot deprecate what's has been a central part of

Re: [Plan] The future of Cocoon

2004-05-27 Thread Sylvain Wallez
Ugo Cei wrote: Il giorno 26/mag/04, alle 11:17, Carsten Ziegeler ha scritto: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) - cleaning up the caching/store mess - remove deprecated blocks etc. - Differentiate

Re: [Plan] The future of Cocoon

2004-05-27 Thread Antonio Gallardo
Sylvain Wallez dijo: Personal note: your post made many people rush into my office saying What, what, deprecate XSP? He's crazy! ;-) lol. Just yesterday we had a little discussion about that in the office. We wonder why nobody commented about XSP deprecation! :-D We have 2 application running

Re: [Plan] The future of Cocoon

2004-05-27 Thread Sylvain Wallez
Antonio Gallardo wrote: Sylvain Wallez dijo: Personal note: your post made many people rush into my office saying What, what, deprecate XSP? He's crazy! ;-) lol. Just yesterday we had a little discussion about that in the office. We wonder why nobody commented about XSP deprecation! :-D We

RE: [Plan] The future of Cocoon

2004-05-27 Thread Carsten Ziegeler
Ah, btw, I added all points to a new document under planning/roadmap.xml. So, feel free to update that doc as well. Carsten -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 4:25 PM To: [EMAIL PROTECTED] Subject: Re: [Plan] The future

RE: [Plan] The future of Cocoon

2004-05-27 Thread Carsten Ziegeler
Antonio Gallardo wrote: lol. Just yesterday we had a little discussion about that in the office. We wonder why nobody commented about XSP deprecation! :-D Yepp, I did the same. Perhaps it's because most people only read the first two or three senctences of an email? :) We have 2

Re: [Plan] The future of Cocoon

2004-05-27 Thread Ugo Cei
Sylvain Wallez wrote: - Drop that Excalibur datasource. Components that need a DS should get one provided by the container via JNDI. If we don't have a container (running via the CLI, for instance), let the environment provide one and bind it to a JNDI namespace. Mmmhh... defining the JNDI

Re: [Plan] The future of Cocoon

2004-05-27 Thread Sylvain Wallez
Carsten Ziegeler wrote: Sylvain Wallez wrote: -1: XSP has been moved to its own block meaning it's no more core, but hundreds (if not thousands) or people are using it on a daily basis. We can drive people towards new techniques such as flow/jxtemplate, but cannot deprecate what's has been

Re: [Plan] The future of Cocoon

2004-05-27 Thread Pier Fumagalli
On 27 May 2004, at 11:05, Carsten Ziegeler wrote: Yes, I think we should wait for the switch (next monday I think it was) and then continue. Kewl by me... BTW, I looked around, but do we have a clear layout on how we're going to organize our SVN repository? Pier smime.p7s Description:

Re: [Plan] The future of Cocoon

2004-05-27 Thread Sylvain Wallez
Ugo Cei wrote: Sylvain Wallez wrote: - Drop that Excalibur datasource. Components that need a DS should get one provided by the container via JNDI. If we don't have a container (running via the CLI, for instance), let the environment provide one and bind it to a JNDI namespace. Mmmhh...

RE: [Plan] The future of Cocoon

2004-05-27 Thread Carsten Ziegeler
Yes, Nicola suggested: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108556233024477w=2 Carsten -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 4:50 PM To: [EMAIL PROTECTED] Subject: Re: [Plan] The future of Cocoon On 27 May

Re: [Plan] The future of Cocoon

2004-05-27 Thread Leszek Gawron
On Thu, May 27, 2004 at 04:54:54PM +0200, Sylvain Wallez wrote: Ugo Cei wrote: Sylvain Wallez wrote: - Drop that Excalibur datasource. Components that need a DS should get one provided by the container via JNDI. If we don't have a container (running via the CLI, for instance), let the

RE: [Plan] The future of Cocoon

2004-05-27 Thread Carsten Ziegeler
Sylvain Wallez wrote: Before envisionning the deprecation of XSP (which I'm currently against), we must ensure alternative technologies provide a similar level of performance and those of the XSP features that are clean from a MVC POV. Sure. We can only deprecate something if we have an

Re: [Plan] The future of Cocoon

2004-05-27 Thread Ugo Cei
Sylvain Wallez wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components Ouch! I had this need one and a half year ago [1] and couldn't satisfy it. Don't remember what I did and why it didn't work, and now that I have a solution, I

Re: [Plan] The future of Cocoon

2004-05-27 Thread Ugo Cei
Sylvain Wallez wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components Ouch! I had this need one and a half year ago [1] and couldn't satisfy it. Don't remember what I did and why it didn't work, and now that I have a solution,

RE: [Plan] The future of Cocoon

2004-05-27 Thread Carsten Ziegeler
Leszek Gawron wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components WOW SHIT ! :) Couldn't express it better. Right now I am also using Hibernate but at my XSP times when XConfToolTask was too much for me,

Re: [Plan] The future of Cocoon

2004-05-27 Thread Sylvain Wallez
Carsten Ziegeler wrote: Leszek Gawron wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components WOW SHIT ! :) Couldn't express it better. Right now I am also using Hibernate but at my XSP times when XConfToolTask was too much for

Re: [Plan] The future of Cocoon

2004-05-27 Thread Tim Larson
On Thu, May 27, 2004 at 07:40:19PM +0200, Sylvain Wallez wrote: Carsten Ziegeler wrote: Leszek Gawron wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components I just tried this and could not make it work :( Even tried

Re: [Plan] The future of Cocoon

2004-05-27 Thread Greg Weinger
Tim Larson wrote: We *can* make this officially but this requires a vote. For example, the new tree processor orginally written for 2.2 (using Fortress) did imho not support this. Don't know if it does support it now, but adding it would be IMO fairly easy. Now I'm all of course for

[Plan] The future of Cocoon

2004-05-26 Thread Carsten Ziegeler
Now as we have 2.1.5 out, I think we should talk about the future a little bit - we already have discussed several things in the past and I want to try to summarize things. First, I heard in the past complains from users at conferences where I presented Cocoon, that it's not identifiable what

Re: [Plan] The future of Cocoon

2004-05-26 Thread Leszek Gawron
Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) - cleaning up the caching/store mess - remove deprecated blocks etc. All request's named how should I implement that? finish at use flow + forms

Re: [Plan] The future of Cocoon

2004-05-26 Thread Ugo Cei
Il giorno 26/mag/04, alle 11:17, Carsten Ziegeler ha scritto: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) - cleaning up the caching/store mess - remove deprecated blocks etc. - Differentiate between blocks that