Christopher Oliver wrote:
Sorry to pick on Sylvain again, but he consistently exhibits a common
behavior of Java programmers with respect to JavaScript. Because JS
syntax is so similar to Java they seem to feel a JS API is somehow
better the more it resembles what it would look like if it was
Christopher Oliver wrote:
Sorry to pick on Sylvain again, but he consistently exhibits a common
behavior of Java programmers with respect to JavaScript. Because JS
syntax is so similar to Java they seem to feel a JS API is somehow
better the more it resembles what it would look like if it was
Sylvain Wallez wrote:
And that's what I call, maybe not adequately, inconsistencies.
Consider the JS wrapper for the request object. It has a remoteUser
property because of the request.getRemoteUser() method. Now what happens
if http://foo/bar?remoteUser=root; is called? Your application is
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
And that's what I call, maybe not adequately, inconsistencies.
Consider the JS wrapper for the request object. It has a remoteUser
property because of the request.getRemoteUser() method. Now what
happens if http://foo/bar?remoteUser=root; is called?
On Sun, 27 Feb 2005 14:16:23 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
snip /
This is actually similar to ServletRequest.getParameterMap() in servlet
2.4 which we do not have on our Request interface. But we should not
introduce special wrappers for Map as proposed recently by the
As an aside, I thought more about it and decided approach #1 was
better and less confusing so I switched Struts Flow to that. I still
believe the map wrapper provides value as it works great for quick
lookups and for..in usage. It also allows for the aforementioned
extensions like a length
Don Brown wrote:
On Sun, 27 Feb 2005 14:16:23 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
snip /
This is actually similar to ServletRequest.getParameterMap() in servlet
2.4 which we do not have on our Request interface. But we should not
introduce special wrappers for Map as proposed
On Sun, 27 Feb 2005 23:15:00 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
snip /
The simple fact that we have to elaborate such strategies IMO reveals
that there's a problem. This problem comes from the fact that a dynamic
property space (request parameters, map entries, etc) is merged with a
Sorry to pick on Sylvain again, but he consistently exhibits a common
behavior of Java programmers with respect to JavaScript. Because JS
syntax is so similar to Java they seem to feel a JS API is somehow
better the more it resembles what it would look like if it was written
in Java.
The
Antonio Gallardo wrote:
snip/
I found time to update the SVN version and an application that works fine
using the lastest SVN version seems to be broken.
I added 2 lines in javascript flow code for test:
cocoon.log.error(name= + cocoon.request.name);
cocoon.log.error(name= +
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I personally would remove this syntactic sugar completly; it's imho
not intuitiv what it means and the inconsistent implementation adds to
it.
In addition it would make our unified object model implementation (for
flow, jxtg etc.) much easier as we
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
I personally would remove this syntactic sugar completly; it's imho
not intuitiv what it means and the inconsistent implementation adds
to it.
In addition it would make our unified object model implementation
(for flow, jxtg
On Jue, 10 de Febrero de 2005, 7:51, Sylvain Wallez dijo:
oceatoon wrote:
Hmm... the problems is that cocoon.request.blah was released and
maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Now with all this deprecated stuff floating around, we should have a
centralized deprecation Logger so that users can easily be informed
of the deprecated features they use (in the case of Javascript,
there's no compiler warning like in Java).
Sylvain Wallez wrote:
Thinking further, I don't think we should attach this to the Cocoon
object as we may want to use this in classes also used outside the
Cocoon machinery.
Outside the Cocoon machinery? What do you mean by this?
So what about a dedicated o.a.c.util.Deprecation class?
Sylvain
Hmm... the problems is that cocoon.request.blah was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite natural ;) in a
users
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Thinking further, I don't think we should attach this to the Cocoon
object as we may want to use this in classes also used outside the
Cocoon machinery.
Outside the Cocoon machinery? What do you mean by this?
I mean not tied to a class that
oceatoon wrote:
Hmm... the problems is that cocoon.request.blah was released and maybe
is used is used (by us and other people?) in a lot of places and maybe
other peopl! :-(
Sorry for peecking into this post but till today I thought
cocoon.request.blah was a normal call, and seemed quite
Sylvain Wallez wrote:
I mean not tied to a class that provides other features than deprecation
logging. And the Cocoon class provides so much more ;-)
Hence the specific Deprecation class below, which will of course be in
the org.apache.cocoon package hierarchy.
Ok: +1 - I would choose a
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is that a special wrapper is
used for request, response and context that shows their
On Wed, 09 Feb 2005 16:05:26 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is
Peter Hunsberger wrote:
On Wed, 09 Feb 2005 16:05:26 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the
On Wed, 09 Feb 2005 16:32:28 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
snip/
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is that a special wrapper is
used for request, response and context that
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session are
now unrestricted.
The only difference with the real objects is that a special wrapper is
used for request, response and context
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session
are now unrestricted.
The only difference with the real objects is that a special wrapper
is used for
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session
are now unrestricted.
The only
Sylvain Wallez wrote:
Great! Why do we need this special wrapper?
Because removing it means a backwards incompatible change!
Sounds familiar ;)
It adds small syntactic sugar by allowing you to write
'cocoon.session.blah' instead of 'cocoon.session.getAttribute(blah)'
and the same on request and
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request, cocoon.response, cocoon.context and cocoon.session
are now
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
Furthermore, I really don't like this naming scope filled from different
sources (the object itself and some other data), especially when one of
the sources comes from the browser.
And what about conflicts? Fortunately the object is
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 12:06, Sylvain Wallez dijo:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi team,
Several months later, it's done (the vote started on 14-06-2004).
cocoon.request,
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
Furthermore, I really don't like this naming scope filled from
different sources (the object itself and some other data), especially
when one of the sources comes from the browser.
And what about conflicts?
Le 9 févr. 05, à 21:27, Carsten Ziegeler a écrit :
...Unfortunately, I fear that this is common use, so let's deprecate
it with 2.1.x and remove for 2.2 completly
+1
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Antonio Gallardo wrote:
On Mie, 9 de Febrero de 2005, 13:58, Sylvain Wallez dijo:
snip/
Oh f*ck, that's even worse than I thought. It now returns the request
*attributes* because I was fooled by the implementation of FOM_Request
which was buggy: getIds() which lists the object's properties was
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
Furthermore, I really don't like this naming scope filled from
different sources (the object itself and some other data), especially
when one of the sources comes from the browser.
And what
Carsten Ziegeler wrote:
I think this should be as simple as possible. What about a static
accessor, e.g. on the Core object?
I meant the Cocoon object here (we are talking about 2.1.x).
You might want to use this logger
where you don't want to either implement Serviceable nor
On 15 Jun 2004, at 18:04, Sylvain Wallez wrote:
Jeremy Quinn wrote:
snip/
Should I hold back on committing my changes to make ContextHelper
Contextualizable, to wait to see what comes out of this proposal ?
Wait a bit ;-)
You can still use the ContextAccess class in your own source tree,
Sylvain Wallez wrote:
Hi all,
More and more, the limitations of objects provided by the FOM seem
like arbitrary constraints that go in the way of people and produce
confusion. Furthermore, these restrictions only apply to the JS
flowscript and not to JavaFlow, thus making JS flowscript a second
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Hi all,
More and more, the limitations of objects provided by the FOM seem
like arbitrary constraints that go in the way of people and produce
confusion. Furthermore, these restrictions only apply to the JS
flowscript and not to JavaFlow, thus making
On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Hi all,
More and more, the limitations of objects provided by the FOM seem
like arbitrary constraints that go in the way of people and produce
confusion. Furthermore, these restrictions only apply to the
Jeremy Quinn wrote:
On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
snip/
Looking at the vote results, the general opinion is to remove the API
restrictions (got only +1's),
Good
but not tie the FOM to a particular Avalon object (got lots of +0's
and a -1).
This is more difficult to
On 15 Jun 2004, at 10:57, Sylvain Wallez wrote:
Jeremy Quinn wrote:
On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
snip/
Looking at the vote results, the general opinion is to remove the
API restrictions (got only +1's),
Good
but not tie the FOM to a particular Avalon object (got lots of +0's
On 15 Jun 2004, at 11:27, Jeremy Quinn wrote:
On 15 Jun 2004, at 10:57, Sylvain Wallez wrote:
Jeremy Quinn wrote:
On 15 Jun 2004, at 10:11, Sylvain Wallez wrote:
snip/
Looking at the vote results, the general opinion is to remove the
API restrictions (got only +1's),
Good
but not tie the FOM to
Jeremy Quinn wrote:
snip/
I made o.a.c.components.ContextHelper Contextualizable, and added the
getAvalonContext() method. It all compiles but is not tested from
FlowScript yet.
I have to get on with some other stuff right now, but hope to have
this tested and committed by this evening (unless
Sylvain Wallez wrote:
We already have cocoon.context, couldn't we make things
available from there?
Mmmh... don't know if it's a good idea, as the Cocoon core
currently doesn't rely on custom attributes in the
environment objects (unless I'm mistaken). This would
complexify
On 15 Jun 2004, at 15:57, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
We already have cocoon.context, couldn't we make things
available from there?
Mmmh... don't know if it's a good idea, as the Cocoon core
currently doesn't rely on custom attributes in the
environment objects (unless I'm
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
We already have cocoon.context, couldn't we make things available from there?
Mmmh... don't know if it's a good idea, as the Cocoon core currently doesn't rely on custom attributes in the environment objects (unless I'm mistaken). This would
Jeremy Quinn wrote:
snip/
Should I hold back on committing my changes to make ContextHelper
Contextualizable, to wait to see what comes out of this proposal ?
Wait a bit ;-)
You can still use the ContextAccess class in your own source tree, though.
BTW. I think there may be a related issue here
Jeremy Quinn wrote:
Currently these attributes are not really used.
Ah, I though these were the context attributes you could
access from FlowScript, as in:
cocoon.context.setAttribute (name, myObject); I have
used this before . when I needed to share the same object
On 15 Jun 2004, at 18:04, Sylvain Wallez wrote:
Jeremy Quinn wrote:
snip/
Should I hold back on committing my changes to make ContextHelper
Contextualizable, to wait to see what comes out of this proposal ?
Wait a bit ;-)
You can still use the ContextAccess class in your own source tree,
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Makes sense. And migrating some stuff to the env-context may
help removing some dependencies on Avalon. But whe have to be
very careful about what attributes we want to move from
avalon-context to env-context, and be sure they will still
make
Hi all,
More and more, the limitations of objects provided by the FOM seem like
arbitrary constraints that go in the way of people and produce
confusion. Furthermore, these restrictions only apply to the JS
flowscript and not to JavaFlow, thus making JS flowscript a second zone
citizen
+1 to remove restrictions on existing objects.
+1 to add cocoon.avalonContext.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Le 14 juin 04, à 12:01, Sylvain Wallez a écrit :
Please cast your votes!
- [ +1] to remove restrictions on existing objects.
- [ +1] to add cocoon.avalonContext.
-Bertrand
On 14.06.2004 12:01, Sylvain Wallez wrote:
That's why I propose to remove these restrictions my having
cocoon.request, cocoon.response and cocoon.context providing the full
API defined by the interfaces in org.apache.cocoon.environment.
Furthermore, I propose to add cocoon.avalonContext to
On 14 Jun 2004, at 11:01, Sylvain Wallez wrote:
Please cast your votes!
The ease with which it can be worked around (thanks Sylvain) and the
fact this is available to JavaFlow are good arguments IMHO.
- [ +1 ] to remove restrictions on existing objects.
- [ +1 ] to add cocoon.avalonContext.
Sylvain Wallez wrote:
- [ ] to remove restrictions on existing objects.
+1
- [ ] to add cocoon.avalonContext.
-1 for the name avalonContext. I think we should avoid references
to Avalon whereever possible. Otherwise perhaps we have to rename
it in the future.
So, +1 if a different name is
On 14 Jun 2004, at 12:11, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
- [ ] to remove restrictions on existing objects.
+1
- [ ] to add cocoon.avalonContext.
-1 for the name avalonContext. I think we should avoid references
to Avalon whereever possible. Otherwise perhaps we have to rename
it in
+1 to remove restrictions on existing objects.
+0 to add cocoon.avalonContext.
Sylvain Wallez wrote:
- [+1] to remove restrictions on existing objects.
- [+0] to add cocoon.avalonContext.
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
- [ ] to remove restrictions on existing objects.
+1
- [ ] to add cocoon.avalonContext.
-1 for the name avalonContext. I think we should avoid references to Avalon whereever possible. Otherwise perhaps we have to rename it in the
, couldn't we make things
available from there?
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Monday, June 14, 2004 2:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [VOTE] Unrestricting the FOM
Carsten Ziegeler wrote:
Sylvain Wallez wrote
Carsten Ziegeler wrote:
This context is a map containing key value pairs, it contains some global information (paths etc.) and e.g. the object model.
So even if we would move away from avalon we could have this map without breaking compatibility here. That's why I'm against avalonContext.
Ok, I
Joerg Heinicke wrote:
[+1] to remove restrictions on existing objects.
[+0] to add cocoon.avalonContext.
Joerg
Same here.
Tony
63 matches
Mail list logo
