date:20040130

On 31.01.2004 00:51, BURGHARD Eric wrote:
Hi everybody,

While playing with forrest/cocoon/xslt, i found something very strange.

I've got two different behavior of a document() function inside an xslt
stylesheet. I don't know if it's a bug or a feature.
If document() takes its parameter from a stylesheet variable ($filename),
xalan try to load the file from the same directory than the .xsl file.
If it takes its parameter from an attribute of the .xml which is being
transformed (@filename), it try to load the file from the same directory
than the .xml file.
Any idea ?
If that's true, it's definitely a bug. Using document() without a second 
parameter should resolve the path relative to the stylesheet. Only 
passing a node-set as second argument changes this behaviour, the path 
is resolved relative to this node-set:

"The URI reference may be relative. The base URI (see [3.2 Base URI]) of 
the node in the second argument node-set that is first in document order 
is used as the base URI for resolving the relative URI into an absolute 
URI. If the second argument is omitted, then it defaults to the node in 
the stylesheet that contains the expression that includes the call to 
the document function. Note that a zero-length URI reference is a 
reference to the document relative to which the URI reference is being 
resolved; thus document("") refers to the root node of the stylesheet; 
the tree representation of the stylesheet is exactly the same as if the 
XML document containing the stylesheet was the initial source document."

