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?
[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
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,
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
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
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
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
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
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
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
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
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
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:
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...
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
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
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
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
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,
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,
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
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
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
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
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
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
26 matches
Mail list logo