Re: [ANN] Daisy 1.1 release
On 24 Nov 2004, at 21:22, Andreas Kuckartz wrote: snip/ I don't mind continuing this conversation, but I'm not sure whether this list is the place where it should happen - do you? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Cocoon-2.1.X Tests Failure 11/25/04
Automated Cocoon Unit tests failed! Full log file if this unit test run is available here: http://nagoya.apache.org/~vadim/cocoon-test-log-20041125.log Last messages from the log file: == [foreach] reader-mime-type.xml:39: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:41: Running test [Header: Content-type = text/html ... done (1ms) [foreach] reader-mime-type.xml:39: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (114ms) [foreach] reader-mime-type.xml:44: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:46: Running test [Header: Content-type = text/html ... done (1ms) [foreach] reader-mime-type.xml:44: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (35ms) [foreach] reader-mime-type.xml:50: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:52: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:50: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (391ms) [foreach] reader-mime-type.xml:55: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:57: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:55: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (82ms) [foreach] reader-mime-type.xml:61: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:63: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:61: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (20ms) [foreach] reader-mime-type.xml:66: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:68: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:66: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (25ms) [foreach] reader-mime-type.xml:72: Starting http://localhost:1///samples/test/reader-mime-type/test50.html [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = text/html[1;31m Failure: file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:74: message doesn't match because header 'content-type' is not present[m [foreach] ... done (7ms) [foreach] reader-mime-type.xml:72: Finished http://localhost:1///samples/test/reader-mime-type/test50.html (45ms) BUILD FAILED file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: Task at file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: failed Total time: 25 seconds Last messages from the server console: == [EMAIL PROTECTED]: Startup sequence initiated from main() method [EMAIL PROTECTED]: Loaded properties from [/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties] [EMAIL PROTECTED]: Initiating startup sequence... [EMAIL PROTECTED]: Server socket opened successfully in 4 ms. [EMAIL PROTECTED]: Database [index=0, id=0, db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb, alias=] opened sucessfully in 2336 ms. [EMAIL PROTECTED]: Startup sequence completed in 2387 ms. [EMAIL PROTECTED]: 2004-11-25 01:27:51.701 HSQLDB server 1.7.2 is online [EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL [EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly - The database 'db' root directory has been set to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind that if a war upgrade will take place the database will be lost. - Database points to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db - [main] '/db/system/SysSymbols' Set object system_SysConfig - [main] '/db/system/SysConfig' Set document database.xml - [main] '/db/system/SysSymbols' Set object meta_Metas - [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig - Database 'db' successfully opened - Xindice server successfully started parameter = @PARAMETER@ replaceme = replaceme-abc parameter = @PARAMETER@ replaceme = replaceme-123 - VM shutting down with the disk store for cocoon-ehcache-1 still active. The disk store is persistent. Calling dispose... - Database 'db' successfully closed - Scheduler Cocoon_$_Thu_Nov_25_01:27:40_PST_2004 paused. - Scheduler Cocoon_$_Thu_Nov_25_01:27:40_PST_2004 shutting down. - Scheduler Cocoon_$_Thu_Nov_25_01:27:40_PST_2004 paused
[GUMP@brutus]: Project cocoon-block-fop (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-block-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - cocoon-block-fop : Java XML Framework Full details are available at: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop-block.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Bad Dependency. Project: xml-fop-maintenance unknown to *this* workspace -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/rss.xml - Atom: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2425112004, brutus:brutus-public:2425112004 Gump E-mail Identifier (unique within run) #32. -- Apache Gump http://gump.apache.org/ [Instance: brutus]
Re: Client side validation
But then don't you have double validation ? Yes, server side validation must be always guarantee. Client side validation is useful basically for two reasons: 1. avoid unnecessary server load 2. some customer doesn't want page refresh. There are other techniques to avoid page reload, but it's a little bit more complex... Yes, with CJS there wouldn't be long reloads, but many reactive validations and one longer send in the end. I'm curious of what you mean by more complex techniques to avoid reload ? Thanks, I guess double validation has to be then, will you publish your transformer to CJS ? Thanks Tibor
DO NOT REPLY [Bug 32342] - Inconsistent Handling on empty element namespace uri
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32342. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32342 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-25 14:10 --- Fixed it in the one liner way: if (uri == null) uri = ; as suggested by Vadim. The null namespace uri has nothing to do with this bug. The method you quoted is not SAX specific, so it might not even an error in Xalan's DTM. But when SAX events are created out of the DTM, the namespace uri must no longer be null as shown by the link Vadim posted. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
i18n and CForms
Hi All I am finding that the default FormsMessages that come with CForms do not appear to be working in 2.1.7-dev. My default browser locale (I tried both Safari and Firefox) is 'en_US', so should be using context://samples/blocks/forms/messages/FormsMessages.xml. This is not happening, either in my own usage or in the samples for CForms. So for instance, instead of getting the message This field is required. I get general.field-required indicating that the lookup failed. Interestingly, even after I copied FormsMessages.xml to FormsMessages_en_US.xml and restarted Cocoon, it still did not work. I also tried setting Firefox to say my locale was 'fr', it still did not work. The i18n Samples work fine. Any ideas anyone? Can anyone else reproduce this? regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
RE: i18n and CForms
Hi Jeremy, I also had that problem. My guess was that is has something to do with the I18n transformer, which gives a problem if more than one catalogue is configured. If you have only one catalogue, and add the contents of FormsMessages.xml to it, it should work. Bart. -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 3:08 PM To: [EMAIL PROTECTED] Subject: i18n and CForms Hi All I am finding that the default FormsMessages that come with CForms do not appear to be working in 2.1.7-dev. My default browser locale (I tried both Safari and Firefox) is 'en_US', so should be using context://samples/blocks/forms/messages/FormsMessages.xml. This is not happening, either in my own usage or in the samples for CForms. So for instance, instead of getting the message This field is required. I get general.field-required indicating that the lookup failed. Interestingly, even after I copied FormsMessages.xml to FormsMessages_en_US.xml and restarted Cocoon, it still did not work. I also tried setting Firefox to say my locale was 'fr', it still did not work. The i18n Samples work fine. Any ideas anyone? Can anyone else reproduce this? regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks !
Re: i18n and CForms
Hi Bart, This is a problem, as I always use more than one catalogue :) I like to rely on the built-in catalogue for generic validation messages, so that I am always up to date with changes to CForms, and my own catalogue for form-specific labels, hints, help, titles etc. Anyway, I tried copying the contents of FormsMessages.xml to my own catalogue and it still did not work. regards Jeremy On 25 Nov 2004, at 14:08, Bart Molenkamp wrote: Hi Jeremy, I also had that problem. My guess was that is has something to do with the I18n transformer, which gives a problem if more than one catalogue is configured. If you have only one catalogue, and add the contents of FormsMessages.xml to it, it should work. Bart. -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 3:08 PM To: [EMAIL PROTECTED] Subject: i18n and CForms Hi All I am finding that the default FormsMessages that come with CForms do not appear to be working in 2.1.7-dev. My default browser locale (I tried both Safari and Firefox) is 'en_US', so should be using context://samples/blocks/forms/messages/FormsMessages.xml. This is not happening, either in my own usage or in the samples for CForms. So for instance, instead of getting the message This field is required. I get general.field-required indicating that the lookup failed. Interestingly, even after I copied FormsMessages.xml to FormsMessages_en_US.xml and restarted Cocoon, it still did not work. I also tried setting Firefox to say my locale was 'fr', it still did not work. The i18n Samples work fine. Any ideas anyone? Can anyone else reproduce this? regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
RE: i18n and CForms
Hmm that does work for me. I'm using Cocoon 2.1.6-dev (from August 8th, if I'm correct) for that. I thought it was a configuration error on my side when I wanted to use two catalogues (like you, use the forms catalogue to stay up to date), but it didn't work so I simply copied the contents to my own catalogue. Another thing about my configuration: my I18n transformer is declared almost in the root sitemap, so that my whole application is using that configured transformer (so I have to define the catalogue locations only once). I don't think it should make any difference anyway. Hi Bart, This is a problem, as I always use more than one catalogue :) I like to rely on the built-in catalogue for generic validation messages, so that I am always up to date with changes to CForms, and my own catalogue for form-specific labels, hints, help, titles etc. Anyway, I tried copying the contents of FormsMessages.xml to my own catalogue and it still did not work. regards Jeremy
Re: Client side validation
On Thu, 25 Nov 2004 13:33:17 +0100, oceatoon [EMAIL PROTECTED] wrote:
But then don't you have double validation ?
Yes, server side validation must be always guarantee. Client side
validation is useful basically for two reasons:
1. avoid unnecessary server load
2. some customer doesn't want page refresh. There are other techniques
to avoid page reload, but it's a little bit more complex...
Yes, with CJS there wouldn't be long reloads, but many reactive validations
and one longer send in the end. I'm curious of what you mean by more
complex techniques to avoid reload ?
Thanks, I guess double validation has to be then,
will you publish your transformer to CJS ?
Yes, but I don't know where to post it. Current version of transformer
generates one function per widget. The transformer gets the mode
parameter:
= form: checks all fields in one shot, generally in the submit button
= field: checks each field when the focus is lost, using onBlur()
event in javascript
Inside the function:
- if required='true', checks if the value is not null
- if datatype=integer|long, checks the number
- if datatype=double|decimal, checks the number considering also the decimals
- if datatype=date, then checks the date format in the (optional)
format specified in fi:convertor/@pattern
After all single validate functions, the validate_form() function will
be generated with the call to each functions, aggregating the error
fields name in the array returned.
So you can customize the error management with a function like this:
function validate()
{
var results = validate_form();
var msg = ;
for( var i = 0; i results.length; ++i )
{
msg += \nError on filed: + results[i];
}
if( results.length 0 )
alert( Error on validation: + msg );
}
Please, tell me suggestion and improvement to insert at the fly.
Thanks
Tibor
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
Re: Gump and unavailable projects (daisy, nekohtml-dtd)
On 25 Nov 2004, at 15:05, Reinhard Poetz wrote: I've just integrated the HTMLCleaner into Cocoon Forms. Awesome stuff! :-) Anyway, now I have problems defining the correct Gump entries. I use - daisy-htmlcleaner-1.1.jar - daisy-util-1.1.jar - nekohtml-0.9.3.jar - nekodtd-0.1.10.jar AFAIKS at http://brutus.apache.org/gump/public/gump_xref/package_project.html I can only reference nekohtml (the parser). How can cocoon-forms reference the other three projects? We haven't done any Gumpy stuff with Daisy, and we're a bit busy ATM. :-( /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Client side validation
Luca Garulli wrote:
On Thu, 25 Nov 2004 13:33:17 +0100, oceatoon [EMAIL PROTECTED]
wrote:
But then don't you have double validation ?
Yes, server side validation must be always guarantee. Client side
validation is useful basically for two reasons:
1. avoid unnecessary server load
2. some customer doesn't want page refresh. There are other techniques
to avoid page reload, but it's a little bit more complex...
Yes, with CJS there wouldn't be long reloads, but many reactive
validations and one longer send in the end. I'm curious of what you mean
by more complex techniques to avoid reload ?
Thanks, I guess double validation has to be then,
will you publish your transformer to CJS ?
Yes, but I don't know where to post it. Current version of transformer
generates one function per widget. The transformer gets the mode
parameter:
= form: checks all fields in one shot, generally in the submit button
= field: checks each field when the focus is lost, using onBlur()
event in javascript
ok great, so all potential errors are validated instantly as the user leaves
the widget
Inside the function:
- if required='true', checks if the value is not null
- if datatype=integer|long, checks the number
- if datatype=double|decimal, checks the number considering also the
decimals - if datatype=date, then checks the date format in the (optional)
format specified in fi:convertor/@pattern
After all single validate functions, the validate_form() function will
be generated with the call to each functions, aggregating the error
fields name in the array returned.
correct me if I misunderstood, this is for the case if the user didn't enter
some of the widget? in which case they couldn't be singularely validated,
so you return an array of the remaining errors? sounds good :)
So you can customize the error management with a function like this:
function validate()
{
var results = validate_form();
var msg = ;
for( var i = 0; i results.length; ++i )
{
msg += \nError on filed: + results[i];
}
if( results.length 0 )
alert( Error on validation: + msg );
}
Please, tell me suggestion and improvement to insert at the fly.
No pb , but if you send me your xsl's I can integrate them and help debug or
test drive it, and maybe contribute(t dot katelbach at systheo dot com)
Thanks
Tibor
Re: Gump and unavailable projects (daisy, nekohtml-dtd)
Steven Noels wrote: On 25 Nov 2004, at 15:05, Reinhard Poetz wrote: I've just integrated the HTMLCleaner into Cocoon Forms. Awesome stuff! :-) Anyway, now I have problems defining the correct Gump entries. I use - daisy-htmlcleaner-1.1.jar - daisy-util-1.1.jar - nekohtml-0.9.3.jar - nekodtd-0.1.10.jar AFAIKS at http://brutus.apache.org/gump/public/gump_xref/package_project.html I can only reference nekohtml (the parser). How can cocoon-forms reference the other three projects? We haven't done any Gumpy stuff with Daisy, and we're a bit busy ATM. :-( ok. What can I do not to break the Gump build? Any chance to reference already built libraries within our repository? Secondly, who can setup the neko-dtd Gump project? -- Reinhard
HTMLArea in tables
Helma, Derek, Sorry, I got lost in the long thread about HTMLArea: Has anybody of you found a solution for the HTMLArea in tables problem? Everything else works well on my laptop: - HTMLCleaningConvertor (based on NekoHTML and NekoDTD) - two possibilites to configure HTMLArea in templates: a) fi:styling type=htmlarea rows=8 cols=50 conf conf.statusBar = false; conf.sizeIncludesToolbar = false; conf.fullPage = false; conf.toolbar = [ [ bold, italic, separator, subscript, superscript, separator, insertorderedlist, insertunorderedlist, outdent, indent, separator, inserthorizontalrule, separator, copy, cut, paste, space, undo, redo, separator, showhelp] ]; /conf /fi:styling b) fi:styling type=htmlarea rows=8 cols=50 initFunctionmyInit/initFunction /fi:styling -- myInit() function must be available at the client e.g. by overriding forms-samples-styling.xsl - org.apache.cocoon.xml.StringXMLizable (by Bruno) added - improved examples I will commit (and port back to 2.1.7) after solving the tables and the gump issues. -- Reinhard
Re: HTMLArea in tables
Reinhard Poetz wrote: Helma, Derek, Sorry, I got lost in the long thread about HTMLArea: Has anybody of you found a solution for the HTMLArea in tables problem? Found Hugo's and Helma's explanations that the HTMLArea initialization has to be called in body/@onload. Any ideas, how we can solve this? -- Reinhard
Re: HTMLArea in tables
see my previous posting on this topic: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=110076768809731w=2 - Original Message - From: Reinhard Poetz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 25, 2004 5:55 PM Subject: Re: HTMLArea in tables Reinhard Poetz wrote: Helma, Derek, Sorry, I got lost in the long thread about HTMLArea: Has anybody of you found a solution for the HTMLArea in tables problem? Found Hugo's and Helma's explanations that the HTMLArea initialization has to be called in body/@onload. Any ideas, how we can solve this? -- Reinhard
Re: HTMLArea in tables
Frank Taffelt wrote: see my previous posting on this topic: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=110076768809731w=2 Thank you! After reading your message I had the idea of implementing a afterLoadHandler. Seems to work but when implementing client-side Javascript I'm never sure ;-) -- Reinhard
Re: i18n and CForms
Jeremy Quinn wrote:
Hi All
I am finding that the default FormsMessages that come with CForms do
not appear to be working in 2.1.7-dev.
My default browser locale (I tried both Safari and Firefox) is
'en_US', so should be using
context://samples/blocks/forms/messages/FormsMessages.xml.
This is not happening, either in my own usage or in the samples for
CForms.
So for instance, instead of getting the message This field is
required. I get general.field-required indicating that the lookup
failed.
Interestingly, even after I copied FormsMessages.xml to
FormsMessages_en_US.xml and restarted Cocoon, it still did not work.
I also tried setting Firefox to say my locale was 'fr', it still did
not work.
The i18n Samples work fine.
Any ideas anyone?
Are you using the i18n transformer in a subsitemap of the sitemap where
it is declared?
There's currently a problem with components that have relative URLs in
their configuration (the message catalogue location is such an URL) and
that are used in subsitemap.
The problem comes from the fact that the relative context is that of the
sitemap where a component is firstly used, which in the case of
subsitemaps is different from the context where the component was declared.
That can be solved by implementing the multi-relative source resolving
I've been talking about recently, but for now you have to make sure that
the i18n transformer is only used in the sitemap where it is declared.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FormsGenerator vs FormsTransformer
Peter Hunsberger wrote:
On Wed, 24 Nov 2004 23:57:13 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
[catching up the list - guys, you were so verbose lately !]
Reinhard Poetz wrote:
Just wondering why in the examples always the FormsTransformer is used
although the use of the FormsGenerator is possible. Does this have a
special reason?
snip/
Ah, and the FormGenerator can also be used for some webservice-style
clients where no layout is needed.
The way we attack this is to aggregate the output of two generators:
one creates the object model and the other creates the layout model.
Conceptually, a XSLT then walks the object model and annotates it with
the layout data. A second XSLT then takes the combined model and
pumps out the actual xhtml (or whatever). In some cases this simply
means adding class attributes since much of our actual styling is left
to CSS, but in other cases we do create gobs of xhtml...
Looks complex, but you certainly have good reasons for it. So could you
elaborate on this and give some examples of what the layout model and
the annotated model look like?
Thanks,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FormsGenerator vs FormsTransformer
Sylvain Wallez wrote: [catching up the list - guys, you were so verbose lately !] Reinhard Poetz wrote: Just wondering why in the examples always the FormsTransformer is used although the use of the FormsGenerator is possible. Does this have a special reason? The FormsGenerator produces an XML representation of the form, following the hierarchy and ordering defined by the form definition. To produce an HTML page from that document, you either must have a generic stylesheet that will setup a standard (but not nice) layout, or have a specific stylesheet for each form. The FormTransformer takes as input widget references spread in a page structure, meaning you have a specific template for each form. That template can be produced by any kind of generator (file, xsp, jxtg, velocity, etc.) So to have nicely laid out forms, you can use either approach depending if you feel more comfortable with writing an XSL or a template for each form. Seems like most people prefer to write a template :-) Ah, and the FormGenerator can also be used for some webservice-style clients where no layout is needed. Thank you Sylvain! -- Reinhard
Re: [Proposal] review of sitemap component documentation
Thorsten Scherler wrote: Reinhard Poetz escribió: snip/ We also have to consider that we have more independant blocks very soon, means that we have the goal that each block can be released seperatly and IMO it should provide its own docs. snip/ Hello Reinhard, you may want to have a look in the new plugin system of http://forrest.apache.org. The idea behind it is to keep plugins that containing their own documentation. Maybe you can use some of this ideas for the blocks. ...or maybe cocoon can adopt the idea of plugins for blocks. ;-) Thank you. Learning more about Maven and Forrest plugins are on my todo list before I continue with BlockBuilder/Deployer development. -- Reinhard
Re: i18n and CForms
Thanks for your response Sylvain. On 25 Nov 2004, at 18:36, Sylvain Wallez wrote: Jeremy Quinn wrote: Hi All I am finding that the default FormsMessages that come with CForms do not appear to be working in 2.1.7-dev. My default browser locale (I tried both Safari and Firefox) is 'en_US', so should be using context://samples/blocks/forms/messages/FormsMessages.xml. This is not happening, either in my own usage or in the samples for CForms. So for instance, instead of getting the message This field is required. I get general.field-required indicating that the lookup failed. Interestingly, even after I copied FormsMessages.xml to FormsMessages_en_US.xml and restarted Cocoon, it still did not work. I also tried setting Firefox to say my locale was 'fr', it still did not work. The i18n Samples work fine. Any ideas anyone? Are you using the i18n transformer in a subsitemap of the sitemap where it is declared? I was originally. There's currently a problem with components that have relative URLs in their configuration (the message catalogue location is such an URL) and that are used in subsitemap. I remembered something about that. The problem comes from the fact that the relative context is that of the sitemap where a component is firstly used, which in the case of subsitemaps is different from the context where the component was declared. My top-level sitemap and all of my subsitemaps are in the same folder. That can be solved by implementing the multi-relative source resolving I've been talking about recently, but for now you have to make sure that the i18n transformer is only used in the sitemap where it is declared. I am not 100% sure what multi-relative source resolving means, I will read back through the lists. Meanwhile . In order to simplify the issue, I have move all i18nTransformer and catalogue declarations to my project's top-level sitemap (there are no higher i18nTransformer declarations). It looks like this: map:transformer name=i18n src=org.apache.cocoon.transformation.I18nTransformer catalogues default=forms catalogue id=main name=main location=content/i18n/ catalogue id=editor name=editor location=content/i18n/ catalogue id=config name=configuration location=content/i18n/ catalogue id=event name=event location=content/i18n/ catalogue id=sched name=scheduler location=content/i18n/ catalogue id=samp name=samples location=content/i18n/ catalogue id=webdav name=webdav location=content/i18n/ catalogue id=forms name=FormsMessages location=context://samples/blocks/forms/messages/ /catalogues cache-at-startupfalse/cache-at-startup /map:transformer This project is mounted externally to Cocoon, hence the context:// URI for FormsMessages. Each of my pages that use the custom i18n work fine, they all refer to their catalogue like this: i18n:text i18n:catalogue=editornew-component.filename.label/i18n:text or from FlowScript like this: form.lookupWidget(messages).addMessage(new I18nMessage(error, editor)); Here is an example of the errors I am seeing. Scenario: default locale of the site is 'it'. my browser's default locale is 'en_US' my custom i18n message files are supplied both as '[filename]_en.xml' and '[filename]_it.xml' 1. I load a page that has a form in it, that uses messages from 'editor_*.xml': INFO(2004-11-25) 18:52.12:049 [core.i18n-bundles] (/gov-cms/editor/new-component.html) PoolThread-4/XMLResourceBundleFactory: Resource not found: editor, locale: , bundleName: file:/Users/jerm/Development/Checkouts/Pronetics/scratchpad/gov-cms/ application/webapp/content/i18n/editor.xml. Exception: org.apache.cocoon.ResourceNotFoundException: Resource not found.: org.apache.excalibur.source.SourceNotFoundException: file:/Users/jerm/Development/Checkouts/Pronetics/scratchpad/gov-cms/ application/webapp/content/i18n/editor.xml doesn't exist. Fine so far . editor_en.xml was found, and works fine. 2. I submit the form in such a way that will invoke validation errors, the first error message about the missing '}' is highly suspicious to me. I have no such characters in my messages (not using that functionality, and the curly-brace pairs in FormsMessages.xml all seem to be well formed). The errors below are what happens when the CForms i18n does not work. ERROR (2004-11-25) 18:54.24:624 [core.i18n-bundles] (/gov-cms/editor/new-component.html) PoolThread-4/XMLResourceBundleFactory: Resource loading failed org.xml.sax.SAXException: Unclosed '}' at org.apache.cocoon.xml.ParamSaxBuffer.characters(ParamSaxBuffer.java:76) at org.apache.cocoon.i18n.XMLResourceBundle$SAXContentHandler.characters(XM LResourceBundle.java:232) at org.apache.xerces.parsers.AbstractSAXParser.characters(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknow n Source) at
Re: i18n and CForms
On 25 Nov 2004, at 19:38, Jeremy Quinn wrote: Thanks for your response Sylvain. On 25 Nov 2004, at 18:36, Sylvain Wallez wrote: Are you using the i18n transformer in a subsitemap of the sitemap where it is declared? I was originally. OK, I misunderstood that on first reading .. I had the i18nTransformer declared in each sitemap that used it (with only the catalogues declared that that sitemap used), this was the case for both top-level and sub sitemaps. I have moved all declarations to the top-level now. The problem did not change between these two setups. All sitemaps are in the same folder anyway. Even the samples for CForms are not working on my machine. I hope that is clearer ;) regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
RE: HTMLArea in tables
Reinhard, I modified the *-styling-*.xsl files to change the body/@onload call. They were in the zip I sent you. Strangely enough I had it working flawlessly with a short page of my own, both in IE and in Firefox, but when I later tested it in a long form (20+ widgets with one or more HTMLareas) in IE it worked for HTMLarea containing text, but not for empty forms. :-( In one occasion I even noticed that the HTMLarea appeared several seconds later! Firefox was at least consistent (i.e. it works). I'm sorry I don't have the time to extensively test various ideas posted on the HTMLare forum: - change the offsetleft and offsetwidth settings (con: this might not be possible if your web layout wants it different) - add an iframe in the HTML code, this should solve the timing problem (I haven't yet figured out where exactly that should be put) - set style:width=100% for the textarea. I've tried something similar and it didn't work. Maybe it does in combination with my initfunction in body/@onload Re the modified forms styling files: As you can see it builds an htmlarea_onload function that calls the initfunctions of each HTMLarea. What I noticed when adding this function to body/@onload is that the XSL template doesn't work as expected: xsl:template match=body xsl:attribute name=@onloadxsl:value-of select=@onload//xsl:attribute /xsl:template Where XXX is forms_onload in the field-styling.xsl and htmlarea_onload in the htmlarea-styling.xsl Well, this doesn't work: the value of the attribute is replaced without the previous version being inserted. For now I fixed it by simply adding the forms_onload function in the htmlarea-styling.xsl as well. Bye, Helma -Original Message- From: Reinhard Poetz [mailto:[EMAIL PROTECTED] Sent: Thursday, 25 November 2004 17:29 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: HTMLArea in tables Helma, Derek, Sorry, I got lost in the long thread about HTMLArea: Has anybody of you found a solution for the HTMLArea in tables problem? Everything else works well on my laptop: - HTMLCleaningConvertor (based on NekoHTML and NekoDTD) - two possibilites to configure HTMLArea in templates: a) fi:styling type=htmlarea rows=8 cols=50 conf conf.statusBar = false; conf.sizeIncludesToolbar = false; conf.fullPage = false; conf.toolbar = [ [ bold, italic, separator, subscript, superscript, separator, insertorderedlist, insertunorderedlist, outdent, indent, separator, inserthorizontalrule, separator, copy, cut, paste, space, undo, redo, separator, showhelp] ]; /conf /fi:styling b) fi:styling type=htmlarea rows=8 cols=50 initFunctionmyInit/initFunction /fi:styling -- myInit() function must be available at the client e.g. by overriding forms-samples-styling.xsl - org.apache.cocoon.xml.StringXMLizable (by Bruno) added - improved examples I will commit (and port back to 2.1.7) after solving the tables and the gump issues. -- Reinhard
I got my account !!!!!!
Hi all, I received my account information and it works! Thank you to everyone who helped to make this happen! In the mail I got it said: Please note that until the Project Management Committee responsible for the project to which you were given group membership actually grants you access to the relevant source code modules, you won't be able to commit anything. My account is tschlabach. Does anyone need to do anything before I can access the respository? Regards, Torsten
Re: I got my account !!!!!!
[EMAIL PROTECTED] dijo: Hi all, I received my account information and it works! Thank you to everyone who helped to make this happen! Congratulations! Best Regards, Antonio Gallardo.
RE: HTMLArea in tables
Frank, Sorry I didn't respond to your mail, but I have indeed tested your solution. Unfortunately I couldn't get it to work. Bye, Helma -Original Message- From: Frank Taffelt [mailto:[EMAIL PROTECTED] Sent: Thursday, 25 November 2004 18:15 To: [EMAIL PROTECTED] Subject: Re: HTMLArea in tables see my previous posting on this topic: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=110076768809731w=2 - Original Message - From: Reinhard Poetz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 25, 2004 5:55 PM Subject: Re: HTMLArea in tables Reinhard Poetz wrote: Helma, Derek, Sorry, I got lost in the long thread about HTMLArea: Has anybody of you found a solution for the HTMLArea in tables problem? Found Hugo's and Helma's explanations that the HTMLArea initialization has to be called in body/@onload. Any ideas, how we can solve this? -- Reinhard
Re: HTMLArea in tables
[EMAIL PROTECTED] wrote: Reinhard, I modified the *-styling-*.xsl files to change the body/@onload call. They were in the zip I sent you. Strangely enough I had it working flawlessly with a short page of my own, both in IE and in Firefox, but when I later tested it in a long form (20+ widgets with one or more HTMLareas) in IE it worked for HTMLarea containing text, but not for empty forms. :-( In one occasion I even noticed that the HTMLarea appeared several seconds later! Firefox was at least consistent (i.e. it works). I'm sorry I don't have the time to extensively test various ideas posted on the HTMLare forum: - change the offsetleft and offsetwidth settings (con: this might not be possible if your web layout wants it different) - add an iframe in the HTML code, this should solve the timing problem (I haven't yet figured out where exactly that should be put) - set style:width=100% for the textarea. I've tried something similar and it didn't work. Maybe it does in combination with my initfunction in body/@onload Re the modified forms styling files: As you can see it builds an htmlarea_onload function that calls the initfunctions of each HTMLarea. What I noticed when adding this function to body/@onload is that the XSL template doesn't work as expected: xsl:template match=body xsl:attribute name=@onloadxsl:value-of select=@onload//xsl:attribute /xsl:template Where XXX is forms_onload in the field-styling.xsl and htmlarea_onload in the htmlarea-styling.xsl Well, this doesn't work: the value of the attribute is replaced without the previous version being inserted. For now I fixed it by simply adding the forms_onload function in the htmlarea-styling.xsl as well. I implemented an afterload-handler which is called right before the body end element. This ensures that the whole page is processed and all tables sizes are calculated. It works with IE6 (WinXP SP2) and Firefox 1.0. -- Reinhard
RE: HTMLArea in tables
I implemented an afterload-handler which is called right before the body end element. This ensures that the whole page is processed and all tables sizes are calculated. It works with IE6 (WinXP SP2) and Firefox 1.0. Right, now that you've explained I remember reading something similar on the HTMLarea forum. Does this mean the extended HTMLarea sample is now in SVN? Bye, Helma
Re: I got my account !!!!!!
bash-2.05b$ groups tschlabach tschlabach apcvs lenya This should mean you have commit access to lenya. Only one way to be sure... :) Congrats, Geoff Howard On Thu, 25 Nov 2004 14:39:04 -0600 (CST), Antonio Gallardo [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] dijo: Hi all, I received my account information and it works! Thank you to everyone who helped to make this happen! Congratulations! Best Regards, Antonio Gallardo.
RE: i18n and CForms
Hi, I noticed this too. I assumed my setup was not correct, but the default=forms doesn't work for me either and my Cocoon version stems from around the time of the 2.1.6 release. My setup: I18n declared and used in same sitemap (subsitemap from default root sitemap). Bye, Helma -Original Message- From: Jeremy Quinn [mailto:[EMAIL PROTECTED] Sent: Thursday, 25 November 2004 20:54 To: [EMAIL PROTECTED] Subject: Re: i18n and CForms On 25 Nov 2004, at 19:38, Jeremy Quinn wrote: Thanks for your response Sylvain. On 25 Nov 2004, at 18:36, Sylvain Wallez wrote: Are you using the i18n transformer in a subsitemap of the sitemap where it is declared? I was originally. OK, I misunderstood that on first reading .. I had the i18nTransformer declared in each sitemap that used it (with only the catalogues declared that that sitemap used), this was the case for both top-level and sub sitemaps. I have moved all declarations to the top-level now. The problem did not change between these two setups. All sitemaps are in the same folder anyway. Even the samples for CForms are not working on my machine. I hope that is clearer ;) regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks !
Re: I got my account !!!!!!
Antonio Gallardo escribió: [EMAIL PROTECTED] dijo: Hi all, I received my account information and it works! Thank you to everyone who helped to make this happen! Congratulations! Best Regards, Antonio Gallardo. Yeah. hip,hip, horray! :) regards -- thorsten Together we stand, divided we fall Hey you (Pink Floyd)
Re: HTMLArea in tables
[EMAIL PROTECTED] wrote: I implemented an afterload-handler which is called right before the body end element. This ensures that the whole page is processed and all tables sizes are calculated. It works with IE6 (WinXP SP2) and Firefox 1.0. Right, now that you've explained I remember reading something similar on the HTMLarea forum. Does this mean the extended HTMLarea sample is now in SVN? Bye, Helma Probably tomorrow, but it will break the gump build of cforms because I don't know how to set all references correctly. -- Reinhard
Re: i18n and CForms
Jeremy Quinn wrote:
snip/
2. I submit the form in such a way that will invoke validation
errors, the first error message about the missing '}' is highly
suspicious to me. I have no such characters in my messages (not using
that functionality, and the curly-brace pairs in FormsMessages.xml
all seem to be well formed). The errors below are what happens when
the CForms i18n does not work.
ERROR (2004-11-25) 18:54.24:624 [core.i18n-bundles]
(/gov-cms/editor/new-component.html)
PoolThread-4/XMLResourceBundleFactory: Resource loading failed
org.xml.sax.SAXException: Unclosed '}'
at
org.apache.cocoon.xml.ParamSaxBuffer.characters(ParamSaxBuffer.java:76)
at
org.apache.cocoon.i18n.XMLResourceBundle$SAXContentHandler.characters(XM
LResourceBundle.java:232)
at org.apache.xerces.parsers.AbstractSAXParser.characters(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknow
n Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis
patcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno
wn Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:296)
at
org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:
123)
at
org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:
166)
at
org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java: 98)
at
org.apache.cocoon.i18n.XMLResourceBundle.load(XMLResourceBundle.java: 299)
Mmmmh... are you sure no message file uses parameters, or that a message
contains an opening brace? Unfortunately, the ParamSaxBuffer class isn't
friendly enough though to tell us _what_ file is faulty. Using the
Locator object could reveal it!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Gump and unavailable projects (daisy, nekohtml-dtd)
Reinhard Poetz wrote: I've just integrated the HTMLCleaner into Cocoon Forms. Awesome stuff! Anyway, now I have problems defining the correct Gump entries. I use - daisy-htmlcleaner-1.1.jar - daisy-util-1.1.jar - nekohtml-0.9.3.jar - nekodtd-0.1.10.jar AFAIKS at http://brutus.apache.org/gump/public/gump_xref/package_project.html I can only reference nekohtml (the parser). How can cocoon-forms reference the other three projects? Look at the very bottom of the gump.xml descriptor, you can add them as local packaged projects. Note that nekohtml already exists (just grep for neko on http://brutus.apache.org/gump/public/gump_xref/output_id_project.html ) -- Stefano.
Re: I got my account !!!!!!
Geoff Howard wrote: bash-2.05b$ groups tschlabach tschlabach apcvs lenya This should mean you have commit access to lenya. Only one way to be sure... :) No, it does not :) Lenya is in SVN http://svn.apache.org/repos/asf/lenya/ Which does not use unix groups but svn-authorization file (which I probably have no access to). I see that tschlabach is already there. So last step for Torsten is to login to minotaur.apache.org and use svnpasswd command to create SVN password, and then checkout lenya from svn using https: url. Vadim
Re: I got my account !!!!!!
Vadim Gritsenko wrote: Geoff Howard wrote: bash-2.05b$ groups tschlabach tschlabach apcvs lenya This should mean you have commit access to lenya. Only one way to be sure... :) No, it does not :) Lenya is in SVN http://svn.apache.org/repos/asf/lenya/ Which does not use unix groups but svn-authorization file (which I probably have no access to). I gather that PMC chairs are the only ones. I see that tschlabach is already there. So last step for Torsten is to login to minotaur.apache.org and use svnpasswd command to create SVN password, and then checkout lenya from svn using https: url. This discussion should really be happening on the [EMAIL PROTECTED] list with the Lenya PMC helping. But Torsten, we will all help to answer your Qs wherever you are. Do you know about: http://www.apache.org/dev/committers.html http://www.apache.org/dev/version-control.html --David
Re: Planning Cocoon's future
Hi Ugo: Ugo Cei dijo: Il giorno 23/nov/04, alle 11:53, Reinhard Poetz ha scritto: release date of 2.1.7 (with or without a stable cForms block): February 2005? Nah. I propose Christmas 2004 ;-). Now, seriously, we should aim for a shorter release cycle. There is already the upgrade to DELI that Antonio wanted to commit shortly before the latest release, but was delayed. Thanks for the big hint. I will try to review the patch and commit it over the weekend. ;-) Best Regards, Antonio Gallardo
DO NOT REPLY [Bug 28360] - [PATCH] DateInputModule's getAttribute() should fetch format from attribute-name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28360. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28360 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 08:52 --- I have implemented the change as described. Please review and test and then close. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