(XSLT spec, 12.1 Multiple Source Documents, 
http://www.w3.org/TR/xslt#document)

Joerg

strange behavior in xslt transformation with document()

2004-01-30 Thread BURGHARD Eric

Hi everybody,

While playing with forrest/cocoon/xslt, i found something very strange.

I've got two different behavior of a document() function inside an xslt
stylesheet. I don't know if it's a bug or a feature.

If document() takes its parameter from a stylesheet variable ($filename),
xalan try to load the file from the same directory than the .xsl file.

If it takes its parameter from an attribute of the .xml which is being
transformed (@filename), it try to load the file from the same directory
than the .xml file.

Any idea ?

file.xml




http://www.w3.org/1999/XSL/Transform";>

RE: Flow Redirect The auth-fw with cocoon:/ Not working

Correct. I have the pipelines moved out of an internal pipeline, and call
them from the browser and they work as expected. As well, when the blank
page loads.. I can manually type in a protected url, and I am logged in
correctly.

JD

( CC'd users to move it over there. )

-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 1:56 PM
To: [EMAIL PROTECTED]
Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not working


Just let me rephrase please (by the way, it might a users@ ... chat instead
of dev):

When you put your login pipeline in a subsitemap: you get a blank page.

If you put them at the root sitemap you don't have nay problems: everything
work as expected.

Is it that?

JD Daniels <[EMAIL PROTECTED]> wrote:
Yes... I get file not found.. it looks in the incorrect directory.
You can see in the sitemap.log below.. everything *seems* to be working
correctly:

INFO [sitemap] (/root/users/view.xsp) Thread-15/ForwardRedirector:
Redirecting to '/root/auth/login.form?resource=%2Froot%2Fusers%2Fview.xsp'
INFO [sitemap] (/root/auth/login.form) Thread-15/ForwardRedirector:
Redirecting to 'cocoon:/login-display-pipeline'
INFO [sitemap]
(/root/auth/5e633f0d466b538e64777087384c836f74437714.continue)
Thread-15/ForwardRedirector: Redirecting to 'cocoon:/doLogin.xml'
INFO [sitemap]
(/root/auth/5e633f0d466b538e64777087384c836f74437714.continue)
Thread-15/RedirectToURINode: Redirecting to '/root' at
file:/D:/Projects/moduletest/ROOT/modules/auth/sitemap.xmap:77:67

JD


-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 1:32 PM
To: [EMAIL PROTECTED]
Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not working


Sorry to ask but have you tried cocoon:/ instead of cocoon:// ?

JD Daniels wrote:
ROOT/sitemap.xmap:















uri-prefix="auth"/>


ROOT/modules/auth/sitemap.xmap




value="forms/login.xml"/>











src="context://resources/xsl/system/woody-styling.xsl"/>











value="{request:username}"/>
value="{request:password}"/>










value="{request:username}"/>
value="{request:password}"/>












-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 12:23 PM
To: [EMAIL PROTECTED]
Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not working


Could you send us your sitemap (well not all, but you understood)

JD Daniels wrote:
the problem seems to be when the pipelines are defined in a sub sitemap.

I have the login, logout pipleines defined in sitemap under auth/
when they are defined in the root sitemap, they work fine. the logs indicate
that all of the actions and redirects are taking place, it is just
serializing out a blank html page.

JD


-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 12:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Flow Redirect The auth-fw with cocoon:/ Not working


I used the action with tons of redirection and it worked fine.

JD Daniels wrote:
There was a thread on this earlier, but there was not a solution I can see.

I had my auth pipelines defined in the root sitemap, and they worked great.
I need to move them to a sub-sitemap, but when I do, a blank html page is
serialized out to the client, although all the logs indicate the redirects
have taken place. the only change I can see is the addition of the cocoon://
protocol to my handler.

function login(form) {
var model = form.getModel();
form.showForm("login-display-pipeline");
cocoon.sendPage("doLogin.xml");
}

If I have this in my root sitemap. it works fine.
But if I move it to a subsitemap and configure the authentication handler:







anyone have any ideas?

JD





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

RE: Flow Redirect The auth-fw with cocoon:/ Not working

Just let me rephrase please (by the way, it might a users@ ... chat instead of dev):
 
When you put your login pipeline in a subsitemap: you get a blank page.
 
If you put them at the root sitemap you don't have nay problems: everything work as expected.Is it that?JD Daniels <[EMAIL PROTECTED]> wrote:
Yes... I get file not found.. it looks in the incorrect directory.You can see in the sitemap.log below.. everything *seems* to be workingcorrectly:INFO [sitemap] (/root/users/view.xsp) Thread-15/ForwardRedirector:Redirecting to '/root/auth/login.form?resource=%2Froot%2Fusers%2Fview.xsp'INFO [sitemap] (/root/auth/login.form) Thread-15/ForwardRedirector:Redirecting to 'cocoon:/login-display-pipeline'INFO [sitemap](/root/auth/5e633f0d466b538e64777087384c836f74437714.continue)Thread-15/ForwardRedirector: Redirecting to 'cocoon:/doLogin.xml'INFO [sitemap](/root/auth/5e633f0d466b538e64777087384c836f74437714.continue)Thread-15/RedirectToURINode: Redirecting to '/root' atfile:/D:/Projects/moduletest/ROOT/modules/auth/sitemap.xmap:77:67JD-Original Message-From: Nicolas Toper
 [mailto:[EMAIL PROTECTED]Sent: 2004-01-30 1:32 PMTo: [EMAIL PROTECTED]Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not workingSorry to ask but have you tried cocoon:/ instead of cocoon:// ?JD Daniels <[EMAIL PROTECTED]>wrote:ROOT/sitemap.xmap:uri-prefix="auth"/>ROOT/modules/auth/sitemap.xmapvalue="forms/login.xml"/>src=""/>value="{request:username}"/>value="{request:password}"/>value="{request:username}"/>value="{request:password}"/>-Original Message-From: Nicolas Toper [mailto:[EMAIL PROTECTED]Sent: 2004-01-30 12:23 PMTo: [EMAIL PROTECTED]Subject: RE:
 Flow Redirect The auth-fw with cocoon:/ Not workingCould you send us your sitemap (well not all, but you understood)JD Daniels wrote:the problem seems to be when the pipelines are defined in a sub sitemap.I have the login, logout pipleines defined in sitemap under auth/when they are defined in the root sitemap, they work fine. the logs indicatethat all of the actions and redirects are taking place, it is justserializing out a blank html page.JD-Original Message-From: Nicolas Toper [mailto:[EMAIL PROTECTED]Sent: 2004-01-30 12:07 PMTo: [EMAIL PROTECTED]Subject: Re: Flow Redirect The auth-fw with cocoon:/ Not workingI used the action with tons of redirection and it worked fine.JD Daniels wrote:There was a thread on this earlier, but there was not a solution I can see.I had my auth pipelines defined in the root sitemap, and they worked great.I need to move them
 to a sub-sitemap, but when I do, a blank html page isserialized out to the client, although all the logs indicate the redirectshave taken place. the only change I can see is the addition of the cocoon://protocol to my handler.function login(form) {var model = form.getModel();form.showForm("login-display-pipeline");cocoon.sendPage("doLogin.xml");}If I have this in my root sitemap. it works fine.But if I move it to a subsitemap and configure the authentication handler:anyone have any ideas?JDDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !Testez le nouveau Yahoo! MailDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !Testez le nouveau Yahoo! MailDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !Testez le nouveau Yahoo! MailDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

RE: Flow Redirect The auth-fw with cocoon:/ Not working

Yes... I get file not found.. it looks in the incorrect directory.
You can see in the sitemap.log below.. everything *seems* to be working
correctly:

INFO [sitemap] (/root/users/view.xsp) Thread-15/ForwardRedirector:
Redirecting to '/root/auth/login.form?resource=%2Froot%2Fusers%2Fview.xsp'
INFO [sitemap] (/root/auth/login.form) Thread-15/ForwardRedirector:
Redirecting to 'cocoon:/login-display-pipeline'
INFO [sitemap]
(/root/auth/5e633f0d466b538e64777087384c836f74437714.continue)
Thread-15/ForwardRedirector: Redirecting to 'cocoon:/doLogin.xml'
INFO [sitemap]
(/root/auth/5e633f0d466b538e64777087384c836f74437714.continue)
Thread-15/RedirectToURINode: Redirecting to '/root' at
file:/D:/Projects/moduletest/ROOT/modules/auth/sitemap.xmap:77:67

JD


-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 1:32 PM
To: [EMAIL PROTECTED]
Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not working


Sorry to ask but have you tried cocoon:/ instead of cocoon:// ?

JD Daniels <[EMAIL PROTECTED]> wrote:
ROOT/sitemap.xmap:















uri-prefix="auth"/>


ROOT/modules/auth/sitemap.xmap




value="forms/login.xml"/>











src="context://resources/xsl/system/woody-styling.xsl"/>











value="{request:username}"/>
value="{request:password}"/>










value="{request:username}"/>
value="{request:password}"/>












-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 12:23 PM
To: [EMAIL PROTECTED]
Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not working


Could you send us your sitemap (well not all, but you understood)

JD Daniels wrote:
the problem seems to be when the pipelines are defined in a sub sitemap.

I have the login, logout pipleines defined in sitemap under auth/
when they are defined in the root sitemap, they work fine. the logs indicate
that all of the actions and redirects are taking place, it is just
serializing out a blank html page.

JD


-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 12:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Flow Redirect The auth-fw with cocoon:/ Not working


I used the action with tons of redirection and it worked fine.

JD Daniels wrote:
There was a thread on this earlier, but there was not a solution I can see.

I had my auth pipelines defined in the root sitemap, and they worked great.
I need to move them to a sub-sitemap, but when I do, a blank html page is
serialized out to the client, although all the logs indicate the redirects
have taken place. the only change I can see is the addition of the cocoon://
protocol to my handler.

function login(form) {
var model = form.getModel();
form.showForm("login-display-pipeline");
cocoon.sendPage("doLogin.xml");
}

If I have this in my root sitemap. it works fine.
But if I move it to a subsitemap and configure the authentication handler:







anyone have any ideas?

JD





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

RE: Flow Redirect The auth-fw with cocoon:/ Not working

Sorry to ask but have you tried cocoon:/ instead of cocoon:// ?JD Daniels <[EMAIL PROTECTED]> wrote:
ROOT/sitemap.xmap:uri-prefix="auth"/>ROOT/modules/auth/sitemap.xmapvalue="forms/login.xml"/>src=""/>value="{request:username}"/>value="{request:password}"/>value="{request:username}"/>value="{request:password}"/>-Original Message-From: Nicolas
 Toper [mailto:[EMAIL PROTECTED]Sent: 2004-01-30 12:23 PMTo: [EMAIL PROTECTED]Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not workingCould you send us your sitemap (well not all, but you understood)JD Daniels <[EMAIL PROTECTED]>wrote:the problem seems to be when the pipelines are defined in a sub sitemap.I have the login, logout pipleines defined in sitemap under auth/when they are defined in the root sitemap, they work fine. the logs indicatethat all of the actions and redirects are taking place, it is justserializing out a blank html page.JD-Original Message-From: Nicolas Toper [mailto:[EMAIL PROTECTED]Sent: 2004-01-30 12:07 PMTo: [EMAIL PROTECTED]Subject: Re: Flow Redirect The auth-fw with cocoon:/ Not workingI used the action with tons of redirection and it worked fine.JD Daniels wrote:There was a thread on this earlier, but there was not a
 solution I can see.I had my auth pipelines defined in the root sitemap, and they worked great.I need to move them to a sub-sitemap, but when I do, a blank html page isserialized out to the client, although all the logs indicate the redirectshave taken place. the only change I can see is the addition of the cocoon://protocol to my handler.function login(form) {var model = form.getModel();form.showForm("login-display-pipeline");cocoon.sendPage("doLogin.xml");}If I have this in my root sitemap. it works fine.But if I move it to a subsitemap and configure the authentication handler:anyone have any ideas?JDDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !Testez le nouveau Yahoo! MailDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !Testez le nouveau Yahoo!
 MailDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

Re: [proposal] Cleaning up our component library

Reinhard Poetz wrote:
From: Sylvain Wallez [mailto:[EMAIL PROTECTED] 



The source-copy action already exists in 
o.a.c.acting.CopySourceAction, 
and the o.a.c.c.flow.util.PipelineUtil class could easily be 
generalized 
to any source, and not only "cocoon:".


Thanks for your answer and confirming that this would be a good idea. 
I don't have a use case yet (was just a thought I had when I read it)
 but if I have I'll implement it ;-)
I implemented a first draft of something like this a month or so ago 
just for "fun" but may have lost it in a computer switch.  I'll look for 
it and post/commit whatever I can find.

Geoff

RE: [proposal] Cleaning up our component library

2004-01-30 Thread Reinhard Poetz


> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] 


> The source-copy action already exists in 
> o.a.c.acting.CopySourceAction, 
> and the o.a.c.c.flow.util.PipelineUtil class could easily be 
> generalized 
> to any source, and not only "cocoon:".

Thanks for your answer and confirming that this would be a good idea. 
I don't have a use case yet (was just a thought I had when I read it)
 but if I have I'll implement it ;-)

--
Reinhard

RE: Releasing 2.1.4?

2004-01-30 Thread Reinhard Poetz


> From: Upayavira [mailto:[EMAIL PROTECTED]
> 
> 
> Sylvain Wallez wrote:
> 
> > Carsten Ziegeler wrote:
> >
> >> What do you all think about releasing 2.1.4? :)
> >>
> >> There are some open issues from our "management" list:
> >> http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320
> >>
> >> And next friday is our first "first friday" for this year.
> So I would
> >> propose to start the code freeze right after the "first
> friday" and
> >> release one week later.
> >>  
> >>
> >
> > +1
> 
> Big +1 (if 1.3 compatibility is okay)

+1 too if 
 - 1.3 compatibility is okay
 - and if Michael has confirmed the 
   fix for http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26186)
 - all problems with redirecting and cascading calls
   of internal pipelines in flows are solved
   (sorry for the noise of all problems are solved but
I haven't followed the discussion very close but I consider
it as important that everything works well)

--
Reinhard

RE: Flow Redirect The auth-fw with cocoon:/ Not working

ROOT/sitemap.xmap:


















ROOT/modules/auth/sitemap.xmap























  
  





























-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 12:23 PM
To: [EMAIL PROTECTED]
Subject: RE: Flow Redirect The auth-fw with cocoon:/ Not working


Could you send us your sitemap (well not all, but you understood)

JD Daniels <[EMAIL PROTECTED]> wrote:
the problem seems to be when the pipelines are defined in a sub sitemap.

I have the login, logout pipleines defined in sitemap under auth/
when they are defined in the root sitemap, they work fine. the logs indicate
that all of the actions and redirects are taking place, it is just
serializing out a blank html page.

JD


-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 12:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Flow Redirect The auth-fw with cocoon:/ Not working


I used the action with tons of redirection and it worked fine.

JD Daniels wrote:
There was a thread on this earlier, but there was not a solution I can see.

I had my auth pipelines defined in the root sitemap, and they worked great.
I need to move them to a sub-sitemap, but when I do, a blank html page is
serialized out to the client, although all the logs indicate the redirects
have taken place. the only change I can see is the addition of the cocoon://
protocol to my handler.

function login(form) {
var model = form.getModel();
form.showForm("login-display-pipeline");
cocoon.sendPage("doLogin.xml");
}

If I have this in my root sitemap. it works fine.
But if I move it to a subsitemap and configure the authentication handler:







anyone have any ideas?

JD





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

Re: Releasing 2.1.4?

2004-01-30 Thread Upayavira

Sylvain Wallez wrote:

Carsten Ziegeler wrote:

What do you all think about releasing 2.1.4? :)

There are some open issues from our "management" list:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320
And next friday is our first "first friday" for this year. So I
would propose to start the code freeze right after the "first friday"
and release one week later.
 

+1
Big +1 (if 1.3 compatibility is okay)

Regards, Upayavira

RE: Flow Redirect The auth-fw with cocoon:/ Not working

Could you send us your sitemap (well not all, but you understood)JD Daniels <[EMAIL PROTECTED]> wrote:
the problem seems to be when the pipelines are defined in a sub sitemap.I have the login, logout pipleines defined in sitemap under auth/when they are defined in the root sitemap, they work fine. the logs indicatethat all of the actions and redirects are taking place, it is justserializing out a blank html page.JD-Original Message-From: Nicolas Toper [mailto:[EMAIL PROTECTED]Sent: 2004-01-30 12:07 PMTo: [EMAIL PROTECTED]Subject: Re: Flow Redirect The auth-fw with cocoon:/ Not workingI used the action with tons of redirection and it worked fine.JD Daniels <[EMAIL PROTECTED]>wrote:There was a thread on this earlier, but there was not a solution I can see.I had my auth pipelines defined in the root sitemap, and they worked great.I need to move them to a sub-sitemap, but when I do, a blank
 html page isserialized out to the client, although all the logs indicate the redirectshave taken place. the only change I can see is the addition of the cocoon://protocol to my handler.function login(form) {var model = form.getModel();form.showForm("login-display-pipeline");cocoon.sendPage("doLogin.xml");}If I have this in my root sitemap. it works fine.But if I move it to a subsitemap and configure the authentication handler:anyone have any ideas?JDDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !Testez le nouveau Yahoo! MailDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

RE: Flow Redirect The auth-fw with cocoon:/ Not working

the problem seems to be when the pipelines are defined in a sub sitemap.

I have the login, logout pipleines defined in sitemap under auth/
when they are defined in the root sitemap, they work fine. the logs indicate
that all of the actions and redirects are taking place, it is just
serializing out a blank html page.

JD


-Original Message-
From: Nicolas Toper [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 12:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Flow Redirect The auth-fw with cocoon:/ Not working


I used the action with tons of redirection and it worked fine.

JD Daniels <[EMAIL PROTECTED]> wrote:
There was a thread on this earlier, but there was not a solution I can see.

I had my auth pipelines defined in the root sitemap, and they worked great.
I need to move them to a sub-sitemap, but when I do, a blank html page is
serialized out to the client, although all the logs indicate the redirects
have taken place. the only change I can see is the addition of the cocoon://
protocol to my handler.

function login(form) {
var model = form.getModel();
form.showForm("login-display-pipeline");
cocoon.sendPage("doLogin.xml");
}

If I have this in my root sitemap. it works fine.
But if I move it to a subsitemap and configure the authentication handler:







anyone have any ideas?

JD





Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

Re: Flow Redirect The auth-fw with cocoon:/ Not working

I used the action with tons of redirection and it worked fine.JD Daniels <[EMAIL PROTECTED]> wrote:
There was a thread on this earlier, but there was not a solution I can see.I had my auth pipelines defined in the root sitemap, and they worked great.I need to move them to a sub-sitemap, but when I do, a blank html page isserialized out to the client, although all the logs indicate the redirectshave taken place. the only change I can see is the addition of the cocoon://protocol to my handler.function login(form) {var model = form.getModel();form.showForm("login-display-pipeline");cocoon.sendPage("doLogin.xml");}If I have this in my root sitemap. it works fine.But if I move it to a subsitemap and configure the authentication handler:anyone have any
 ideas?JDDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Testez le nouveau Yahoo! Mail

Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/v2 ScriptableWidget.java

2004-01-30 Thread Christopher Oliver

Sorry about that. Thanks for fixing.

[EMAIL PROTECTED] wrote:

cziegeler2004/01/30 02:00:12

 Modified:src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/v2
   ScriptableWidget.java
 Log:
 Make cocoon compilable again - please cross-check the change
 
 Revision  ChangesPath
 1.3   +2 -0  cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/v2/ScriptableWidget.java
 
 Index: ScriptableWidget.java
 ===
 RCS file: /home/cvs/cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/v2/ScriptableWidget.java,v
 retrieving revision 1.2
 retrieving revision 1.3
 diff -u -r1.2 -r1.3
 --- ScriptableWidget.java	29 Jan 2004 16:36:17 -	1.2
 +++ ScriptableWidget.java	30 Jan 2004 10:00:12 -	1.3
 @@ -288,6 +288,8 @@
  Repeater repeater = (Repeater)delegate;
  return repeater.getSize();
  }
 +//TODO - added for making this compile
 +return 0;
  }
  
  public void jsSet_value(Object value) throws JavaScriptException {

Re: [flowscript] How to set an integer value in the FlowScript?

2004-01-30 Thread Christopher Oliver

Joerg Heinicke wrote:

Christopher Oliver  verizon.net> writes:
 

JS Number  is a double according to the specification. ScriptableWidget 
   

provides coercions that allow you to write:
   

 offset.value = 0;
   

See the sample I recently committed.
   



Ok, I had a look at it. woody_flow_example.js (v2) contains lines like

   wid.account.value = 2;

   wid.cowheight.value = 2;

with datatype long and it seems to work. I did remote debugging and the Double

is replaced by a Long in the method jsSet_value(Object value).



But I'm not using the v2, but "normal" Woody and it seems not to work. The

ScriptableWidget here has a similar logic in put() as in the mentioned

jsSet_value() in v2. But setting a breakpoint inside it, it never breaks there.

 

That's because the object provided to your event handler in your form 
definition is not a ScriptableWidget but rather the Java Widget. When 
you write

   offsetWidget.value = 0

you're actually calling Widget.setValue() through Rhino's Java integration

Is it now just a new functionality in v2 or is something broken in the current

Woody ScriptableWidget?

 

The old ScriptableWidget has something similar but as I mentioned in my 
email about the new one it has other limitations that makes it unusable.

BTW, this functionality does only work for fields, but not for output widgets

(it's more or less obvious from the code and I tried it with v2 sample). 

I just added a fix for Output.

Regards,

Chris

Re: Mail thread headers (was Re: source resolving in 2.2)

Geoff Howard wrote:

Sylvain Wallez wrote:

Geoff Howard wrote:

Sylvain Wallez wrote:

Unico Hommes wrote:




BTW, Unico, I don't know what is your mail software, but it 
doesn't send the "In-Reply-To" header, which breaks thread views 
in Mozilla and makes following discussions highly difficult.  


I use Outlook. I checked the thread view in Thunderbird but it 
wasn't a
problem there. What client are you using? I may rise to the 
opportunity
to finally exorcise The Evil Empire from controlling my inbox ;-)


Read carefully: "...which breaks thread views in _Mozilla_..." ;-)

Are other people experiencing this also?


Yes, but I was very interested to hear they may have this solved in 
Thunderbird.  I recently happened to look into what headers were 
being sent by mozilla and outlook and did think it looked like 
something a reader could solve...


Actually, Unico is not the only one. What I've found is that Mozilla 
uses the In-Reply-To header whereas Outlook (at least some version) 
uses "Thread-Topic" and "Thread-Index".

Outlook's headers seem strange to me, as I don't know how a mailer 
can rebuild a thread tree with just an indentifier for the thread, 
but no information about the posts relationships.


Ah, yes - that was it.  And I remember now it wasn't clear whether 
they gave enough info to reconstruct the tree, or just associate 
messages together in a common conversation topic.  I use the 
conversation topic view in outlook at work, and it's not a tree - just 
a flat topic view. May not be possible after all.  My mozilla keeps 
outlook posts in the same thread, but under the root post, not the 
actual message replied to.  Maybe Thunderbird and Mozilla are the same 
after all?


Well, I guess some Micro$oft marketing guy decided once that tree view 
were too much complicated for average users and invented this 
"conversation view" where all messages in a thread are sorted 
chronologically.

And even worse: "In-Reply-To" is specified in RFC 2822 [1] as a header a 
mailer /should/ send (see §3.6.4). Sure, it's not written /must/ send, 
but we can expect from a full-featured mailer to properly implement 
these optional features, and not inventing its own.

And that f**cking M$ doesn't even use the "X-" prefix for its 
non-standard headers. I also found a page [2] listing all other "fancy" 
M$-specific fields.

[1] http://www.faqs.org/rfcs/rfc2822.html
[2] http://info.ccone.at/INFO/Mail-Archives/procmail/Jul-2002/msg00286.html
Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Flow Redirect The auth-fw with cocoon:/ Not working

There was a thread on this earlier, but there was not a solution I can see.

I had my auth pipelines defined in the root sitemap, and they worked great.
I need to move them to a sub-sitemap, but when I do, a blank html page is
serialized out to the client, although all the logs indicate the redirects
have taken place. the only change I can see is the addition of the cocoon://
protocol to my handler.

function login(form) {
var model = form.getModel();
form.showForm("login-display-pipeline");
cocoon.sendPage("doLogin.xml");
}

If I have this in my root sitemap. it works fine.
But if I move it to a subsitemap and configure the authentication handler:







anyone have any ideas?

JD

Re: Mail thread headers (was Re: source resolving in 2.2)

2004-01-30 Thread J.Pietschmann

Sylvain Wallez wrote:
Actually, Unico is not the only one. What I've found is that Mozilla 
uses the In-Reply-To header whereas Outlook (at least some version) uses 
"Thread-Topic" and "Thread-Index".

Outlook's headers seem strange to me, as I don't know how a mailer can 
rebuild a thread tree with just an indentifier for the thread, but no 
information about the posts relationships.
*bg* my pet topic...
See
 http://marc.theaimsgroup.com/?l=fop-dev&m=104335769809427&w=2
The "Internet Mail Service" mentioned there is MS Exchange Server,
which actually is the culprit responsible for the "Thread-Topic"
and "Thread-Index" headers.
Even for the Clients sending In-Reply-To and References, there
are some caveats:
 http://bugzilla.mozilla.org/show_bug.cgi?id=191726
The Mail Client sending a bogus Referers header is actually Eudora
5.0 (>7.0 is ok).
Any ideas where this would fit in the Wiki or somewhere? Perhaps
 http://nagoya.apache.org/wiki/apachewiki.cgi?ToolChest/Users
J.Pietschmann

Re: source resolving in 2.2

Carsten Ziegeler wrote:

Unico Hommes wrote:
 

I haven't had doubts that hosting nodes as components in an IoC
container is a good approach, I think it makes perfect sense in light of
a sitemap's inheritable nature. What I *have* been having doubts about
is the way the container is now being configured from a sitemap
following a transformation to a general container configuration, but
that may be another story alltogether.
I think that defining a separate lifecycle extension for nodes in
combination with a semantic restriction on sitemap components that says
they must not implement Node will work well.
For instance, we could define:

interface Node {
 /** creation time LFE */
 setup(Context context, ServiceManager manager);
}
where context and manager parameters contain private objects that are
not available to their equivalents passed in through contextualize and
service respectively.
The LFE should just make sure the component it services is not a sitemap
component.
Wouldn't that work?

   

Yes, that would work. The only question, how will you check that only nodes
will implement this? We could test against a common interface: Node.
 

[guessing you mean "ProcessingNode"]

Yeah, but this won't avoid people to implement that interface just to 
benefit from the lifecycle extension (and leave the invoke() method empty).


Considering that the Avalon doesn't allow enumerating its content, and 
considering that the sitemap is preprocessed by an XSLT, what about 
having this stylesheet produce a random identifier that is used as the 
context entry name for processor-private data? This identifier will be 
set as a configuration attribute on sitemap statements only, thus 
totally hiding it from components in .


Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel Repeater.java

I had a look, it was the Woody v2 stuff. So thanks for fixing, otherwise 
my Cocoon would have been broken today at work after the update :)

Joerg

On 30.01.2004 11:57, Carsten Ziegeler wrote:

I got the problems when I udpated today.

Carsten


-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
cziegeler2004/01/30 02:04:35

 Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
   Repeater.java
 Log:
 Make cocoon compilable again - please cross-check the change
Uh! I had no problems compiling Cocoon/Woody in the last days.

Joerg

RE: Mail thread headers (was Re: source resolving in 2.2)

hmmm.. I took a look and you can group messages in outlook by "conversation"
which seems to use in-reply-to to have a normal thread view


-Original Message-
From: JD Daniels [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 11:10 AM
To: [EMAIL PROTECTED]
Subject: RE: Mail thread headers (was Re: source resolving in 2.2)


Outlook 2000 *does*

I was getting frustrated I was not getting any replies to a post i made... I
was lazy and just hit reply to an existing message to get the address and
wiped out the original text. This thread made me look.. and it does send
"in-Reply-to"

JD

-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 10:06 AM
To: [EMAIL PROTECTED]
Subject: RE: Mail thread headers (was Re: source resolving in 2.2)




Sylvain Wallez wrote:
>
> Geoff Howard wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Unico Hommes wrote:
> >
> 
>
>  BTW, Unico, I don't know what is your mail software, but
> it doesn't
>  send the "In-Reply-To" header, which breaks thread views
> in Mozilla
>  and makes following discussions highly difficult.
> >>>
> >>>
> >>>
> >>> I use Outlook. I checked the thread view in Thunderbird but it
> >>> wasn't a problem there. What client are you using? I may
> rise to the
> >>> opportunity to finally exorcise The Evil Empire from
> controlling my
> >>> inbox ;-)
> >>
> >>
> >> Read carefully: "...which breaks thread views in _Mozilla_..." ;-)
> >>
> >> Are other people experiencing this also?
> >
> >
> > Yes, but I was very interested to hear they may have this solved in
> > Thunderbird.  I recently happened to look into what headers
> were being
> > sent by mozilla and outlook and did think it looked like
> something a
> > reader could solve...
>
>
> Actually, Unico is not the only one. What I've found is that
> Mozilla uses the In-Reply-To header whereas Outlook (at least
> some version) uses "Thread-Topic" and "Thread-Index".
>
> Outlook's headers seem strange to me, as I don't know how a
> mailer can rebuild a thread tree with just an indentifier for
> the thread, but no information about the posts relationships.
>

Outlook doesn't maintain post relationships. The 'thread view' in
Outlook just consists of a long list of mails of the same thread, then
sorted by date. It is less verbose but - at least if the thread is not
too long - sufficient.

Unico

RE: Mail thread headers (was Re: source resolving in 2.2)


JD Daniels wrote:
> 
> Outlook 2000 *does*
> 
> I was getting frustrated I was not getting any replies to a 
> post i made... I was lazy and just hit reply to an existing 
> message to get the address and wiped out the original text. 
> This thread made me look.. and it does send "in-Reply-to"
> 
> JD
> 

The version I use at work is Outlook 2003.

Unico

RE: Mail thread headers (was Re: source resolving in 2.2)

Outlook 2000 *does*

I was getting frustrated I was not getting any replies to a post i made... I
was lazy and just hit reply to an existing message to get the address and
wiped out the original text. This thread made me look.. and it does send
"in-Reply-to"

JD

-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: 2004-01-30 10:06 AM
To: [EMAIL PROTECTED]
Subject: RE: Mail thread headers (was Re: source resolving in 2.2)




Sylvain Wallez wrote:
>
> Geoff Howard wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Unico Hommes wrote:
> >
> 
>
>  BTW, Unico, I don't know what is your mail software, but
> it doesn't
>  send the "In-Reply-To" header, which breaks thread views
> in Mozilla
>  and makes following discussions highly difficult.
> >>>
> >>>
> >>>
> >>> I use Outlook. I checked the thread view in Thunderbird but it
> >>> wasn't a problem there. What client are you using? I may
> rise to the
> >>> opportunity to finally exorcise The Evil Empire from
> controlling my
> >>> inbox ;-)
> >>
> >>
> >> Read carefully: "...which breaks thread views in _Mozilla_..." ;-)
> >>
> >> Are other people experiencing this also?
> >
> >
> > Yes, but I was very interested to hear they may have this solved in
> > Thunderbird.  I recently happened to look into what headers
> were being
> > sent by mozilla and outlook and did think it looked like
> something a
> > reader could solve...
>
>
> Actually, Unico is not the only one. What I've found is that
> Mozilla uses the In-Reply-To header whereas Outlook (at least
> some version) uses "Thread-Topic" and "Thread-Index".
>
> Outlook's headers seem strange to me, as I don't know how a
> mailer can rebuild a thread tree with just an indentifier for
> the thread, but no information about the posts relationships.
>

