Re: [cron block] Execute job with original request setup
Hi Andreas, I saw Vadim already gave you some infos. I am using directly the Quartz Scheduler Agent from Cocoon aand don't know much more about Lenya. Nevertheless, the mechanism should be the same. Andreas Hartmann wrote: Hi Cocoon devs, in the process of moving the Lenya scheduler to Cocoon components, I played a little bit with the cron block. At first I tried to invoke a Lenya service from the scheduler by obtaining the service directly via the ServiceableJob's service manager. But this way I ended up with exceptions, because the request URI was empty. Originally, the service was only invoked from the web interface via flowscript. Some questions: 1) Is it possible to initialize a cron job with the original environment information? I would look directly on the cocoon.xconf file. I looked quickly and it looks like Lenya is using the Quartz scheduler from Cocoon. A a consequence, you should be able to initialize your cron job directly in the cocoon.xconf by providing the correct parameters. This will be ok only if you have a predefine number of tasks to load. 2) Or is it unwise to implement Contextualizable and access the request object via the ContextHelper in services which can be called from the scheduler? If yes, would that mean I should pass the request URI etc. manually? Personally I modified the QuartzScheduler so that it can read into a DB when starting Cocoon. This way all the cron Job I have already configured are automatically loaded and the correct parameters. It enables me to create or remove tasks during my session. Those modification will reamins when cocoon restarts I think your Idea with the ContextHelper might be fine but you need to find a way to provide the correct info to it. 3) Are there any general hints how to implement such a behaviour (call the same service from web interface and scheduler)? Refer to my first answer. Again, I am using the QuartzScheduler directly but this system allows me to define my tasks through a URI, when Cocoon restart they are all loaded. Thanks in advance! -- Andreas I hope this will help, sorry if I missed something, Pierre
RE: CForms samples for 2.1.7 - i18n question - errors SOLVED
Found this one too somewhere in an old message:
Now all I need are translations ;-)
Bye, Helma
> -Original Message-
> From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 23:51
> To: dev@cocoon.apache.org
> Subject: RE: CForms samples for 2.1.7 - i18n question -
> errors SOLVED except for one
>
>
> It finally clicked: I added the extra i18n keys to the wrong
> catalogue (forms instead of the default others). :-(
>
> Now there is only one error/problem left:
>
> how do I specify from which catalogue the attribute should come? I.e.
>
>
>
> tries to find the calendar.alt key in the default catalogue,
> but it's in the forms catalogue.
>
> Thanks.
>
> Bye, Helma
>
> > -Original Message-
> > From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, 12 March 2005 21:56
> > To: dev@cocoon.apache.org
> > Subject: RE: CForms samples for 2.1.7 - i18n question -
> > update on error
> >
> >
> > Hi,
> >
> > I've been adding and removing comments in the pipeline below
> > and I found that the weird namespace is introduced by the
> > i18n transformer. At first I thought it was an invalid locale
> > setting, but even if I set it to "en-US" the error remains.
> >
> > Please help!
> >
> > Bye, Helma
> >
> >
> >
> > > -Original Message-
> > > From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> > > Sent: Saturday, 12 March 2005 21:02
> > > To: dev@cocoon.apache.org
> > > Subject: RE: CForms samples for 2.1.7 - i18n question
> > >
> > >
> > > Bertrand et Sylvain,
> > >
> > > Right now, no i18n works. In core.log I find lines like:
> > >
> > > INFO(2005-03-12) 20:24.05:156 [core.i18n-bundles]
> > > (/samples/blocks/cssforms/form1.flow)
> > > PoolThread-3/XMLResourceBundleFactory: Resource not found:
> > > OtherMessages, locale: nl_BE, bundleName:
> > > file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messa
> > > ges/OtherMessages_nl_BE.xml. Exception:
> > > org.apache.cocoon.ResourceNotFoundException: Resource not
> > > found.: org.apache.excalibur.source.SourceNotFoundException:
> > > file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messa
> > > ges/OtherMessages_nl_BE.xml doesn't exist.
> > > INFO(2005-03-12) 20:24.05:812 [core.i18n-bundles]
> > > (/samples/blocks/cssforms/form1.flow)
> > > PoolThread-3/XMLResourceBundle: Resource update failed.
> > > OtherMessages, locale: nl Exception: Resource not found.
> > > INFO(2005-03-12) 20:24.49:031 [core.i18n-bundles]
> > > (/samples/blocks/cssforms/form1.flow)
> > > PoolThread-4/XMLResourceBundle: Resource update failed.
> > > OtherMessages, locale: nl Exception: Resource not found.
> > > INFO(2005-03-12) 20:25.54:421 [core.i18n-bundles]
> > > (/samples/blocks/cssforms/form1.flow)
> > > PoolThread-4/XMLResourceBundle: Resource update failed.
> > > OtherMessages, locale: nl Exception: Resource not found.
> > > INFO(2005-03-12) 20:27.33:968 [core.i18n-bundles]
> > > (/samples/blocks/cssforms/form1.flow)
> > > PoolThread-4/XMLResourceBundle: Resource update failed.
> > > OtherMessages, locale: nl Exception: Resource not found.
> > >
> > > In /samples/blocks/cssforms/messages I have the usual set of
> > > messages. IIUC nl_BE should default to nl and en_US should
> > > default to FormsMessages.xml.
> > >
> > > Are these messages correct?
> > >
> > > This is my pipeline:
> > >
> > >
> > > > > label="content1"/>
> > >
> > > > > value="{flow-attribute:locale}"/>
> > >
> > >
> > > value="forms/{1}_template.xml"/>
> > >
> > > > > src="resources/forms-samples-styling.xsl" label="debug3"/>
> > >
> > > > > value="{flow-attribute:locale}"/>
> > >
> > >
> > >
> > >
> > >
> > > Right now I get the i18n keys (i.e. 'firstname' instead of
> > > 'First Name'). However, the error messages are translated
> > > correctly, i.e. the defaults as available in
> > > /samples/blocks/forms/messages are translated, while my
> > > extended set (cssforms is merely a copy of
> > > /samples/blocks/forms) are ignored.
> > > Since I get the correct language, I assume the first i18n
> > > works correctly.
> > >
> > > The second doesn't work, since I introduce a key calendar.alt
> > > for calendar image alt attribute and that's still there.
> > >
> > > In the page source I find this:
> > >
> > > email.help
> > >
> > > (below in English only)
> > >
> > > And if you do not know what email address is,
> > > then well, chances are
> > > that you do not have it. However, if you have access
> > > to the Internet,
> > > you can easily get yourself one!
> > >
> > >
> > > Which is the result of:
> > >
> > >
> > > email.help
> > > (below in English only)
> > > And if you do not know what email address is,
> > > then well, chances are
> > >
Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition
depub2 wrote:
David's notes: see below
Sylvain Wallez
Thu, 24 Feb 2005 09:07:07 -0800
Added. When including your patch, I had a quick look at Excel and
found that the row insertion command adds rows _before_ the selected
rows as you initially suggested. So I added it that way. I made a
small change though by clearing the selection after executing the action.
If you'd like your name to be included for fame and posterity in
Cocoon's release notes, please give us your full name as "David" is a
bit unprecise.
I think it would be better to not clear the selections and here's why:
if there is a need to insert, say 32 empty rows, it is much easier if
the ones that are already checked remain checked; so the use case
looks like, check 1, insert; check the new one (old one still
checked), insert; check 2, insert; check 4, insert; check 8 (old 8
still checked), insert; done! It is very easy to have some very short
client-side javascript/buttons that "uncheck-all" or "check-all" (we
have it in our application), so the need to auto-uncheck is not really
needed - and in fact for the above use-case, hindering.
Ok, it makes sense. I changed it and the selection is now left untouched.
Well actually, the readonly="readonly" works! Try it!!! And there are
some cases where disabled="disabled" is problematic (binding/saving)
and I think something else I can't remember right now (pulldown
selections? calendar selections? - can't remember). (note {at-symbol}
above must be translated to @ - seems that symbol is not allowed on
the archives.)
Sorry, but I really don't know what you're talking about. Is this
'readonly' in the binding? If so, what's the relation with the styling
XSLs??
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: CForms samples for 2.1.7 - i18n question - errors SOLVED except for one
It finally clicked: I added the extra i18n keys to the wrong catalogue (forms
instead of the default others). :-(
Now there is only one error/problem left:
how do I specify from which catalogue the attribute should come? I.e.
tries to find the calendar.alt key in the default catalogue, but it's in the
forms catalogue.
Thanks.
Bye, Helma
> -Original Message-
> From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 21:56
> To: dev@cocoon.apache.org
> Subject: RE: CForms samples for 2.1.7 - i18n question -
> update on error
>
>
> Hi,
>
> I've been adding and removing comments in the pipeline below
> and I found that the weird namespace is introduced by the
> i18n transformer. At first I thought it was an invalid locale
> setting, but even if I set it to "en-US" the error remains.
>
> Please help!
>
> Bye, Helma
>
>
>
> > -Original Message-
> > From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, 12 March 2005 21:02
> > To: dev@cocoon.apache.org
> > Subject: RE: CForms samples for 2.1.7 - i18n question
> >
> >
> > Bertrand et Sylvain,
> >
> > Right now, no i18n works. In core.log I find lines like:
> >
> > INFO(2005-03-12) 20:24.05:156 [core.i18n-bundles]
> > (/samples/blocks/cssforms/form1.flow)
> > PoolThread-3/XMLResourceBundleFactory: Resource not found:
> > OtherMessages, locale: nl_BE, bundleName:
> > file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messa
> > ges/OtherMessages_nl_BE.xml. Exception:
> > org.apache.cocoon.ResourceNotFoundException: Resource not
> > found.: org.apache.excalibur.source.SourceNotFoundException:
> > file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messa
> > ges/OtherMessages_nl_BE.xml doesn't exist.
> > INFO(2005-03-12) 20:24.05:812 [core.i18n-bundles]
> > (/samples/blocks/cssforms/form1.flow)
> > PoolThread-3/XMLResourceBundle: Resource update failed.
> > OtherMessages, locale: nl Exception: Resource not found.
> > INFO(2005-03-12) 20:24.49:031 [core.i18n-bundles]
> > (/samples/blocks/cssforms/form1.flow)
> > PoolThread-4/XMLResourceBundle: Resource update failed.
> > OtherMessages, locale: nl Exception: Resource not found.
> > INFO(2005-03-12) 20:25.54:421 [core.i18n-bundles]
> > (/samples/blocks/cssforms/form1.flow)
> > PoolThread-4/XMLResourceBundle: Resource update failed.
> > OtherMessages, locale: nl Exception: Resource not found.
> > INFO(2005-03-12) 20:27.33:968 [core.i18n-bundles]
> > (/samples/blocks/cssforms/form1.flow)
> > PoolThread-4/XMLResourceBundle: Resource update failed.
> > OtherMessages, locale: nl Exception: Resource not found.
> >
> > In /samples/blocks/cssforms/messages I have the usual set of
> > messages. IIUC nl_BE should default to nl and en_US should
> > default to FormsMessages.xml.
> >
> > Are these messages correct?
> >
> > This is my pipeline:
> >
> >
> > > label="content1"/>
> >
> > > value="{flow-attribute:locale}"/>
> >
> >
> >
> >
> > > src="resources/forms-samples-styling.xsl" label="debug3"/>
> >
> > > value="{flow-attribute:locale}"/>
> >
> >
> >
> >
> >
> > Right now I get the i18n keys (i.e. 'firstname' instead of
> > 'First Name'). However, the error messages are translated
> > correctly, i.e. the defaults as available in
> > /samples/blocks/forms/messages are translated, while my
> > extended set (cssforms is merely a copy of
> > /samples/blocks/forms) are ignored.
> > Since I get the correct language, I assume the first i18n
> > works correctly.
> >
> > The second doesn't work, since I introduce a key calendar.alt
> > for calendar image alt attribute and that's still there.
> >
> > In the page source I find this:
> >
> > email.help
> >
> > (below in English only)
> >
> > And if you do not know what email address is,
> > then well, chances are
> > that you do not have it. However, if you have access
> > to the Internet,
> > you can easily get yourself one!
> >
> >
> > Which is the result of:
> >
> >
> > email.help
> > (below in English only)
> > And if you do not know what email address is,
> > then well, chances are
> > that you do not have it. However, if you have access
> > to the Internet,
> > you can easily get yourself one!
> >
> > .
> >
> >
> > So I suppose I have 2 or 3 problems here:
> >
> > 1. my extended messages are not read (I even moved away the
> > original forms directory and restarted Jetty).
> > 2. I get that weird namespace (maybe related), this is
> > already present in label="debug3".
> >
> > 3. my second i18n doesn't work, which I can't verify due to
> > error 2. :-(
> >
> > Bye, Helma
> >
> >
> >
> >
> > > -Original Message-
> > > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> > > Sent:
Re[2]: AW: Portal block using java 1.4 method
Hi Carsten, > Checked in, please cross check. Looks good, thanks. -- * best regards * Jens Maukisch
RE: CForms samples for 2.1.7 - i18n question - update on error
Hi,
I've been adding and removing comments in the pipeline below and I found that
the weird namespace is introduced by the i18n transformer. At first I thought
it was an invalid locale setting, but even if I set it to "en-US" the error
remains.
Please help!
Bye, Helma
> -Original Message-
> From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 March 2005 21:02
> To: dev@cocoon.apache.org
> Subject: RE: CForms samples for 2.1.7 - i18n question
>
>
> Bertrand et Sylvain,
>
> Right now, no i18n works. In core.log I find lines like:
>
> INFO(2005-03-12) 20:24.05:156 [core.i18n-bundles]
> (/samples/blocks/cssforms/form1.flow)
> PoolThread-3/XMLResourceBundleFactory: Resource not found:
> OtherMessages, locale: nl_BE, bundleName:
> file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messa
> ges/OtherMessages_nl_BE.xml. Exception:
> org.apache.cocoon.ResourceNotFoundException: Resource not
> found.: org.apache.excalibur.source.SourceNotFoundException:
> file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messa
> ges/OtherMessages_nl_BE.xml doesn't exist.
> INFO(2005-03-12) 20:24.05:812 [core.i18n-bundles]
> (/samples/blocks/cssforms/form1.flow)
> PoolThread-3/XMLResourceBundle: Resource update failed.
> OtherMessages, locale: nl Exception: Resource not found.
> INFO(2005-03-12) 20:24.49:031 [core.i18n-bundles]
> (/samples/blocks/cssforms/form1.flow)
> PoolThread-4/XMLResourceBundle: Resource update failed.
> OtherMessages, locale: nl Exception: Resource not found.
> INFO(2005-03-12) 20:25.54:421 [core.i18n-bundles]
> (/samples/blocks/cssforms/form1.flow)
> PoolThread-4/XMLResourceBundle: Resource update failed.
> OtherMessages, locale: nl Exception: Resource not found.
> INFO(2005-03-12) 20:27.33:968 [core.i18n-bundles]
> (/samples/blocks/cssforms/form1.flow)
> PoolThread-4/XMLResourceBundle: Resource update failed.
> OtherMessages, locale: nl Exception: Resource not found.
>
> In /samples/blocks/cssforms/messages I have the usual set of
> messages. IIUC nl_BE should default to nl and en_US should
> default to FormsMessages.xml.
>
> Are these messages correct?
>
> This is my pipeline:
>
>
> label="content1"/>
>
> value="{flow-attribute:locale}"/>
>
>
>
>
> src="resources/forms-samples-styling.xsl" label="debug3"/>
>
> value="{flow-attribute:locale}"/>
>
>
>
>
>
> Right now I get the i18n keys (i.e. 'firstname' instead of
> 'First Name'). However, the error messages are translated
> correctly, i.e. the defaults as available in
> /samples/blocks/forms/messages are translated, while my
> extended set (cssforms is merely a copy of
> /samples/blocks/forms) are ignored.
> Since I get the correct language, I assume the first i18n
> works correctly.
>
> The second doesn't work, since I introduce a key calendar.alt
> for calendar image alt attribute and that's still there.
>
> In the page source I find this:
>
> email.help
>
> (below in English only)
>
> And if you do not know what email address is,
> then well, chances are
> that you do not have it. However, if you have access
> to the Internet,
> you can easily get yourself one!
>
>
> Which is the result of:
>
>
> email.help
> (below in English only)
> And if you do not know what email address is,
> then well, chances are
> that you do not have it. However, if you have access
> to the Internet,
> you can easily get yourself one!
>
> .
>
>
> So I suppose I have 2 or 3 problems here:
>
> 1. my extended messages are not read (I even moved away the
> original forms directory and restarted Jetty).
> 2. I get that weird namespace (maybe related), this is
> already present in label="debug3".
>
> 3. my second i18n doesn't work, which I can't verify due to
> error 2. :-(
>
> Bye, Helma
>
>
>
>
> > -Original Message-
> > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, 12 March 2005 20:00
> > To: dev@cocoon.apache.org
> > Subject: Re: CForms samples for 2.1.7 - i18n question
> >
> >
> > Le 12 mars 05, à 19:01, Linden H van der (MI) a écrit :
> >
> > > ...I've managed to get the i18n for the flowscript samples
> > to work, by
> > > moving around the i18n transformer. However, I haven't
> succeeded in
> > > properly translating i18n info that is introduced in the
> > > forms-*-styling.xsl files. It seems impossible to add the i18n
> > > transformer a second time...
> >
> > Why not twice? I think you need to use it twice, IIRC because the
> > forms-styling stuff eats the i18n namespace:
> >
> > I've been doing stuff like
> >
> >
> >
> >
> >
> >
> >
> >
> > -Bertrand
> >
>
RE: CForms samples for 2.1.7 - i18n question
Bertrand et Sylvain, Right now, no i18n works. In core.log I find lines like: INFO(2005-03-12) 20:24.05:156 [core.i18n-bundles] (/samples/blocks/cssforms/form1.flow) PoolThread-3/XMLResourceBundleFactory: Resource not found: OtherMessages, locale: nl_BE, bundleName: file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messages/OtherMessages_nl_BE.xml. Exception: org.apache.cocoon.ResourceNotFoundException: Resource not found.: org.apache.excalibur.source.SourceNotFoundException: file:/D:/svn/cocoon/build/webapp/samples/blocks/cssforms/messages/OtherMessages_nl_BE.xml doesn't exist. INFO(2005-03-12) 20:24.05:812 [core.i18n-bundles] (/samples/blocks/cssforms/form1.flow) PoolThread-3/XMLResourceBundle: Resource update failed. OtherMessages, locale: nl Exception: Resource not found. INFO(2005-03-12) 20:24.49:031 [core.i18n-bundles] (/samples/blocks/cssforms/form1.flow) PoolThread-4/XMLResourceBundle: Resource update failed. OtherMessages, locale: nl Exception: Resource not found. INFO(2005-03-12) 20:25.54:421 [core.i18n-bundles] (/samples/blocks/cssforms/form1.flow) PoolThread-4/XMLResourceBundle: Resource update failed. OtherMessages, locale: nl Exception: Resource not found. INFO(2005-03-12) 20:27.33:968 [core.i18n-bundles] (/samples/blocks/cssforms/form1.flow) PoolThread-4/XMLResourceBundle: Resource update failed. OtherMessages, locale: nl Exception: Resource not found. In /samples/blocks/cssforms/messages I have the usual set of messages. IIUC nl_BE should default to nl and en_US should default to FormsMessages.xml. Are these messages correct? This is my pipeline: Right now I get the i18n keys (i.e. 'firstname' instead of 'First Name'). However, the error messages are translated correctly, i.e. the defaults as available in /samples/blocks/forms/messages are translated, while my extended set (cssforms is merely a copy of /samples/blocks/forms) are ignored. Since I get the correct language, I assume the first i18n works correctly. The second doesn't work, since I introduce a key calendar.alt for calendar image alt attribute and that's still there. In the page source I find this: email.help (below in English only) And if you do not know what email address is, then well, chances are that you do not have it. However, if you have access to the Internet, you can easily get yourself one! Which is the result of: email.help (below in English only) And if you do not know what email address is, then well, chances are that you do not have it. However, if you have access to the Internet, you can easily get yourself one! . So I suppose I have 2 or 3 problems here: 1. my extended messages are not read (I even moved away the original forms directory and restarted Jetty). 2. I get that weird namespace (maybe related), this is already present in label="debug3". 3. my second i18n doesn't work, which I can't verify due to error 2. :-( Bye, Helma > -Original Message- > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > Sent: Saturday, 12 March 2005 20:00 > To: dev@cocoon.apache.org > Subject: Re: CForms samples for 2.1.7 - i18n question > > > Le 12 mars 05, à 19:01, Linden H van der (MI) a écrit : > > > ...I've managed to get the i18n for the flowscript samples > to work, by > > moving around the i18n transformer. However, I haven't succeeded in > > properly translating i18n info that is introduced in the > > forms-*-styling.xsl files. It seems impossible to add the i18n > > transformer a second time... > > Why not twice? I think you need to use it twice, IIRC because the > forms-styling stuff eats the i18n namespace: > > I've been doing stuff like > > > > > > > > > -Bertrand >
Re: CForms samples for 2.1.7 - i18n question
Linden H van der (MI) wrote:
Hi,
I've managed to get the i18n for the flowscript samples to work, by
moving around the i18n transformer. However, I haven't succeeded in
properly translating i18n info that is introduced in the
forms-*-styling.xsl files. It seems impossible to add the i18n
transformer a second time.
Why is it impossible? What problem do you encounter?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Question on CForms - relevant for 2.1.7
Linden H van der (MI) wrote:
Guys,
I don't manage to stay current on the ins and outs of CForms, current
state and its future. I'm currently working on removing the tablebased
layout from the forms-*-styling.xsl files. I would very much like it to
be added to 2.1.7, so I'm doing my best to get it done before the code
freeze.
I got the idea to adjust the form1 examples to something more along the
lines of:
http://www.aplus.co.yu/css/forms/
I.e. a bit more realistic and a menu that shows different styles.
What I'd like to know is: how many differences are there between HEAD
and TRUNK that will make my efforts useless?
There are no differences, except very minor ones in a few classes.
So you can work safely, your efforts won't be wasted.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: CForms samples for 2.1.7 - i18n question
Le 12 mars 05, à 19:01, Linden H van der (MI) a écrit : ...I've managed to get the i18n for the flowscript samples to work, by moving around the i18n transformer. However, I haven't succeeded in properly translating i18n info that is introduced in the forms-*-styling.xsl files. It seems impossible to add the i18n transformer a second time... Why not twice? I think you need to use it twice, IIRC because the forms-styling stuff eats the i18n namespace: I've been doing stuff like -Bertrand smime.p7s Description: S/MIME cryptographic signature
CForms samples for 2.1.7 - i18n question
Hi, I've managed to get the i18n for the flowscript samples to work, by moving around the i18n transformer. However, I haven't succeeded in properly translating i18n info that is introduced in the forms-*-styling.xsl files. It seems impossible to add the i18n transformer a second time. So, what to do? Bye, Helma
RE: Question on CForms - relevant for 2.1.7 - translations requested
I think any language is welcome, but you'd have to fill me in on how to display it. If you want to go into the trouble of translating the list below, please provide the rest of FormsMessages.xml and OtherMessages.xml as well. Ah, and to make things complete: please provide the Greek word for "Calendar". Thanks. Bye, Helma > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Saturday, 12 March 2005 17:33 > To: dev@cocoon.apache.org > Subject: RE: Question on CForms - relevant for 2.1.7 - > translations requested > > > On Sat, 12 Mar 2005, Linden H van der (MI) wrote: > hi helma > > do you want a grrek translation too, or it would be difficult > to handle > greek language? > > regards > > stavros > > > > THANKS a lot. > > > > I'm putting some i18n text in to make the localized samples > more interesting. It would be great if you could provide a > translation of the following in your native language: > > > >Title > >Mr. > >Ms. > >Mrs. > >Miss. > >First Name > >Surname > >Birthdate (dd/MM/) > >Dead and not born > yet should not bother filling this form > >Enter your email address > >An email address must be in > [EMAIL PROTECTED] format. > >Remember me > >Address > >Username > >The username must contain > exactly 5 characters. > >Country > >Password > >Retype Password > > > > I'm sorry it's not yet complete, but every bit helps. > > > > Thanks. > > > > Bye, Helma > > > > > -Original Message- > > > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > > > Sent: Saturday, 12 March 2005 15:06 > > > To: dev@cocoon.apache.org > > > Subject: Re: Question on CForms - relevant for 2.1.7 > > > > > > > > > Le 12 mars 05, ΰ 14:52, Linden H van der (MI) a ιcrit : > > > > > > > ...So at least the styling will remain the same, but are there > > > > differences (big or small) in the widget definitions etc. > > > that require > > > > a rewrite of the current form samples?.. > > > > > > Like you I haven't been able to follow everything. > > > > > > File comparison, however, shows very few differences, it > > > seems like the > > > branch and trunk are well in sync. You might want to look at the > > > status.xml file in the trunk for more info. > > > > > > -Bertrand > > > > > > >
RE: Question on CForms - relevant for 2.1.7 - translations requested
On Sat, 12 Mar 2005, Linden H van der (MI) wrote: hi helma do you want a grrek translation too, or it would be difficult to handle greek language? regards stavros > THANKS a lot. > > I'm putting some i18n text in to make the localized samples more interesting. > It would be great if you could provide a translation of the following in your > native language: > >Title >Mr. >Ms. >Mrs. >Miss. >First Name >Surname >Birthdate (dd/MM/) >Dead and not born yet should not > bother filling this form >Enter your email address >An email address must be in [EMAIL > PROTECTED] format. >Remember me >Address >Username >The username must contain exactly 5 > characters. >Country >Password >Retype Password > > I'm sorry it's not yet complete, but every bit helps. > > Thanks. > > Bye, Helma > > > -Original Message- > > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > > Sent: Saturday, 12 March 2005 15:06 > > To: dev@cocoon.apache.org > > Subject: Re: Question on CForms - relevant for 2.1.7 > > > > > > Le 12 mars 05, ΰ 14:52, Linden H van der (MI) a ιcrit : > > > > > ...So at least the styling will remain the same, but are there > > > differences (big or small) in the widget definitions etc. > > that require > > > a rewrite of the current form samples?.. > > > > Like you I haven't been able to follow everything. > > > > File comparison, however, shows very few differences, it > > seems like the > > branch and trunk are well in sync. You might want to look at the > > status.xml file in the trunk for more info. > > > > -Bertrand > > >
RE: Question on CForms - relevant for 2.1.7 - translations requested
THANKS a lot. I'm putting some i18n text in to make the localized samples more interesting. It would be great if you could provide a translation of the following in your native language: Title Mr. Ms. Mrs. Miss. First Name Surname Birthdate (dd/MM/) Dead and not born yet should not bother filling this form Enter your email address An email address must be in [EMAIL PROTECTED] format. Remember me Address Username The username must contain exactly 5 characters. Country Password Retype Password I'm sorry it's not yet complete, but every bit helps. Thanks. Bye, Helma > -Original Message- > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > Sent: Saturday, 12 March 2005 15:06 > To: dev@cocoon.apache.org > Subject: Re: Question on CForms - relevant for 2.1.7 > > > Le 12 mars 05, à 14:52, Linden H van der (MI) a écrit : > > > ...So at least the styling will remain the same, but are there > > differences (big or small) in the widget definitions etc. > that require > > a rewrite of the current form samples?.. > > Like you I haven't been able to follow everything. > > File comparison, however, shows very few differences, it > seems like the > branch and trunk are well in sync. You might want to look at the > status.xml file in the trunk for more info. > > -Bertrand >
Re: Question on CForms - relevant for 2.1.7
Le 12 mars 05, à 14:52, Linden H van der (MI) a écrit : ...So at least the styling will remain the same, but are there differences (big or small) in the widget definitions etc. that require a rewrite of the current form samples?.. Like you I haven't been able to follow everything. File comparison, however, shows very few differences, it seems like the branch and trunk are well in sync. You might want to look at the status.xml file in the trunk for more info. -Bertrand smime.p7s Description: S/MIME cryptographic signature
RE: Question on CForms - relevant for 2.1.7
Thanks Bertrand for the quick reply. So at least the styling will remain the same, but are there differences (big or small) in the widget definitions etc. that require a rewrite of the current form samples? Bye, Helma > -Original Message- > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > Sent: Saturday, 12 March 2005 14:45 > To: dev@cocoon.apache.org > Subject: Re: Question on CForms - relevant for 2.1.7 > > > Le 12 mars 05, à 14:30, Linden H van der (MI) a écrit : > > ...What I'd like to know is: how many differences are there between > > HEAD > > and TRUNK that will make my efforts useless?.. > > It looks like the *-styling.xsl files are currently identical: > > $ cd BRANCH_2_1_X/src/blocks/forms > > $ for i in $(find . | grep styling.xsl | grep -v '\.svn') ; > do echo $i > ; diff $i ../../../../trunk/src/blocks/forms/$i ; done > > shows only a difference in the comments of > ./samples/resources/forms-field-styling.xsl > > -Bertrand >
Re: Question on CForms - relevant for 2.1.7
Le 12 mars 05, à 14:30, Linden H van der (MI) a écrit : ...What I'd like to know is: how many differences are there between HEAD and TRUNK that will make my efforts useless?.. It looks like the *-styling.xsl files are currently identical: $ cd BRANCH_2_1_X/src/blocks/forms $ for i in $(find . | grep styling.xsl | grep -v '\.svn') ; do echo $i ; diff $i ../../../../trunk/src/blocks/forms/$i ; done shows only a difference in the comments of ./samples/resources/forms-field-styling.xsl -Bertrand smime.p7s Description: S/MIME cryptographic signature
Question on CForms - relevant for 2.1.7
Guys, I don't manage to stay current on the ins and outs of CForms, current state and its future. I'm currently working on removing the tablebased layout from the forms-*-styling.xsl files. I would very much like it to be added to 2.1.7, so I'm doing my best to get it done before the code freeze. I got the idea to adjust the form1 examples to something more along the lines of: http://www.aplus.co.yu/css/forms/ I.e. a bit more realistic and a menu that shows different styles. What I'd like to know is: how many differences are there between HEAD and TRUNK that will make my efforts useless? Bye, Helma
Re: [RT] Another step to blocks: Application container support
Bradley S. Huffman wrote: > > I still trying to get acquainted with Cocoon so this may be a silly question, > but why cann't anything come after a serializer? > The answer is simple :) This is the way how the behaviour of the sitemap has been defined years ago. So, also you can write something after a serializer in the sitemap, it is *never* executed. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Another step to blocks: Application container support
Bertrand Delacretaz wrote:
> Le 11 mars 05, à 19:45, Carsten Ziegeler a écrit :
>
>
> IIUC the mechanism that you suggest would make it possible to support
> new DCCs by creating some kind of adapter class for them? In this way
> we could provide adapters for (say) Spring and Hivemind without closing
> doors to other options.
>
Yes, exactly.
>
>>...b) Direct support for DCC. Using these frameworks is not that
>>difficult
>>inside Cocoon, but I think it could be easier.
>>What do you think if e.g. a "getComponent("something")" in flow uses a
>>Spring BeanFactory (and if the factory does not have the bean/component
>>then the usual Avalon mechanism is used). The same would happen if you
>>get a service manager from the Cocoon core...
>
>
> Does that mean "chaining" containers, asking them in turn until one of
> them finds the component? If this is implemented at the sitemap level,
> would we then get a chain like this to get a component?
>
> -Ask this sitemap's DCC for the component
> -If not found, ask this sitemap's service manager
> -if not found, ask the parent sitemap, which asks its DCC then its
> service manager, and so on
>
> Just asking to check my understanding.
>
Yes, that's the idea.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Another step to blocks: Application container support
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
> +1. That was one of the concerns I expressed when seeing more and more
> features going into the core container. We should stick it to the
> well-known old ECM behaviour (plus a few additional bonuses like proxied
> poolable), and not try to extend it up to being a full-blown POJO container.
>
Yes, that's my idea today as well :) (I must admit that my initial
motivation for creating our own core was exactly that: build a
full-blown container...but now I know that this would be the wrong
approach).
>
>
> +1 as well. Such listeners could be declared a bit like in CForms, and I
> currently see 4 types of listeners :
> - on-enter (entering a sitemap)
> - on-pipeline-built (a pipeline has been built, but not yet executed)
> - on-execute-pipeline (the previously built pipeline is executed)
> - on-leave (going out -- needs to have the information of success, no
> match or exception)
>
> on-pipeline-built and on-execute-pipeline are IMO needed to handle the
> strict separation of these phases in the case of internal ("cocoon:")
> processing.
>
Hmm, yes, might be - I have to think about it.
>
> Back in fall 2004 I started prototyping an implementation of an Avalon
> component with Spring. Although technically feasible, this proved to
> require some work to be able to merge both configuration styles in a
> single file or convert Avalon-style xconf into Spring-style bean
> definitions. A lot of DCC-specific code to write and maintain.
>
> Now we actually don't have to mix them, but simply use the hierarchical
> nesting capabilities of both our containers and most (if not all) DCCs.
>
Yepp.
>
> Yes. Actually most of what is needed for this is a set of bidirectional
> adapters between ServiceManager and the equivalent interfaces in DCCs.
> That would allow for a DCC to be a parent of our core service manager
> and reciprocally.
>
> A component will then be managed by the appropriate CC (component
> container) type, and be available in that CC and all its children,
> whatever their kind. Proxied poolables is probably key to allow this as
> AFIACS not all DCCs have explicit release().
>
Yes ;)
>
> Yes. Since DCCs don't have a complex lifecycle as Avalon, the Context
> should be available as a component, and not only through a separate
> lifecycle interfaces.
>
Yes, I started already with the Settings object which is not a map (like
the context), but allows typed access to the information.
> Another very Cocoon-specific component is the SourceResolver. Since now
> manage our classloaders, we could benefit from the 3rd constructor
> parameter of URLClassLoader which is a URLStreamHandlerFactory.
>
> That would give access to the rich set of Cocoon-defined protocols using
> java.net.URL. Can you imagine writing "new
> URL("cocoon://blah").openStream()"? That would be cool :-)
>
Yes, indeed - it would make all the source resolving stuff obsolete. Now
that will be fun to explain it to the users.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: svn commit: r157153 - in cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/treeprocessor/sitemap: ErrorHandlerHelper.java PipelineNode.java PipelinesNode.java PipelinesNodeBuilder.java
Sylvain Wallez wrote: Vadim Gritsenko wrote: Ralph Goers wrote: Does this fix mean that handle-errors now works on internal pipelines as well? No, not yet, I need couple of more days. But it means that: ... (1) (2) (2) is now behaving more like (1). Before, I noticed it did not log an error into handled-error log, did not handle ConnectionResetException, etc. Sorry, I may have missed something as I never heard of (2). When is it triggered? If you remember, exception "traverses" error handlers up the invocation tree till it finds the handler which can process exception. So, (2) will be triggered if (1) is missing or did not process an exception. Behaviour is very similar to java exception catch block processing. I see that this feature was introduced before 2.1m1 release [1]. See also [2], [3] for samples showing this off. Also, when no match is found, the of the last was used to handle the ResourceNotFound. Is this still the case? Yes. Vadim [1] http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/components/treeprocessor/sitemap/PipelinesNodeBuilder.java?r1=1.1&r2=1.2&diff_format=h [2] http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/webapp/samples/errorhandling/exception/sitemap.xmap [3] http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/webapp/samples/errorhandling/sitemap.xmap
[GUMP@brutus]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 36 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jfor : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -DEBUG- Dependency on avalon-framework-api exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-12032005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-12032005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-12032005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-12032005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-12032005.jar -Dversion=12032005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-12032005/classes:/usr/local/gump/public/workspace/cocoon/build/cocoon-12032005/deprecated:/usr/local/gump/public/workspace/cocoon/build/cocoon-12032005/test:/usr/local/gump/public/workspace/cocoon/build/cocoon-12032005/mocks:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/tools/loader:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-tr
Re: Flowscript encoding weirdness and a solution
Bertrand Delacretaz wrote:
Le 11 mars 05, à 21:42, Sylvain Wallez a écrit :
Or even a more javadoc-like
// @encoding UTF-8...
Looks good.
Note that IIUC the same problem exists for java source files: unless
the -encoding switch is used for javac, the default platform encoding
is used to compile. Should we add it to our build targets?
I haven't seen problems, but if you have a use case for encoded
strings in flowscript it might apply to java source code as well.
Over time, I have written a small (but useful) library of flowscript
dialog functions inspired by javax.swing.JOptionPane. For example, I can
write:
if (Dialog.confirm("Item already exists. Overwrite it?")) {
overwrite();
} else {
cancel();
}
As you can see, the message is the one displayed to the user, and may
therefore contain accented letters in french. There's also a i18n-ized
version, but setting up a dictionary is overkill for quick
single-language demos and prototypes.
I never encountered this problem in Java classes as they're used as
logic components and therefore don't produce user-readable messages, and
also because encoding problems are solved at compilation time and not at
runtime.
Now with Javaflow+CompilingClassLoader, this problem is certainly likely
to arise. So this should probably be a setting of the CompilingClassloader.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: svn commit: r157153 - in cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/treeprocessor/sitemap: ErrorHandlerHelper.java PipelineNode.java PipelinesNode.java PipelinesNodeBuilder.java
Vadim Gritsenko wrote:
Ralph Goers wrote:
Does this fix mean that handle-errors now works on internal pipelines
as well?
No, not yet, I need couple of more days. But it means that:
...
(1)
(2)
(2) is now behaving more like (1). Before, I noticed it did not log an
error into handled-error log, did not handle ConnectionResetException,
etc.
Sorry, I may have missed something as I never heard of (2). When is it
triggered?
Also, when no match is found, the of the last
was used to handle the ResourceNotFound. Is this still
the case?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
