Stefano Mazzocchi wrote:
...
I think it's a good time for cleaning up what avalon did wrong, simplify
as much as we can and tune it for our needs.
But I'm wide open to suggestions, as long as we move away from avalon.
A bit OT... I can't stand Cocoon not be able to build properly in Gump,
and
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
I'm trying to figure out what the current kernel already
provides and
what not.
Let's forget all the xml (descriptors etc) for a moment. Imagine I
want to write a block, that provides - let's say a special file
generator -
Joerg,
I realize that 'resting my case' is not enough...
some ideas:
this sounds like the operation 'selecting a row' should be an intrinsic
feature of the repeater-widget
to some extend we already have a means of selecting (multiple) rows by
putting a checkbox in every row which results in
On Tue, 2004-04-06 at 09:20, Marc Portier wrote:
Joerg,
I realize that 'resting my case' is not enough...
some ideas:
this sounds like the operation 'selecting a row' should be an intrinsic
feature of the repeater-widget
exactly my idea when I saw the message on users, +1
--
Bruno
On Tue, 2004-04-06 at 00:55, Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
[EMAIL PROTECTED] wrote:
antonio 2004/04/05 05:25:36
Log:
removing encoding=ISO-8859-1
Why?
Since UTF-8 is the new standard, I thought it
The XUL link bring a impressed application. But yes,90%(even more in my country) use
IE,and it's almost impossible to persuade user throw IE away.But to developers or
administrators it is different.Using Flash may offer great UI but still has some
shortcoming: much slower compare standard html
Bruno Dumon dijo:
Are you sure about the converting them? The one file I checked seems to
be not OK: src/blocks/forms/samples/messages/FormsMessages_fr.xml
I made a change, please review the file on the CVS:
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 22:44:
Why don't use (Object obj, Method method, Object[] args) in the
constructor of the continuation object.
That's a possible alternative, but makes prevents making Continuation an
abstract class.
Why should the continuation be
Hello,
I've been looking at the v2 version of cforms and AFAIU there is no way to
pass additional bizData to the showForm method. The only way is to do:
form[bizData] = bizData;
form.showForm( viewUri );
I find it very awkward. Let me give you the example. I have a page that
contains a CForms
Hello,
Christofer Oliver has written [1] that I should make a proposal so here it is:
What do you think about the flow ability to call a continuation knowing the
continuation id.
It should look something like:
contManager = null;
try {
contManager = cocoon.getComponent(
Leszek Gawron wrote:
Hello,
Christofer Oliver has written [1] that I should make a
proposal so here it is:
What do you think about the flow ability to call a
continuation knowing the continuation id.
It should look something like:
contManager = null;
try {
contManager =
Hello,
I'd like to log all Requests so that we can record them for analysis.
So, far the only way I think I can do this is to modify the method
process(..) in org.apache.cocoon. In this method, I thought I could use
a logging component (which has yet to be created) from the component
manager
Hi:
Stephan Michels dijo:
Uhmm, yes, you know that you CP the uri of an POST request? So in this
case all request parameters get lost, and you got a
NullPointerException.
Yes it can look weird the idea of CP this URI, but in the real life we
can find similar cases. Suppose I need to send the
On Tue, Apr 06, 2004 at 12:59:10PM +0200, Carsten Ziegeler wrote:
- when one gets 2 continuation ids and chooses one basing on
some external
info
Can you give an example, when you need this? - Just curious.
Me ? Nowhere - that was just a rough example ..
- when one wants to do
Leszek Gawron wrote:
On Tue, Apr 06, 2004 at 12:59:10PM +0200, Carsten Ziegeler wrote:
- when one gets 2 continuation ids and chooses one basing on some
external
info
Can you give an example, when you need this? - Just curious.
Me ? Nowhere - that was just a rough example ..
Leszek Gawron dijo:
If you use IE (I do not know how other browsers handle this) if you serve
a
page without client cache turned off you make a security hole (IE caches
everything and serves even after user has logged out).
Very smart browser! ROTFL!
See the code attached below. The main
On Tue, Apr 06, 2004 at 05:32:25AM -0600, Antonio Gallardo wrote:
Leszek Gawron dijo:
If you use IE (I do not know how other browsers handle this) if you serve
a
page without client cache turned off you make a security hole (IE caches
everything and serves even after user has logged out).
On Tue, Apr 06, 2004 at 01:32:58PM +0200, Carsten Ziegeler wrote:
That's true, but that are imho two different concerns: the page flow and
the continuation handling.
Now, perhaps someone else can help here a little bit. I discusses the
contination handling in flow with Ovidiu a little bit
I would highly suggest dropping in on #groovy on irc.codehaus.org for
any assistance on the best way to plug it into Groovy, though I
strongly suspect that a number of people there would jump on the chance
to put continuations in the normal groovy distro -- and at least one of
the people who
Joerg Heinicke wrote:
On 05.04.2004 14:35, Vadim Gritsenko wrote:
BTW, jstyle.jar might be only be of interest for the xsp block, so
it can possibly be moved to this block.
You can safely drop jstyle.
What about
Antonio Gallardo wrote:
Joerg Heinicke dijo:
On 06.04.2004 00:55, Antonio Gallardo wrote:
Moreover, even if XML parsers are able to recognize encoding, it's very
bad practice to have an XML file without the encoding property set.
We have the default enconding that is UTF-8 in
roy huang wrote:
snip what=CForms in XUL/
WDYT?
I think it's time to see some examples. If one of you guys who knows XUL
can produce XUL skin for CForms and/or other interesting examples, I'm
sure they will be included as part of Cocoon samples app.
Vadim
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Also, what do you think about something to allow generation of
labels? Currently, widget-label does not produce any label at all...
Actually, that's not a generator/transformer problem, but something
wrong with ft:widget-label. It should produce a
leo leonid wrote:
On Apr 3, 2004, at 9:35 PM, Sylvain Wallez wrote:
leo leonid wrote:
On Apr 3, 2004, at 5:55 PM, Joerg Heinicke wrote:
On 02.04.2004 19:42, leo leonid wrote:
...
The problem is, that you only cancel standard validation. But you
get stuck if you have a additional custom
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a stupid client which we need to
send a new page after each interaction.
On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
In v2 I have to do something like this:
form = new Form( definition );
form[ globalAppContext ] = getGlobalAppContext();
form[ user ] = getLoggedInUser();
form[ userContext ] = getContextForUser( getLoggedInUser() );
form[
On Tue, Apr 06, 2004 at 02:14:24PM +0100, Tim Larson wrote:
On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
In v2 I have to do something like this:
form = new Form( definition );
form[ globalAppContext ] = getGlobalAppContext();
form[ user ] = getLoggedInUser();
Am Di, den 06.04.2004 schrieb Antonio Gallardo um 13:12:
Hi:
Stephan Michels dijo:
Uhmm, yes, you know that you CP the uri of an POST request? So in this
case all request parameters get lost, and you got a
NullPointerException.
Yes it can look weird the idea of CP this URI, but in the
Am Di, den 06.04.2004 schrieb Bruno Dumon um 14:49:
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a stupid client
Vadim Gritsenko dijo:
Antonio Gallardo wrote:
Joerg Heinicke dijo:
On 06.04.2004 00:55, Antonio Gallardo wrote:
Moreover, even if XML parsers are able to recognize encoding, it's
very
bad practice to have an XML file without the encoding property set.
We have the default enconding that
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
I'm trying to figure out what the current kernel already
provides and
what not.
Let's forget all the xml (descriptors etc) for a moment. Imagine I
want to write a block, that provides - let's say a special file
Le 6 avr. 04, à 14:49, Bruno Dumon a écrit :
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a stupid client which we
On Tue, Apr 06, 2004 at 02:49:26PM +0200, Bruno Dumon wrote:
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a
Bruno Dumon dijo:
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a stupid client which we need to
send a new page
Bertrand Delacretaz dijo:
Le 6 avr. 04, à 14:49, Bruno Dumon a écrit :
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the
I was just looking into this over the last week. Unfortunately, neither the
process method or anything in CocoonServlet provide a hook to log or capture
the kind of statistics you want. In my case, I am adding some JMX
statistics. The only way I see to do it, short of modifying one of the
classes,
Stefano Mazzocchi wrote:
:) Sounds good to me. Now what do you think of using the
things from
Avalon that are good (for us)? Now, I think, some of the interfaces
(for logging, contextualization, initialization) are good
and we could
directly use them instead of building just a
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=28095.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 2004-04-06 at 16:01, Antonio Gallardo wrote:
Bruno Dumon dijo:
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the
Using the LuceneIndexTransformer, I discovered that elements containing
a numeric value are sometimes (not always) not stored by the
transformer, although the attribute lucene:store has been set to true in
de input for the transformer.
Example:
blah lucene:store=true13/blah
is not stored.
Bruno Dumon wrote:
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a stupid client which we need to
send a new page
Hello,
this construct doesn't show me the the content of the variable:
jx:set name=foo value=bar/
${foo}
This should print out bar but it doesn't!! Why? Is it another bug in
JXTemplateTransformer or did I something wrong?
Please help me.
Regards
Stephan
Leszek Gawron wrote:
snip
none of these is strictly connected to the form (the only one is the rowset
displayed as the form controls invoke actions that change this part of view).
In v2 I have to do something like this:
form = new Form( definition );
form[ globalAppContext ] =
Ohh. I'am sorry. I had used attribute name instead var. It works fine!
Thank you.
Regards
Stephan
On Tue, 2004-04-06 at 16:20, Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
:) Sounds good to me. Now what do you think of using the
things from
Avalon that are good (for us)? Now, I think, some of the interfaces
(for logging, contextualization, initialization) are good
Tim Larson wrote:
On Tue, Apr 06, 2004 at 12:30:03PM +0200, Leszek Gawron wrote:
In v2 I have to do something like this:
form = new Form( definition );
form[ globalAppContext ] = getGlobalAppContext();
form[ user ] = getLoggedInUser();
form[ userContext ] = getContextForUser(
On Tue, 2004-04-06 at 16:36, Sylvain Wallez wrote:
snip/
Don't agree ;-)
One area where CForms can (and must) improve is client-side validation.
This has already been discussed, maybe it's time to consider
implementing it.
If we look at the elements composing a Form, some of them
On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
snip/
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.
WDYT?
For the generator-approach, a good starting point would be to commit it
to CVS and add or
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
:) Sounds good to me. Now what do you think of using the
things from
Avalon that are good (for us)? Now, I think, some of the interfaces
(for logging, contextualization, initialization) are good
and we could
directly use them instead of
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
:) Sounds good to me. Now what do you think of using the
things from
Avalon that are good (for us)? Now, I think, some of the interfaces
(for logging, contextualization, initialization) are good
and we could
directly use them instead of
Carsten Ziegeler wrote:
...
I strongly suggest that we start with org.apache.cocoon.* to
avoid these problems down the road (including, yes, gump problems)
Yes, I understand of course all these problems, but I'm really afraid
of changing all the components now from Avalon interfaces to Cocoon
Bruno Dumon wrote:
On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
snip/
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.
WDYT?
For the generator-approach, a good starting point would be to commit
On Tue, 2004-04-06 at 18:19, Christopher Oliver wrote:
Bruno Dumon wrote:
On Mon, 2004-04-05 at 13:28, Sylvain Wallez wrote:
snip/
So, I propose the following changes to Cocoon forms:
- add a state to widgets (enabled/disabled/hidden).
- move to a generator approach.
WDYT?
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi
So what do others think?
Cocoon components will never work putside of Cocoon.
But will non-Cocoon components work inside of Cocoon? If so, with how
much work in adapting?
Or can a general adapter be written that uses
On Apr 5, 2004, at 11:31 AM, Hugo Burm wrote:
I have been thinking about a
Hibernate block on cocoondev.org.
That would be great!
I've been working on getting your Hibernate+Woody sample working for:
Cocoon 2.1.5_dev
Hibernate 2.0, w/ minimal changes to hibernate.properties (just the
dialect
Hi!
Has anyone written a generator to use Saxon 7.9s
xQuery processing or wired in xQuery support into Cocoon some other way?
If you could you please provide some examples/details on
how? J
Thanks!
Jared
Bruno Dumon wrote:
On Tue, 2004-04-06 at 18:19, Christopher Oliver wrote:
Bruno Dumon wrote:
snip
For the generator-approach, a good starting point would be to commit it
to CVS and add or change an example to show how it works.
I've done this for the V2 flowscript sample.
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
...
I strongly suggest that we start with org.apache.cocoon.* to avoid
these problems down the road (including, yes, gump problems)
Yes, I understand of course all these problems, but I'm really afraid
of changing all the components now from
On 06.04.2004 14:13, Vadim Gritsenko wrote:
The problem is, that you only cancel standard validation. But you
get stuck if you have a additional custom validation step.
If so, this feature is more or less deprecated though there was no
official decision made about this until now, but Sylvain
On 06.04.2004 13:52, Vadim Gritsenko wrote:
It does not provide much value - how many times have you looked into the
generated XSP code? And how important for you was formatting of this
generated code? I'm ok with keeping it, but, for myself, I have it
disabled (and jstyle.jar removed).
I
Maybe I'm missing something, but isn't there an access.log?
Joerg
On 06.04.2004 16:12, Ralph Goers wrote:
I was just looking into this over the last week. Unfortunately, neither the
process method or anything in CocoonServlet provide a hook to log or capture
the kind of statistics you want. In
Sure there is. But that doesn't necessarily integrate too well with JMX or
necessarily for what Surjan wants to do.
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 06, 2004 2:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Logging all requests
Maybe I'm
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=24900.
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=25110.
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=25094.
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=25110.
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=25293.
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=25305.
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=25315.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
...
I strongly suggest that we start with org.apache.cocoon.* to avoid
these problems down the road (including, yes, gump problems)
Yes, I understand of course all these problems, but I'm really afraid
of changing all the
On 06.04.2004 09:20, Marc Portier wrote:
Joerg,
I realize that 'resting my case' is not enough...
some ideas:
this sounds like the operation 'selecting a row' should be an intrinsic
feature of the repeater-widget
Yes, sounds reasonable.
In light of the above we could even consider sending
On 06.04.2004 16:36, Sylvain Wallez wrote:
Bruno Dumon wrote:
I'm wondering though what the value of this is.
The main advantage of CForms is to handle the typical problem of HTML
forms: the form needs to be redisplayed in a loop until everything's
valid. This is because the browser is a stupid
Hello Corin,
I would be really interested what means XUL in production for your
company. We have created a remote web application with XUL almost a year
ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106448994624522w=4.
The mentioned URL is no longer online as the company is dead. The
Hi,
Our internal content management system - incorporating Web, Teletext and
(shortly) on-air TV systems uses XUL as a rich interface. Basically our
user requirements meant that a flat web-based CMS wasn't suitable. And
I was loathe to go forward with an HTML / Javascript based rich
interface.
Joerg Heinicke dijo:
Another important difference at least for XUL is it's templating
mechanism. Supply the data as RDF and the XUL page builds up the form
itself. This would replace forms-samples-styling.xsl co. But it would
not make CForms superfluous. I even see no request/response cycles
75 matches
Mail list logo