Outlook doesn't maintain post relationships. The 'thread view' in
Outlook just consists of a long list of mails of the same thread, then
sorted by date. It is less verbose but - at least if the thread is not
too long - sufficient.

Unico

Re: Releasing 2.1.4?

On 30.01.2004 16:38, Geoff Howard wrote:

Appears it's properly blocking in the release plan for next release:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
Yes, I changed it today shortly before all the other buzilla mails were 
sent to the list. I don't know if no mail is sent on adding dependencies 
or if those mails still haven't arrived the list as often in the last 
days. I only do not expect this as the other mails arrived immediately. 
Where are the bugzilla admins (Bertrand?), maybe they can have a look 
whether mails are sent on changes on dependencies?

Joerg

RE: Mail thread headers (was Re: source resolving in 2.2)

 

Sylvain Wallez wrote:
> 
> Geoff Howard wrote:
> 
> > Sylvain Wallez wrote:
> >
> >> Unico Hommes wrote:
> >
> 
> 
>  BTW, Unico, I don't know what is your mail software, but 
> it doesn't 
>  send the "In-Reply-To" header, which breaks thread views 
> in Mozilla 
>  and makes following discussions highly difficult.
> >>>
> >>>
> >>>
> >>> I use Outlook. I checked the thread view in Thunderbird but it 
> >>> wasn't a problem there. What client are you using? I may 
> rise to the 
> >>> opportunity to finally exorcise The Evil Empire from 
> controlling my 
> >>> inbox ;-)
> >>
> >>
> >> Read carefully: "...which breaks thread views in _Mozilla_..." ;-)
> >>
> >> Are other people experiencing this also?
> >
> >
> > Yes, but I was very interested to hear they may have this solved in 
> > Thunderbird.  I recently happened to look into what headers 
> were being 
> > sent by mozilla and outlook and did think it looked like 
> something a 
> > reader could solve...
> 
> 
> Actually, Unico is not the only one. What I've found is that 
> Mozilla uses the In-Reply-To header whereas Outlook (at least 
> some version) uses "Thread-Topic" and "Thread-Index".
> 
> Outlook's headers seem strange to me, as I don't know how a 
> mailer can rebuild a thread tree with just an indentifier for 
> the thread, but no information about the posts relationships.
> 

