Ok, thanks!
Bart.
-Oorspronkelijk bericht-
Van: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Verzonden: donderdag 12 mei 2005 19:04
Aan: dev@cocoon.apache.org
Onderwerp: Re: [CForms] having more control over showing/processing a
form
Bart Molenkamp wrote:
Well, I still have a
You are proposing to pollute the container session with a parasitic
attribute. Even if the Serialable issue of that wrapper object was
solved, that is still a -1 for me. Let's keep the session clean!
Cheers, Alfred.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Daniel Fagerstrom wrote:
[X] Go ahead and implement the environment extensions proposed above.
[ ] Implement the environment extensions but use the *Map() syntax instead.
[ ] Don't extend the environment.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software
Fine. Leave the WeakHashmap the way it is. But synchronizing on the
servlet session is a -1 for me. That could have unknown consequences
since the object is owned by the container, not Cocoon. See my other
post. Sorry - my ISP has had severe email problems the last few days
and so I have
One must synchonize the put and get operation on the map itself
in order to protect its internal consistency.
Map map = Collections.synchronizedMap(new HashMap());
...
map.put(key, value);
...
value = map.get(key);
is just easier to read than
Map map = new HashMap();
...
Nathaniel Alfred wrote:
One must synchonize the put and get operation on the map itself
in order to protect its internal consistency.
Well, yeah. A synchronized block that synchronizes on the map
accomplishes that.
Map map = Collections.synchronizedMap(new HashMap());
...
map.put(key,
Nathaniel Alfred wrote:
You must have synchronized(serverSession) (or block all threads) to
avoid calling sessions.put twice for the same serverSession.
Sorry. I misread that sentence. Yes, this statement is quite true.
Ralph
Daniel Fagerstrom wrote:
How above Request interface additions will relate to methods already
added to 2.2 interface:
Object getAttribute(String name, int scope);
Object searchAttribute(String name);
Enumeration getAttributeNames(int scope);
void setAttribute(String name,
On Friday 13 May 2005 13:27, Bertrand Delacretaz wrote:
Le 13 mai 05, à 07:19, Niclas Hedhman a écrit :
Can you explain this a bit further? Because I have no clue what you
think is
the actual problem.
I think Vadim sees a potential denial of service attack, if your system
allows one to
On Friday 13 May 2005 12:21, Vadim Gritsenko wrote:
Niclas Hedhman wrote:
The most accessible site we have done can be pre-viewed at
http://www.gensbol.dk/gallery/search.html (running Cocoon 2.1.6)
(Search a bird type, such as eagle, sparrow ant hit enter)
Layout seems broken in ff -
Ralph Goers Ralph.Goers at dslextreme.com writes:
Why is sessions a synchronized map if you are only accessing it in a
block synchronized on the session. I would much prefer that you
a) not use a synchronized map
b) synchronize on the map instead of the session.
Is there a reason that
Folks,
I've made a form without a submit widget, which resulted (after a while)
in a StackOverflowError... apparently the flow engine keep
auto-submitting the form over and over: is this a bug or is accepted
behaviour ?
Regards,
Luca Morandini
www.lucamorandini.it
This question has been asked on [EMAIL PROTECTED] some time ago but IIRC there was no
answer.
I have the need for a repeater that has one boolean field at each row. It should
only be possible to select one row. Usually the logical solution for this task
is using radio buttons but this
Upayavira wrote:
James Bates wrote:
The Cocoon command line interface provides a switch for simulating
the
Cocoon User-Agent header that would be sent by a browser. The idea
being
that it could be used by e.g. the browser selector to detect that
a
request is coming from the CLI.
Luca Morandini wrote:
I've made a form without a submit widget, which resulted (after a while)
in a StackOverflowError... apparently the flow engine keep
auto-submitting the form over and over: is this a bug or is accepted
behaviour ?
Hmm... seems the problem is more complex than just the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 May 2005, Daniel Fagerstrom wrote:
Please cast your votes:
[X] Go ahead and implement the environment extensions proposed above.
[ ] Implement the environment extensions but use the *Map() syntax instead.
[ ] Don't extend the environment.
-
Luca Morandini wrote:
Folks,
I've made a form without a submit widget, which resulted (after a
while) in a StackOverflowError... apparently the flow engine keep
auto-submitting the form over and over: is this a bug or is accepted
behaviour ?
Hmm... strange. A number of form samples have no
Upayavira wrote:
James Bates wrote:
The Cocoon command line interface provides a switch for simulating
the Cocoon User-Agent header that would be sent by a browser. The
idea being that it could be used by e.g. the browser selector to
detect that a request is coming from the CLI.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Freitag, 13. Mai 2005 08:57
To: dev@cocoon.apache.org
Subject: Re: svn commit: r169856 -
/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/environment/http/HttpRequest.java
You don't want to replace the
Reinhard Poetz wrote:
This question has been asked on [EMAIL PROTECTED] some time ago but IIRC
there was no answer.
I have the need for a repeater that has one boolean field at each row.
It should only be possible to select one row. Usually the logical
solution for this task is using radio
Niclas Hedhman wrote:
On Friday 13 May 2005 13:27, Bertrand Delacretaz wrote:
Le 13 mai 05, à 07:19, Niclas Hedhman a écrit :
Can you explain this a bit further? Because I have no clue what you
think is
the actual problem.
I think Vadim sees a potential denial of service attack, if your system
On 12 May 2005, at 17:21, Stefano Mazzocchi wrote:
But it's also true that editing xml files in a svn repository sucks as
an editing tool. Using wiki (or daisy or other solutions) is much
better.
I like the notion of
daisy - forrest - out
makes very good sense.
It does, yet there's obvious
Sylvain Wallez wrote:
Hmm... strange. A number of form samples have no explicit submit widget
and (seem to) work correctly.
Ahem... ashamed to say my flowscript auto-loaded itself (I was
cuttingpasting way too fast to notice), resulting in a really weird
behaviour: by chance it worked when I
Steven Noels wrote:
...
What do people think?
I think that we need people that write documentation, not a tool.
I'll think about it again when we have 10 doc writers sending patches
and files that we are not able to manage.
For now converting all documentation files to plain html and adding a
On Friday 13 May 2005 17:48, Upayavira wrote:
Does it have the 'don't enlarge' option that is in the current image
reader? That seems quite sensible to me.
No. But I'll add that to the feature list as well. No biggie at all.
The heavy use of photos in a couple of sites we have done, shows that
Luca Morandini wrote:
Sylvain Wallez wrote:
Hmm... strange. A number of form samples have no explicit submit
widget and (seem to) work correctly.
Ahem... ashamed to say my flowscript auto-loaded itself (I was
cuttingpasting way too fast to notice), resulting in a really weird
behaviour: by
Steven Noels wrote:
On 12 May 2005, at 17:21, Stefano Mazzocchi wrote:
But it's also true that editing xml files in a svn repository sucks
as an editing tool. Using wiki (or daisy or other solutions) is much
better.
I like the notion of
daisy - forrest - out
makes very good sense.
It does,
Nicola Ken Barozzi wrote:
Steven Noels wrote:
...
What do people think?
I think that we need people that write documentation, not a tool.
I'll think about it again when we have 10 doc writers sending patches
and files that we are not able to manage.
We'll never have 10 doc writers without tools
I did some tests and this is what I came up with:
The main problem seems to be that the browser is confused by empty
script / tags. This is easily fixed by something like:
script src=...
xsl:comment filler /xsl:comment
/script
in the CForms sample stylesheets.
Then you have to have HTML
On 13 May 2005, at 12:01, Nicola Ken Barozzi wrote:
Steven Noels wrote:
...
What do people think?
I think that we need people that write documentation, not a tool.
Of course, that's why I'm suggesting to take a look at the low-hanging
fruit.
I'll think about it again when we have 10 doc writers
Steven,
so the GT for users will be on the 11th Oct while the 10th is for the
community members?
Just to be sure which date I should preserve in my calendar as user
Regards,
Gunter D'Hondt
Steven Noels [EMAIL PROTECTED]
09/05/2005 09:53
Please respond to
users@cocoon.apache.org
To
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
snip/
How above Request interface additions will relate to methods already
added to 2.2 interface:
Object getAttribute(String name, int scope);
Object searchAttribute(String name);
Enumeration getAttributeNames(int scope);
void
On 13 May 2005, at 12:30, Sylvain Wallez wrote:
IMO the problem is more political or sentimental than technical.
Yes, and that's why I won't push. But I'm feeling our pain.
Note that I don't question the value of Daisy nor the good intentions
of you OT folks, but I want to point out the
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
More specifically I propose is that we extend
o.a.c.environment.Request with:
Map getAttributes();
Map getParameters();
Map getHeaders();
What about cookies? (There is Map getCookieMap() but naming
Sorry people; had some trouble subscribing to the mailing list; but
it's done now. Below is a svn patch against the BRANCH_2_1_X
development tree that changes the behaviour as described above...
Careful before committing: the code ALTERS the behaviour sothat any
existing implemenetations
Steven Noels wrote:
...
Again, I'm not pushing - consider me a dis-interested, yet friendly
party. I'm quite convinced though that documentation committers are
currently passively discouraged by the patch/mail mechanism.
Remember what started the Cocoon Wiki? Content (Leigh Dodds) + platform
Haven't used bugzilla before, but I'll try ;-)
-Original Message-
From: Torsten Curdt [mailto:[EMAIL PROTECTED]
Sent: 13 May 2005 12:49
To: dev@cocoon.apache.org
Subject: Re: User-Agent in Command-line interface
Sorry people; had some trouble subscribing to the mailing list; but
Daniel Fagerstrom wrote:
I missed that discussion. Anyway, IMO global request scope is nearly
never a good idea. As discussed in that thread, people are into an
unplesant suprise if they use global request scope for e.g. aggregation.
Furthermore one introduce quite strange dependencies in
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34906.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34906.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Ugo Cei wrote:
I did some tests and this is what I came up with:
The main problem seems to be that the browser is confused by empty
script / tags. This is easily fixed by something like:
script src=...
xsl:comment filler /xsl:comment
/script
in the CForms sample stylesheets.
Then you have to
Niclas Hedhman wrote:
On Friday 13 May 2005 13:27, Bertrand Delacretaz wrote:
Le 13 mai 05, à 07:19, Niclas Hedhman a écrit :
Can you explain this a bit further? Because I have no clue what you
think is the actual problem.
I think Vadim sees a potential denial of service attack, if your system
Il giorno 13/mag/05, alle 14:19, Sylvain Wallez ha scritto:
Why? Because it's too much work?
My impression is that once we have an xhtml-compliant CForms, it will
be easier to have it run on HTML browsers.
Because I'm worried about having to dive into Matt Kruse's JS code. I'm
no
On Friday 13 May 2005 20:21, Vadim Gritsenko wrote:
Niclas Hedhman wrote:
On Friday 13 May 2005 13:27, Bertrand Delacretaz wrote:
Le 13 mai 05, à 07:19, Niclas Hedhman a écrit :
Can you explain this a bit further? Because I have no clue what you
think is the actual problem.
I think Vadim
Sylvain Wallez wrote:
Template:
ft:repeater-widget id=items
...
input type=radio name=selected-row value=${repeaterLoop.index}/
/ft:repeater-widget
I don't think this will work in the template, does FormTemplateTransformer
supports this?
Vadim
Ugo Cei wrote:
Il giorno 13/mag/05, alle 14:19, Sylvain Wallez ha scritto:
Why? Because it's too much work?
My impression is that once we have an xhtml-compliant CForms, it will
be easier to have it run on HTML browsers.
Because I'm worried about having to dive into Matt Kruse's JS code.
I'm no
Joerg Heinicke wrote:
It would work, but IMO the current implementation is better because it is
more
fine-grained. Synchronizing the block on the map (yes, you don't need a
synchronized map then) blocks all requests for the execution of this block while
this impl blocks only the requests for the
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Template:
ft:repeater-widget id=items
...
input type=radio name=selected-row
value=${repeaterLoop.index}/
/ft:repeater-widget
I don't think this will work in the template, does
FormTemplateTransformer supports this?
Ah no, forgot to say:
Nathaniel Alfred wrote:
snip
Bottomline:
I think synchronized(session) should never be used as vehicle to
coordinate concurrent requests because there is no convincing guarantee
that it is always working as expected.
Thanks for doing more research. Although you put it much more clearly
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I missed that discussion. Anyway, IMO global request scope is nearly
never a good idea. As discussed in that thread, people are into an
unplesant suprise if they use global request scope for e.g. aggregation.
Furthermore one introduce quite
Nathaniel Alfred wrote:
Global synchronization on sessions saves two lock operations and gives
better single-threaded performance.
Local synchronization on serverSession/sessions.get/sessions.put gives
better multi-threaded concurrency.
Both effects are really minute. I now tend to favour your
Sylvain Wallez wrote:
Steven Noels wrote:
On 12 May 2005, at 17:21, Stefano Mazzocchi wrote:
But it's also true that editing xml files in a svn repository sucks
as an editing tool. Using wiki (or daisy or other solutions) is much
better.
I like the notion of
daisy - forrest - out
makes very
On 13 May 2005, at 12:31, Gunter D'Hondt wrote:
Steven,
so the GT for users will be on the 11th Oct while the 10th is for the
community members?
well, don't want to create polarization but yes, that's basically the
concept
the hackaton however is a great opportunity for informal chats - so
Steven Noels wrote:
the hackaton however is a great opportunity for informal chats - so
everybody is welcome on both days
Any chance of 2 day hackathon? :-)
Vadim
Vadim Gritsenko wrote:
Steven Noels wrote:
the hackaton however is a great opportunity for informal chats - so
everybody is welcome on both days
Any chance of 2 day hackathon? :-)
yes please!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open
Steven Noels wrote:
On 12 May 2005, at 17:21, Stefano Mazzocchi wrote:
But it's also true that editing xml files in a svn repository sucks as
an editing tool. Using wiki (or daisy or other solutions) is much better.
I like the notion of
daisy - forrest - out
makes very good sense.
It does, yet
Hi all,
Just to inform you that the creation review of Lepido [1] has just been
passed successfully. That means Lepido has been formally accepted as an
Eclipse project and the work can actually start.
A few days more are needed to setup the infrastructure, after which
you'll all be able to put
Il giorno 13/mag/05, alle 15:08, Sylvain Wallez ha scritto:
I see. You may want to try the calendar in window mode, instead of div
mode. This just requires to change new
CalendarPopup('forms_calendarDiv') to new CalendarPopup(). That
way, the calendar will output is non-xhtml stuff in a
The 2.1.x branch doesn't build. AFAICS the BrowserUpdateTransformer is missing.
Can you have a look at it Sylvain? Thanks!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
Reinhard Poetz wrote:
The 2.1.x branch doesn't build. AFAICS the BrowserUpdateTransformer is
missing. Can you have a look at it Sylvain? Thanks!
adding the transformer is not enough, otherwise I would have done it myself
;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
Le 13 mai 05, à 12:36, Steven Noels a écrit :
...I'm quite convinced though that documentation committers are
currently passively discouraged by the patch/mail mechanism...
Sounds right.
But there is another part of our docs which is still incomplete: the
autogenerated reference docs, created
Le 13 mai 05, à 16:38, Sylvain Wallez a écrit :
...Just to inform you that the creation review of Lepido [1] has just
been passed successfully. That means Lepido has been formally accepted
as an Eclipse project and the work can actually start...
Wow, good job, keep it up!
-Bertrand
smime.p7s
Le 13 mai 05, à 16:17, Vadim Gritsenko a écrit :
..Any chance of 2 day hackathon? :-)
+1 for +1 day
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Steven Noels wrote:
On 12 May 2005, at 17:21, Stefano Mazzocchi wrote:
But it's also true that editing xml files in a svn repository sucks as
an editing tool. Using wiki (or daisy or other solutions) is much better.
I like the notion of
daisy - forrest - out
makes very good sense.
It does, yet
Nicola Ken Barozzi wrote:
Steven Noels wrote:
...
What do people think?
I think that we need people that write documentation, not a tool.
I can hardly disagree more.
I wrote my blog *before* I wrote its posts. Without it, I could have
written them by hand, but god, that always made me go nah.
I think that we need people that write documentation, not a tool.
I can hardly disagree more.
I wrote my blog *before* I wrote its posts. Without it, I could have
written them by hand, but god, that always made me go nah.
MDR ! This discussion is really funny. No offense guys but I feel
Sebastien Arbogast wrote:
I think that we need people that write documentation, not a tool.
I can hardly disagree more.
I wrote my blog *before* I wrote its posts. Without it, I could have
written them by hand, but god, that always made me go nah.
MDR ! This discussion is really funny. No offense
What we need is simplicity in the workflow.
Simplify the workflow, tuning the simplicity to those people that are
more likely to write, and content will start flowing in (as the wiki
shows very well).
Sebastien, this is not a funny discussion. Those who think that Word is
always more
I've noticed something weird with sitemap and flowscript.
I had made a syntax error in one of my matchers :
map:match pattern=internal/repository
map:call function=displayRepositoryDetails()/
/map:match
Notice the two parenthesis after the name of the function parameter.
Of course it's wrong
Sebastien Arbogast wrote:
What we need is simplicity in the workflow.
Simplify the workflow, tuning the simplicity to those people that are
more likely to write, and content will start flowing in (as the wiki
shows very well).
..
So I think that there is a third criteria we have to integrate in
For many Cocoon applications, there is the need to initialize Context,
Session and Request (C/R/S) attributes, e.g. with database connections,
and dispose those attributes after use so there are no leaks. Right now,
there are several methods for hooking into C/R/S creation and destruction:
Sebastien Arbogast wrote:
I've noticed something weird with sitemap and flowscript.
I had made a syntax error in one of my matchers :
map:match pattern=internal/repository
map:call function=displayRepositoryDetails()/
/map:match
Notice the two parenthesis after the name of the function
On Vie, 13 de Mayo de 2005, 9:38, Sylvain Wallez dijo:
Hi all,
Just to inform you that the creation review of Lepido [1] has just been
passed successfully. That means Lepido has been formally accepted as an
Eclipse project and the work can actually start.
A few days more are needed to setup
73 matches
Mail list logo