Outlook doesn't maintain post relationships. The 'thread view' in
Outlook just consists of a long list of mails of the same thread, then
sorted by date. It is less verbose but - at least if the thread is not
too long - sufficient.

Unico

Re: Mail thread headers (was Re: source resolving in 2.2)

Sylvain Wallez wrote:

Geoff Howard wrote:

Sylvain Wallez wrote:

Unico Hommes wrote:



BTW, Unico, I don't know what is your mail software, but it doesn't 
send the "In-Reply-To" header, which breaks thread views in Mozilla 
and makes following discussions highly difficult.  
I use Outlook. I checked the thread view in Thunderbird but it wasn't a
problem there. What client are you using? I may rise to the opportunity
to finally exorcise The Evil Empire from controlling my inbox ;-)
Read carefully: "...which breaks thread views in _Mozilla_..." ;-)

Are other people experiencing this also?
Yes, but I was very interested to hear they may have this solved in 
Thunderbird.  I recently happened to look into what headers were being 
sent by mozilla and outlook and did think it looked like something a 
reader could solve...
Actually, Unico is not the only one. What I've found is that Mozilla 
uses the In-Reply-To header whereas Outlook (at least some version) uses 
"Thread-Topic" and "Thread-Index".

Outlook's headers seem strange to me, as I don't know how a mailer can 
rebuild a thread tree with just an indentifier for the thread, but no 
information about the posts relationships.
Ah, yes - that was it.  And I remember now it wasn't clear whether they 
gave enough info to reconstruct the tree, or just associate messages 
together in a common conversation topic.  I use the conversation topic 
view in outlook at work, and it's not a tree - just a flat topic view. 
May not be possible after all.  My mozilla keeps outlook posts in the 
same thread, but under the root post, not the actual message replied to. 
 Maybe Thunderbird and Mozilla are the same after all?

Geoff

Mail thread headers (was Re: source resolving in 2.2)

Geoff Howard wrote:

Sylvain Wallez wrote:

Unico Hommes wrote:



BTW, Unico, I don't know what is your mail software, but it doesn't 
send the "In-Reply-To" header, which breaks thread views in Mozilla 
and makes following discussions highly difficult.  


I use Outlook. I checked the thread view in Thunderbird but it wasn't a
problem there. What client are you using? I may rise to the opportunity
to finally exorcise The Evil Empire from controlling my inbox ;-)


Read carefully: "...which breaks thread views in _Mozilla_..." ;-)

Are other people experiencing this also?


Yes, but I was very interested to hear they may have this solved in 
Thunderbird.  I recently happened to look into what headers were being 
sent by mozilla and outlook and did think it looked like something a 
reader could solve...


Actually, Unico is not the only one. What I've found is that Mozilla 
uses the In-Reply-To header whereas Outlook (at least some version) uses 
"Thread-Topic" and "Thread-Index".

Outlook's headers seem strange to me, as I don't know how a mailer can 
rebuild a thread tree with just an indentifier for the thread, but no 
information about the posts relationships.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

[bug 26376] ,was: Releasing 2.1.4?

2004-01-30 Thread Bertrand Delacretaz

Le Vendredi, 30 jan 2004, à 16:38 Europe/Zurich, Geoff Howard a écrit :
...Appears it's properly blocking in the release plan for next release:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
Am I interpreting that right?
you're right - I have increased the severity to make it more obvious.

-Bertrand

DO NOT REPLY [Bug 26376] - No samples run with JDK1.3

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26376

No samples run with JDK1.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Major

Re: Releasing 2.1.4?

Bertrand Delacretaz wrote:
Le Vendredi, 30 jan 2004, à 14:30 Europe/Zurich, Geoff Howard a écrit :

On 30.01.2004 10:54, Carsten Ziegeler wrote:

...I propose the 12th of february
as the release date for 2.1.4 - regardless if we have solved all
the open issues (RORE - Release often, release early).
WDYAT?
+1


+1 - The 1.3 runtime incompatibility recently reported should be a 
blocker though (not sure if it's in bugzilla or not).  Still, I'd say 
it could be fixed by then.


+1, also for the 1.3 problem.
Appears it's properly blocking in the release plan for next release:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
Am I interpreting that right?

Geoff

Re: source resolving in 2.2

Sylvain Wallez wrote:
Unico Hommes wrote:

Sylvain Wallez wrote:
 

Carsten Ziegeler wrote:

As for the redirector, please add it to InvokeContext. This makes it 
available to both ActNode and CallFunctionNode. This is really a 
private concern of the Processor that has no need to spread somewhere 
else.
  


What about the flow interpreter and FOM_Cocoon class that have
dependencies on the Redirector?
 

Missed these ones. Sometimes I hate the flow code, that messes up with 
things it should not even know about :-(

I'll fix that.

BTW, Unico, I don't know what is your mail software, but it doesn't 
send the "In-Reply-To" header, which breaks thread views in Mozilla 
and makes following discussions highly difficult.
  


I use Outlook. I checked the thread view in Thunderbird but it wasn't a
problem there. What client are you using? I may rise to the opportunity
to finally exorcise The Evil Empire from controlling my inbox ;-)
 

Read carefully: "...which breaks thread views in _Mozilla_..." ;-)

Are other people experiencing this also?
Yes, but I was very interested to hear they may have this solved in 
Thunderbird.  I recently happened to look into what headers were being 
sent by mozilla and outlook and did think it looked like something a 
reader could solve...

Geoff

Re: Releasing 2.1.4?

2004-01-30 Thread Tony Collen

Carsten Ziegeler wrote:
What do you all think about releasing 2.1.4? :)

There are some open issues from our "management" list:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320
And next friday is our first "first friday" for this year. So I
would propose to start the code freeze right after the "first friday"
and release one week later.
Now, I'm not really superstitious but as I don't want to do a release
on a friday, 13th and as I'm not able to do the release between
the 14th and the 21th of february, I propose the 12th of february
as the release date for 2.1.4 - regardless if we have solved all
the open issues (RORE - Release often, release early).
Dang, imagine the karma of releasing 2.1.4 on Feb 14 :)

Tony

Re: [proposal] Cleaning up our component library

Reinhard Poetz wrote:

-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 28, 2004 6:13 PM
To: [EMAIL PROTECTED]
Subject: Re: [proposal] Cleaning up our component library

Ralph Goers wrote:

I thought actions were performed before generators and transformers?  

If so, how could an action copy data from a generator or transformer?

Wouldn't a source-copy function a nice addition for FOM?

The source-copy action already exists in o.a.c.acting.CopySourceAction, 
and the o.a.c.c.flow.util.PipelineUtil class could easily be generalized 
to any source, and not only "cocoon:".

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: Releasing 2.1.4?

Carsten Ziegeler wrote:

What do you all think about releasing 2.1.4? :)

There are some open issues from our "management" list:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320
And next friday is our first "first friday" for this year. So I
would propose to start the code freeze right after the "first friday"
and release one week later.
 

+1

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: source resolving in 2.2

Unico Hommes wrote:

I'd already replied to Sylvain's mail yesterday but it never seems to
have shown up :-/
Carsten Ziegeler wrote:

Do you mean the Processor is made available into the Avalon Context object in order for processing nodes to access it? A side effect is that it also makes it accessible to all components defined in the sitemap, and this is IMO *highly undesirable* as it potentially opens the door to weird abuses.

Yes, that's true as well - sigh. I thought this context is only available to tree processor components, but it seems that you're right and this context is passed down to all components.

The same goes for the ServiceManager. It currently exposes all components within a sitemap container, which means sitemap components can potentially access ProcessNodes. We will need some kind of insulation between the nodes and the components. If we do it so they run inside separate containers the Context issue will go away too.

Yep. I was thinking to something along these lines: a container for
sitemap components (the ones of ) and a child of that
container for sitemap statements.

This may have several benefits:
- avoids cluttering the container for runtime components with "dormant
components", i.e. components representing processing nodes will only be
created once and never again.
- can therefore allow using a more lightweight container for processing
nodes.

Is there any good way to pass down information to the
different tree nodes during processing time?

Alternatively, since running two different containers may be more
expensive -and not absolutely neccesary because ServiceManager isolation
can be achieved within the same container - we could define a lifecycle
extension for ProcessingNodes in order to pass in static settings.

I'm a total Fortress newbie and don't know about these features. Time
for me to learn, I think...

Sylvain

--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com

Re: [Gump@dotnot.org]: cocoon-2.1/cocoon-block-paranoid failed

Gump wrote:

Project: cocoon-block-paranoid
State: Failed
 

A dependency was missing. Should be fixed now.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: source resolving in 2.2

Unico Hommes wrote:

Sylvain Wallez wrote:
 

Carsten Ziegeler wrote:

As for the redirector, please add it to InvokeContext. This 
makes it available to both ActNode and CallFunctionNode. This 
is really a private concern of the Processor that has no need 
to spread somewhere else.
   

What about the flow interpreter and FOM_Cocoon class that have
dependencies on the Redirector?
 

Missed these ones. Sometimes I hate the flow code, that messes up with 
things it should not even know about :-(

I'll fix that.

BTW, Unico, I don't know what is your mail software, but it 
doesn't send the "In-Reply-To" header, which breaks thread 
views in Mozilla and makes following discussions highly difficult.
   

I use Outlook. I checked the thread view in Thunderbird but it wasn't a
problem there. What client are you using? I may rise to the opportunity
to finally exorcise The Evil Empire from controlling my inbox ;-)
 

Read carefully: "...which breaks thread views in _Mozilla_..." ;-)

Are other people experiencing this also?

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

DO NOT REPLY [Bug 25482] - [BUG] bug in the Jisp filesystem store clear

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25482

[BUG] bug in the Jisp filesystem store clear





--- Additional Comments From [EMAIL PROTECTED]  2004-01-30 15:56 ---
Created an attachment (id=10160)
[TESTCASE-2] test case for PATCH-2

DO NOT REPLY [Bug 25482] - [BUG] bug in the Jisp filesystem store clear

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25482

[BUG] bug in the Jisp filesystem store clear





--- Additional Comments From [EMAIL PROTECTED]  2004-01-30 15:55 ---
Created an attachment (id=10159)
[PATCH-2] patch for the clearing the jisp file store

output widget (was: [flowscript] How to set an integer value in the FlowScript?)

Joerg Heinicke  ewerk.com> writes:

> When thinking about it I have to ask whether we need an output widget? Isn't
> it just a matter of styling, but nothing for the form definition (we already
> have wi:field/wi:styling/@type='output'). So shouldn't we remove the
> output widget?

I found a use case for the output widget - or better said a case where I need it
at the moment. But the reason for it is not the output widget itself, but seems
to be a limitation of the binding:

I have a repeater where a list of different objects is put in. These objects
have an ID, which I don't want to put into the frontend (i.e. HTML code, e.g.
hidden input). If I make the ID in the form definition a field (without
mentioning it in the template) the ID is null afterwards. It seems not to be
possible to set the repeater ID to direction="load" in the binding definition:

So the only possibility I have at the moment is to use a wd:output, so that the
value of the ID is not replaced with null.

Is this observation correct? Is there an option for the binding to set
direction="load"? Setting it on wb:repeater does not work for me.

Joerg

Re: Releasing 2.1.4?

2004-01-30 Thread Tony Collen

Ugo Cei wrote:
Carsten Ziegeler wrote:

WDYAT?


+1

Ugo




+1 here, too.

Tony

JXForms and validation inside Flow

2004-01-30 Thread Luca Nora

I've a problem with an application developed with Cocoon 2.1.3.

I'm trying to do validation inside a JXForm using Flow.

I'm using sitemap matches like this:



 
  
  
  http://www.ascc.net/xml/schematron"/>
  
 




 
 
 
 
 


XSP page which creates jxform (excerpt): basically outputs JXForm with inputs 
and selectS fetched from a DB source using ESQL.

...
http://apache.org/cocoon/jxforms/1.0";>
...


 

...


 bla bla
 
 

...

And in my JS flow:

function addresource(form) {
...
 // Show jxform
 form.sendView("dmin-jxforms-addresource-xsp",
  function(form) {
   // I use Database.js (PetShop sample) in order to query a DB and exceptions
   // to catch DB errors
   try {
// Do SQL on datasource...
   } catch(e) {
// Error coming from DBMS (ie. duplicate PK)
// Add violation in jxform
// User should see again this jxform with phone_number with Error!! string
// showed
form.addViolation("/phone_number", "Error!!");
   }
  });
...
}

Schematron for jxform is like this:
...

 bla
 


 
  drin drin!!
 

...

The result is that cocoon, when user fill this jxform and there's an error, 
show again jxform but WITHOUT any string indicating ie. "drin drin!!" 
or "Error!!" as indicated in JS and schematron (which is desidered behaviour). 
I'm missing something? What are the exact steps in order to do jxform 
validation using JS?

TIA,
-- 
Luca Nora

Re: Releasing 2.1.4?

2004-01-30 Thread Bertrand Delacretaz

Le Vendredi, 30 jan 2004, à 14:30 Europe/Zurich, Geoff Howard a écrit :

On 30.01.2004 10:54, Carsten Ziegeler wrote:
...I propose the 12th of february
as the release date for 2.1.4 - regardless if we have solved all
the open issues (RORE - Release often, release early).
WDYAT?
+1
+1 - The 1.3 runtime incompatibility recently reported should be a 
blocker though (not sure if it's in bugzilla or not).  Still, I'd say 
it could be fixed by then.
+1, also for the 1.3 problem.

-Bertrand

DO NOT REPLY [Bug 25113] - [Roadmap] CocoonForms - FUTURE releases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25113

[Roadmap] CocoonForms - FUTURE releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[Roadmap] CocoonForms - |[Roadmap] CocoonForms -
   |future releases |FUTURE releases

DO NOT REPLY [Bug 25099] - [Roadmap] CocoonForms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25099

[Roadmap] CocoonForms

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[Roadmap] Cocoon Forms  |[Roadmap] CocoonForms

DO NOT REPLY [Bug 25359] - [Roadmap] General - NEXT release

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25359

[Roadmap] General - NEXT release

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[Roadmap] General - next|[Roadmap] General - NEXT
   |release |release

DO NOT REPLY [Bug 25351] - [Roadmap] Documentation - FUTURE releases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25351

[Roadmap] Documentation - FUTURE releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Documentation roadmap - |[Roadmap] Documentation -
   |FUTURE releases |FUTURE releases

DO NOT REPLY [Bug 25358] - [Roadmap] General - FUTURE releases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25358

[Roadmap] General - FUTURE releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|General roadmap - FUTURE|[Roadmap] General - FUTURE
   |releases|releases

DO NOT REPLY [Bug 25322] - [Roadmap] Cocoon - FUTURE releases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25322

[Roadmap] Cocoon - FUTURE releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Cocoon Roadmap - FUTURE |[Roadmap] Cocoon - FUTURE
   |releases|releases

DO NOT REPLY [Bug 25321] - [Roadmap] Cocoon - NEXT release

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25321

[Roadmap] Cocoon - NEXT release

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Cocoon Roadmap - NEXT   |[Roadmap] Cocoon - NEXT
   |release |release

DO NOT REPLY [Bug 25320] - [Roadmap] Cocoon

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25320

[Roadmap] Cocoon

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Cocoon Roadmap  |[Roadmap] Cocoon

DO NOT REPLY [Bug 25359] - [Roadmap] General - next release

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25359

[Roadmap] General - next release

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|General roadmap - NEXT  |[Roadmap] General - next
   |release |release

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - release 1.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25110

[Roadmap] CocoonForms - release 1.0

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[Roadmap] CocoonForms - |[Roadmap] CocoonForms -
   |Release 1.0 |release 1.0

DO NOT REPLY [Bug 25113] - [Roadmap] CocoonForms - future releases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25113

[Roadmap] CocoonForms - future releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|CocoonForms - future|[Roadmap] CocoonForms -
   |releases|future releases

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - Release 1.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25110

[Roadmap] CocoonForms - Release 1.0

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|CocoonForms release 1.0 |[Roadmap] CocoonForms -
   ||Release 1.0

DO NOT REPLY [Bug 25099] - [Roadmap] Cocoon Forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25099

[Roadmap] Cocoon Forms

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Cocoon Forms Roadmap|[Roadmap] Cocoon Forms

RE: [portal] Tab navigation

2004-01-30 Thread Alex Romayev

OK, I'll take a look, see if I can figure it out.

So is the intention to be able to use store="request"
in the future?

Also, what about the back button?  Clicking the back
button breaks tab navigation.  Is this a bug?

Thanks,
-Alex

--- Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Ok, my fault, sorry - I was wrong, it doesn't work
> this way :(
> 
> I currently don't have the time to give you much
> more details, but
> I guess, you have to do it in a different way, like
> this:
> 
> Every change in the portal is notified by an event.
> You can subscribe
> for events and "listen" what is going on.
> Now, you can register your own event listener for
> tab changes. This
> listener knows all your tabs and resets the state of
> all sub tabs
> if the main tab selection changes.
> 
> If someone else has a better idea, let us know.
> 
> HTH
> Carsten
> 
> > -Original Message-
> > From: Alex Romayev [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, January 29, 2004 6:23 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [portal] Tab navigation
> > 
> > 
> > I also tried changing the "store" parameter in
> "tab"
> > configuration itself -- one word change, less room
> for
> > error.  I then tested the sample portal -- it
> still
> > did not work.
> > 
> > Hope this helps,
> > -Alex
> > 
> > --- Alex Romayev <[EMAIL PROTECTED]> wrote:
> > > Hi Carsten,
> > > 
> > > Unfortunately none of them worked :-(
> > > 
> > > I first tried fixing the back button, which
> seems
> > > like
> > > a simple change, however it still behaved the
> same
> > > way.  Is there anything wrong with my syntax?
> > > 
> > > With the tab I followed your steps, however it
> > > appears
> > > that they don't have any effect on the portal. 
> Any
> > > other ideas?
> > > 
> > > Thanks,
> > > -Alex
> > > 
> > > --- Carsten Ziegeler <[EMAIL PROTECTED]>
> wrote:
> > > > Alex Romayev wrote:
> > > > >
> > > > > Hi Carsten,
> > > > >
> > > > > I'm ready for the "portal configuration
> hell",
> > > if
> > > > you
> > > > > can lead me through it ;-)
> > > > >
> > > > To be honest, I don't know if it works, but
> it's
> > > > worth a try :)
> > > > 
> > > > Ok, here is a brief description:
> > > > Creating a different tab (stateless), means
> > > creating
> > > > a new renderer
> > > > for a tab. You will find this somewhere in the
> > > > cocoon.xconf:
> > > >   > > >
> > >
> >
>
class="org.apache.cocoon.portal.layout.renderer.impl.AspectRenderer"
> > > > logger="portal" name="tab">
> > > >  
> > > >  
> > > >   > > > value="{global:skin}styles/tab.xsl"/>
> > > >  
> > > >  
> > > >   > > > value="tab-layout"/>
> > > >  
> > > >  
> > > >  
> > > >   > > > value="false"/>
> > > >   > > > value="session"/>
> > > >  
> > > >  
> > > >  
> > > > Copy this and change the name "tab" in the
> first
> > > > line to whatever you want.
> > > > Change the "store" configuration for the
> > > > "tab-content" to "request".
> > > > Now, you have to register this renderer in the
> > > > layout factory:
> > > >  > > >
> > >
> >
>
class="org.apache.cocoon.portal.layout.impl.CompositeLayout"
> > > > name="tab">
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Add a new entry
> > > >  inside
> the
> > > > renderers section.
> > > > 
> > > > Now, you have an alternative renderer for a
> tab
> > > > layout object.
> > > > 
> > > > Last thing is to use this renderer. Go into
> your
> > > > layout.xml, to the
> > > > stateless
> > > > tab definition and configure the stateless tab
> to
> > > > use the new renderer:
> > > >  > > > default-renderer-name="YOUR NEW
> > > > TAB NAME">
> > > > 
> > > > So, in theory, this is it - if I didn't forget
> > > > anything.
> > > > Now the basic idea is to say, the main tab
> > > > (stateful) uses a session to
> > > > store the
> > > > state of a tab. The stateless instead uses the
> > > > request (one req-res cycle)
> > > > to store
> > > > the state.
> > > > If this doesn't work, well we have to find a
> > > better
> > > > solution :(
> > > > 
> > > > > I think stateful + stateless tab solution
> should
> > > > work
> > > > > for me.  There is also another problem I'm
> > > having,
> > > > > which I hope will be fixed by this (but I'd
> like
> > > > to
> > > > > check with you to make sure):
> > > > >
> > > > > On my "news" sub-tab I have "Latest News"
> page
> > > > with
> > > > > callouts to news items, which open "News
> Item"
> > > > page,
> > > > > by passing "news-item" coplet news-id:
> > > > >
> > > > > 
> > > > >   "News" is the 4th tab on "maintab"
> > > > >> > > > path="aspectDatas/tab"/>
> > > > >   "News Item" page is the 3rd page on
> "newstab"
> > > > >> > > > path="aspectDatas/tab"/>
> > > > >value="[EMAIL PROTECTED]"
> > > > > path="attributes/news-id"/>
> > > > >> > > > select="titl

Re: Releasing 2.1.4?

2004-01-30 Thread Ugo Cei

Carsten Ziegeler wrote:
WDYAT?
+1

	Ugo

Re: FormValidatorAction & regexp matching

2004-01-30 Thread Vadim Gritsenko

Leszek Gawron wrote:

Was anything changed with the regexp matching classes in cocoon?
I am using FormValidatorAction and while some older version worked OK the
lastest version returns NO_MATCH when comparing '2004-01-01' with 
^\d{4}(-\d{2}){2}$

It is a little bit strange as ^\d{4}-\d{2}-\d{2}$ works fine.

I just tried this pattern against Regexp 1.4-dev (current Regexp CVS) 
and it worked just fine. But the same pattern fails with Regexp 1.3 release.
So this is known, and already fixed, bug.

Vadim

Re: [flowscript] How to set an integer value in the FlowScript?

2004-01-30 Thread Vadim Gritsenko

Joerg Heinicke wrote:

Ok, instead of asking for further help on the last issue I had a look 
into the convertors myself - they are nicely short :) And I guess I 
found the reason for this problem: The PlainFloatConvertor returned a 
BigDecimal object - I guess just a copy & paste problem. I will commit 
it now. Please confirm my observation.


I had used formatting convertor by myself, I guess that's the reason why 
I'd not noticed the typo. Yes, it was typo, thanks for fixing.

Vadim

Re: [GUMP@lsd]: cocoon-2.1/cocoon-block-paranoid failed

2004-01-30 Thread Stefano Mazzocchi

On 30 Jan 2004, at 08:08, Gump wrote:

Project: cocoon-block-paranoid
State: Failed
URL:  
http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon-block- 
paranoid.htm
Wow! This Python Gump is *awesome*!

anybody cares to take a look at why this fails?

l--
Stefano.


smime.p7s
Description: S/MIME cryptographic signature

Re: Releasing 2.1.4?

Joerg Heinicke wrote:

On 30.01.2004 10:54, Carsten Ziegeler wrote:

What do you all think about releasing 2.1.4? :)

There are some open issues from our "management" list:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320


This one that is about the next release looks much better :)
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
And next friday is our first "first friday" for this year. So I
would propose to start the code freeze right after the "first friday"
and release one week later.
Now, I'm not really superstitious but as I don't want to do a release
on a friday, 13th and as I'm not able to do the release between
the 14th and the 21th of february, I propose the 12th of february
as the release date for 2.1.4 - regardless if we have solved all
the open issues (RORE - Release often, release early).
WDYAT?
+1
+1 - The 1.3 runtime incompatibility recently reported should be a 
blocker though (not sure if it's in bugzilla or not).  Still, I'd say it 
could be fixed by then.

Geoff

Re: Releasing 2.1.4?

2004-01-30 Thread Stefano Mazzocchi

On 30 Jan 2004, at 05:40, Joerg Heinicke wrote:

On 30.01.2004 10:54, Carsten Ziegeler wrote:
What do you all think about releasing 2.1.4? :)
There are some open issues from our "management" list:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320
This one that is about the next release looks much better :)
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
And next friday is our first "first friday" for this year. So I
would propose to start the code freeze right after the "first friday"
and release one week later.
Now, I'm not really superstitious but as I don't want to do a release
on a friday, 13th and as I'm not able to do the release between
the 14th and the 21th of february, I propose the 12th of february
as the release date for 2.1.4 - regardless if we have solved all
the open issues (RORE - Release often, release early).
WDYAT?
+1
+1

--
Stefano.


smime.p7s
Description: S/MIME cryptographic signature

RE: FormValidatorAction & regexp matching

2004-01-30 Thread Leszek Gawron

> What does 'older version' mean? Jakarta RegExp was updated from 1.2 to 1.3
> on
> 4th of September (between release of 2.1 and 2.1.1). The actions
> (FormValidatorAction and more important
> AbstractValidatorAction) don't have much changed in the last months:
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/
> org/apache/cocoon/acting/AbstractValidatorAction.java

After a little research I found out that it works with Tomcat because Tomcat
4.1.27 contains server\lib\jakarta-regexp-1.2.jar. Overwritting 1.3 version in
cocoon with 1.2 and running in Jetty got it working.

Another question is: if I want to be sure that all classes that cocoon uses
are fetched from cocoon/web-inf/lib should I use ParanoidCocoonServlet?

-- 
Leszek Gawron

Re: FormValidatorAction & regexp matching

Leszek Gawron  mobilebox.pl> writes:

> Was anything changed with the regexp matching classes in cocoon?
> I am using FormValidatorAction and while some older version worked OK the
> lastest version returns NO_MATCH when comparing '2004-01-01' with 
> ^d{4}(-d{2}){2}$
> 
> It is a little bit strange as ^d{4}-d{2}-d{2}$ works fine.

What does 'older version' mean? Jakarta RegExp was updated from 1.2 to 1.3 on
4th of September (between release of 2.1 and 2.1.1). The actions
(FormValidatorAction and more important
AbstractValidatorAction) don't have much changed in the last months:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/
org/apache/cocoon/acting/AbstractValidatorAction.java

Joerg

RE: FormValidatorAction & regexp matching

2004-01-30 Thread Leszek Gawron

I have found out that this has got nothing to do with FormValidatorAction or
jakarta regexp itself. It DOES NOT work under Jetty while WORKS under Tomcat. 
What can be the issue? 
LG

> Was anything changed with the regexp matching classes in cocoon?
> I am using FormValidatorAction and while some older version worked OK the
> lastest version returns NO_MATCH when comparing '2004-01-01' with
> ^\d{4}(-\d{2}){2}$
> 
> It is a little bit strange as ^\d{4}-\d{2}-\d{2}$ works fine.

--
Leszek Gawron

Re: [flowscript] How to set an integer value in the FlowScript?

Christopher Oliver  verizon.net> writes:

> JS Number  is a double according to the specification. ScriptableWidget 
> provides coercions that allow you to write:
> 
>   offset.value = 0;
> 
> See the sample I recently committed.

Ok, I had a look at it. woody_flow_example.js (v2) contains lines like
wid.account.value = 2;
wid.cowheight.value = 2;
with datatype long and it seems to work. I did remote debugging and the Double
is replaced by a Long in the method jsSet_value(Object value).

But I'm not using the v2, but "normal" Woody and it seems not to work. The
ScriptableWidget here has a similar logic in put() as in the mentioned
jsSet_value() in v2. But setting a breakpoint inside it, it never breaks there.

Is it now just a new functionality in v2 or is something broken in the current
Woody ScriptableWidget?

BTW, this functionality does only work for fields, but not for output widgets
(it's more or less obvious from the code and I tried it with v2 sample). When
thinking about it I have to ask whether we need an output widget? Isn't it just
a matter of styling, but nothing for the form definition (we already have
wi:field/wi:styling/@type='output'). So shouldn't we remove the output widget?

Joerg

RE: source resolving in 2.2

Unico Hommes wrote:
> 
> I haven't had doubts that hosting nodes as components in an IoC
> container is a good approach, I think it makes perfect sense in light of
> a sitemap's inheritable nature. What I *have* been having doubts about
> is the way the container is now being configured from a sitemap
> following a transformation to a general container configuration, but
> that may be another story alltogether.
> 
> I think that defining a separate lifecycle extension for nodes in
> combination with a semantic restriction on sitemap components that says
> they must not implement Node will work well.
> 
> For instance, we could define:
> 
> interface Node {
>   /** creation time LFE */
>   setup(Context context, ServiceManager manager);
> }
> 
> where context and manager parameters contain private objects that are
> not available to their equivalents passed in through contextualize and
> service respectively.
> 
> The LFE should just make sure the component it services is not a sitemap
> component.
> 
> Wouldn't that work?
> 
Yes, that would work. The only question, how will you check that only nodes
will implement this? We could test against a common interface: Node.

Ok, you have my +1 :)

Carsten

FormValidatorAction & regexp matching

2004-01-30 Thread Leszek Gawron

Was anything changed with the regexp matching classes in cocoon?
I am using FormValidatorAction and while some older version worked OK the
lastest version returns NO_MATCH when comparing '2004-01-01' with 
^\d{4}(-\d{2}){2}$

It is a little bit strange as ^\d{4}-\d{2}-\d{2}$ works fine.

-- 
Leszek Gawron

RE: source resolving in 2.2

Carsten Ziegeler wrote:
> 
> Unico Hommes wrote:
> > 
> > I haven't thought it all the way through either but I see some 
> > complexity arising now.
> > 
> > For instance in a subsitemap the components container must inherit 
> > from the supersitemaps components container. But the 
> subsitemaps node 
> > container needs to inherit from both the supersitemaps node 
> container 
> > and the subsitemaps component container. This cannot be 
> accomplished 
> > by allowing the subsitemap component container to inherit from the 
> > supersitemap node container because then the subsitemap components 
> > would have access to the supersitemap nodes. Still with me ;-)
> 
> Yes :)
> 
> > 
> > It looks as if some kind of multiple container inheritance 
> is needed?
> > 
> Hmm. Ok, for me this sounds too complex, but the current 
> approach is not safe as any component can lookup a tree 
> processor node. Is this right?
> 

Correct.

> So we need an easy and safe solution. Perhaps using the 
> container to build the tree is not the right way to go? (I 
> really don't know)
> 

I haven't had doubts that hosting nodes as components in an IoC
container is a good approach, I think it makes perfect sense in light of
a sitemap's inheritable nature. What I *have* been having doubts about
is the way the container is now being configured from a sitemap
following a transformation to a general container configuration, but
that may be another story alltogether.

I think that defining a separate lifecycle extension for nodes in
combination with a semantic restriction on sitemap components that says
they must not implement Node will work well.

For instance, we could define:

interface Node {
  /** creation time LFE */
  setup(Context context, ServiceManager manager);
}

where context and manager parameters contain private objects that are
not available to their equivalents passed in through contextualize and
service respectively.

The LFE should just make sure the component it services is not a sitemap
component.

Wouldn't that work?

Unico

RE: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel Repeater.java

I got the problems when I udpated today.

Carsten

> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 30, 2004 11:53 AM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit:
> cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel
> Repeater.java
> 
> 
> On 30.01.2004 11:04, [EMAIL PROTECTED] wrote:
> 
> > cziegeler2004/01/30 02:04:35
> > 
> >   Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
> > Repeater.java
> >   Log:
> >   Make cocoon compilable again - please cross-check the change
> 
> Uh! I had no problems compiling Cocoon/Woody in the last days.
> 
> Joerg
>

Re: cvs commit: cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/formmodel Repeater.java

On 30.01.2004 11:04, [EMAIL PROTECTED] wrote:

cziegeler2004/01/30 02:04:35

  Modified:src/blocks/woody/java/org/apache/cocoon/woody/formmodel
Repeater.java
  Log:
  Make cocoon compilable again - please cross-check the change
Uh! I had no problems compiling Cocoon/Woody in the last days.

Joerg

RE: source resolving in 2.2

Unico Hommes wrote:
> 
> I haven't thought it all the way through either but I see some
> complexity arising now. 
> 
> For instance in a subsitemap the components container must inherit from
> the supersitemaps components container. But the subsitemaps node
> container needs to inherit from both the supersitemaps node container
> and the subsitemaps component container. This cannot be accomplished by
> allowing the subsitemap component container to inherit from the
> supersitemap node container because then the subsitemap components would
> have access to the supersitemap nodes. Still with me ;-)

Yes :)

> 
> It looks as if some kind of multiple container inheritance is needed?
> 
Hmm. Ok, for me this sounds too complex, but the current approach is not
safe as any component can lookup a tree processor node. Is this right?

So we need an easy and safe solution. Perhaps using the container to build
the tree is not the right way to go? (I really don't know)

Some thoughts?

Carsten

Re: Releasing 2.1.4?

On 30.01.2004 10:54, Carsten Ziegeler wrote:
What do you all think about releasing 2.1.4? :)

There are some open issues from our "management" list:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320
This one that is about the next release looks much better :)
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25321
And next friday is our first "first friday" for this year. So I
would propose to start the code freeze right after the "first friday"
and release one week later.
Now, I'm not really superstitious but as I don't want to do a release
on a friday, 13th and as I'm not able to do the release between
the 14th and the 21th of february, I propose the 12th of february
as the release date for 2.1.4 - regardless if we have solved all
the open issues (RORE - Release often, release early).
WDYAT?
+1

Joerg

RE: source resolving in 2.2


Carsten Ziegeler wrote:
> 
> Unico Hommes wrote:
> >
> > > >
> > > Yes, that's true as well - sigh. I thought this context is only 
> > > available to tree processor components, but it seems that you're 
> > > right and this context is passed down to all components.
> > >
> >
> > The same goes for the ServiceManager. It currently exposes all 
> > components within a sitemap container, which means sitemap 
> components 
> > can potentially access ProcessNodes. We will need some kind of 
> > insulation between the nodes and the components. If we do 
> it so they 
> > run inside separate containers the Context issue will go away too.
> >
> > > Is there any good way to pass down information to the 
> different tree 
> > > nodes during processing time?
> >
> > Alternatively, since running two different containers may be more 
> > expensive -and not absolutely neccesary because ServiceManager 
> > isolation can be achieved within the same container - we 
> could define 
> > a lifecycle extension for ProcessingNodes in order to pass 
> in static settings.
> >
> Yes, I thought of that as well, but I think it's not really 
> better as any component could implement the lifecycle 
> interface as well and get the processor using this route. 
> Although it's not as convenient as using the context, I think 
> it's not really a difference.
> 
> I haven't thought very well about it, but would it really 
> work with a separate container for the treeprocessor? Some 
> nodes need to lookup sitemap components and the sitemap 
> components need to lookup other components. So, I think, this 
> only works, if the tree container is a child of the "sitemap 
> components"
> container.
> Does this work or do I oversee something?
> 

I haven't thought it all the way through either but I see some
complexity arising now. 

For instance in a subsitemap the components container must inherit from
the supersitemaps components container. But the subsitemaps node
container needs to inherit from both the supersitemaps node container
and the subsitemaps component container. This cannot be accomplished by
allowing the subsitemap component container to inherit from the
supersitemap node container because then the subsitemap components would
have access to the supersitemap nodes. Still with me ;-)

It looks as if some kind of multiple container inheritance is needed?

Hmmm.

Unico

Releasing 2.1.4?

What do you all think about releasing 2.1.4? :)

There are some open issues from our "management" list:
http://nagoya.apache.org/bugzilla/showdependencytree.cgi?id=25320

And next friday is our first "first friday" for this year. So I
would propose to start the code freeze right after the "first friday"
and release one week later.

Now, I'm not really superstitious but as I don't want to do a release
on a friday, 13th and as I'm not able to do the release between
the 14th and the 21th of february, I propose the 12th of february
as the release date for 2.1.4 - regardless if we have solved all
the open issues (RORE - Release often, release early).

WDYAT?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

DO NOT REPLY [Bug 25359] - General roadmap - NEXT release

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25359

General roadmap - NEXT release

This bug depends on bug 26186, which changed state:

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

DO NOT REPLY [Bug 26186] - Memory Leak caused by cocoon:// protocol

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26186

Memory Leak caused by cocoon:// protocol

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-30 09:45 ---
Could you please cross-check if everything now works for you as well and then 
close the bug?
I didn't use your patch, but I slightly simplified version that should do 
exactly the same.
Thanks!

DO NOT REPLY [Bug 26186] - Memory Leak caused by cocoon:// protocol

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26186

Memory Leak caused by cocoon:// protocol

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

RE: [portal] Tab navigation

Ok, my fault, sorry - I was wrong, it doesn't work this way :(

I currently don't have the time to give you much more details, but
I guess, you have to do it in a different way, like this:

Every change in the portal is notified by an event. You can subscribe
for events and "listen" what is going on.
Now, you can register your own event listener for tab changes. This
listener knows all your tabs and resets the state of all sub tabs
if the main tab selection changes.

If someone else has a better idea, let us know.

HTH
Carsten

> -Original Message-
> From: Alex Romayev [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 29, 2004 6:23 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [portal] Tab navigation
> 
> 
> I also tried changing the "store" parameter in "tab"
> configuration itself -- one word change, less room for
> error.  I then tested the sample portal -- it still
> did not work.
> 
> Hope this helps,
> -Alex
> 
> --- Alex Romayev <[EMAIL PROTECTED]> wrote:
> > Hi Carsten,
> > 
> > Unfortunately none of them worked :-(
> > 
> > I first tried fixing the back button, which seems
> > like
> > a simple change, however it still behaved the same
> > way.  Is there anything wrong with my syntax?
> > 
> > With the tab I followed your steps, however it
> > appears
> > that they don't have any effect on the portal.  Any
> > other ideas?
> > 
> > Thanks,
> > -Alex
> > 
> > --- Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> > > Alex Romayev wrote:
> > > >
> > > > Hi Carsten,
> > > >
> > > > I'm ready for the "portal configuration hell",
> > if
> > > you
> > > > can lead me through it ;-)
> > > >
> > > To be honest, I don't know if it works, but it's
> > > worth a try :)
> > > 
> > > Ok, here is a brief description:
> > > Creating a different tab (stateless), means
> > creating
> > > a new renderer
> > > for a tab. You will find this somewhere in the
> > > cocoon.xconf:
> > >   > >
> >
> class="org.apache.cocoon.portal.layout.renderer.impl.AspectRenderer"
> > > logger="portal" name="tab">
> > >  
> > >  
> > >   > > value="{global:skin}styles/tab.xsl"/>
> > >  
> > >  
> > >   > > value="tab-layout"/>
> > >  
> > >  
> > >  
> > >   > > value="false"/>
> > >   > > value="session"/>
> > >  
> > >  
> > >  
> > > Copy this and change the name "tab" in the first
> > > line to whatever you want.
> > > Change the "store" configuration for the
> > > "tab-content" to "request".
> > > Now, you have to register this renderer in the
> > > layout factory:
> > >  > >
> >
> class="org.apache.cocoon.portal.layout.impl.CompositeLayout"
> > > name="tab">
> > > 
> > > 
> > > 
> > > 
> > > Add a new entry
> > >  inside the
> > > renderers section.
> > > 
> > > Now, you have an alternative renderer for a tab
> > > layout object.
> > > 
> > > Last thing is to use this renderer. Go into your
> > > layout.xml, to the
> > > stateless
> > > tab definition and configure the stateless tab to
> > > use the new renderer:
> > >  > > default-renderer-name="YOUR NEW
> > > TAB NAME">
> > > 
> > > So, in theory, this is it - if I didn't forget
> > > anything.
> > > Now the basic idea is to say, the main tab
> > > (stateful) uses a session to
> > > store the
> > > state of a tab. The stateless instead uses the
> > > request (one req-res cycle)
> > > to store
> > > the state.
> > > If this doesn't work, well we have to find a
> > better
> > > solution :(
> > > 
> > > > I think stateful + stateless tab solution should
> > > work
> > > > for me.  There is also another problem I'm
> > having,
> > > > which I hope will be fixed by this (but I'd like
> > > to
> > > > check with you to make sure):
> > > >
> > > > On my "news" sub-tab I have "Latest News" page
> > > with
> > > > callouts to news items, which open "News Item"
> > > page,
> > > > by passing "news-item" coplet news-id:
> > > >
> > > > 
> > > >   "News" is the 4th tab on "maintab"
> > > >> > > path="aspectDatas/tab"/>
> > > >   "News Item" page is the 3rd page on "newstab"
> > > >> > > path="aspectDatas/tab"/>
> > > >> > > path="attributes/news-id"/>
> > > >> > > select="title"/>
> > > > 
> > > >
> > > > This works correctly, however if I press brower
> > > "Back"
> > > > button when on "News Item" page and click to
> > view
> > > > another news item on the "Latest News" page, I
> > get
> > > the
> > > > same news item.  However, if I navigate to
> > "Latest
> > > > News" page by clicking on tabs, everything works
> > > > correctly.
> > > >
> > > No, this is a different issue :) The portal has a
> > > built-in
> > > mechanism to "disable" the back button. By this
> > the
> > > user
> > > can't get into an undefined state.
> > > This means, that if you use back and to any
> > action,
> > > this
> > > action is ignored. If you want to enabled the
> >

Re: Commerzbank and Cocoon

2004-01-30 Thread Bertrand Delacretaz

Le Vendredi, 30 jan 2004, à 08:21 Europe/Zurich, Matthew Langham a  
écrit :

It looks as though the German Commerzbank is using Cocoon:

https://portal01.commerzbanking.de/cocoon/zgs/frankfurt/pubdist/ 
derivate.pag
e
Yes, and this
https://portal01.commerzbanking.de/cocoon/NOPAGE
makes it more obvious ;-)
-Bertrand

RE: source resolving in 2.2