Re: Vote Result: Releasing 2.1.8 today [was: [Vote] Releasing on friday]
Just as well. I'm still trying to get the portal full screen working properly. If I can't get it working tomorrow I'll have to back the change out as I'll be away next week. Ralph Carsten Ziegeler wrote: To be honest I'm not really happy about this vote: I counted only four votes! I'm still trying to figure out what this result means to us? Anyway, I counted two +1's, one +0.5, one -0.5 and some reservations for releasing today. My decision is to not release today, sorry, but imho there are not enough votes. I'll start another vote on monday for releasing tuesday. Carsten
Re: Vote Result: Releasing 2.1.8 today [was: [Vote] Releasing on friday]
Carsten Ziegeler wrote: To be honest I'm not really happy about this vote: I counted only four votes! I'm still trying to figure out what this result means to us? Anyway, I counted two +1's, one +0.5, one -0.5 and some reservations for releasing today. My decision is to not release today, sorry, but imho there are not enough votes. I'll start another vote on monday for releasing tuesday. yeah, maybe the weekend will give us the necessary inspiration :-) +1 for releasing ASAP, so as soon as the dust settles around Sylvain's last minute changes we should get this puppy out of the door , pronto! Jorg
Re: [M10N] new repo layout
Vadim Gritsenko wrote: I must be stupid. I re-read it [1] twice but still don't see where tags and branches live. :-( well that's because i didn't really specify this :) I'll have a look at the release plugin and find out where and how it creates tags. Jorg
cforms and ajax - circular reference
Hi, In my recent experiments with the new repo layout, I stumbled accross the following problem : 1) cforms depends on ajax for compiling 2) ajax depends on cforms for tests So, using maven, you need to disable tests while packaging ajax if cforms hasn't been packaged yet. The easy way out would be to just merge both blocks together, alternatively we'ld have to organize the tests differently. Thoughts ? Jorg
Re: cforms and ajax - circular reference
Jorg Heymans wrote: Hi, In my recent experiments with the new repo layout, I stumbled accross the following problem : 1) cforms depends on ajax for compiling 2) ajax depends on cforms for tests Uh? What tests? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: cforms and ajax - circular reference
Sylvain Wallez wrote: Uh? What tests? *cough* the ones I copied from CForms and forgot to delete again - sorry for the noise :(
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Antonio Gallardo wrote:
Joerg Heinicke wrote:
On 04.11.2005 02:09, Antonio Gallardo wrote:
Yep. The . and / are already checked in
AbstractWidgetDefinition.setCommonProperties(). We just need to add
:.
Why we need to use a symbol at any cost ? Can we use a simple word
prefix? As cform-[widgetID]?
If you prefix the widget id with a simple word (your proposal) or
suffix it with another one (Sylvain's way), with both you have to
care about the validness of user-chosen ids. To check them easily you
use the unique separator.
Agreed. I think checking a prefix is often faster than checking a
suffix in a string. On the other side a prefix can rest code
readibility. IMHO, the first is better for generated (X)HTML code.
The suffix is also ok. The problem was that a -input suffix is too
generic and seems to broke some javascript code somewhere. ajax is the
main reason for change? If yes, then we can use -cf-input as the
suffix or something like that.
You missed the essence of the problem: if you add a suffix that makes
the generated id a valid widget name, then you have the possibility for
someone to write a form definition where there is a widget that has the
same name than the generated id, then leading to conflicts in the page.
That's why I proposed a character that isn't allowed in widget names.
That way, there is *no* possibility for conflicting ids.
I am just afraid of adding a : in the name. Maybe does not make
sense. Here are some points:
1-It can breaks compatibility somewhere. As sample, all browsers
claims to support CSS standards. The point is at wich level and how
they interpret the word support.
The : has been a valid character for ID in HTML and XML for years:
- http://www.w3.org/TR/REC-html40/types.html#type-id
- http://www.w3.org/TR/REC-xml/#id
The CSS specification says how to use '\' to escape special characters:
- http://www.w3.org/TR/REC-CSS2/syndata.html#q4
So writing a CSS rule for the input of widget foo should be
#foo\:input { }
However, f*cking IE goes in the way, and although it properly escapes
'.' (used for container widgets), it is the only one among the 4
browsers I tested that doesn't understand '\:'. That means that the
'\3A' unicode escape sequence must be used.
To test thoroughly with containers and Ajax, I added the following to
datasource_chooser_template.xml:
style type=text/css
#name { background: #00FF00 }
#name\3Ainput { background: #FF }
#datasource\.SQL\.login { background: #00FF00 }
#datasource\.SQL\.login\3Ainput { background: #FF }
/style
This works in IE 6, Firefox 1.5rc1, Safari 2.0, Opera 8.5.
I also added
a href=#
onclick=document.getElementById('datasource.SQL.login:input').value =
'Yeah'; return falseYeah/a
Works like a charm in all tested browsers.
Now the question is: do you find the \3A quirk to be a blocking issue?
It seems to me that more often inputs in a form will be styled using
classes, so as all inputs share the same styling rule. Also, a way to
avoid the quirk is to use the ancestor selector, which works in all
tested browsers:
#datasource\.SQL\.login input { background: #FF }
2-Being in a xpath 1.0 namespace nightmare for months. I am not sure
if suddenly somebody will need to give a meaning to the :. I know it
is very remote, but...
There's no XPath construct that expects an ID as a litteral. They're
always used as string: [EMAIL PROTECTED]bar:baz] or id(bar:baz)
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
[jira] Created: (COCOON-1678) HTMLArea unable to set target and title to a link
HTMLArea unable to set target and title to a link --- Key: COCOON-1678 URL: http://issues.apache.org/jira/browse/COCOON-1678 Project: Cocoon Type: Bug Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Critical I do the following test on http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea : Type some text in the in a table HTMLArea. Select a portion of the text, click on the link button. Type the address : http://www.google.com Type a title : test Select a target. Submit, The result is : result data1br //data1 data2 html body p a a href=http://www.google.fr;new/a test /p /body /html /data2 /result -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1678) HTMLArea unable to set target and title to a link
[ http://issues.apache.org/jira/browse/COCOON-1678?page=comments#action_12356759 ] Philippe Gassmann commented on COCOON-1678: --- Note : it happens in cocoon forms HTMLArea unable to set target and title to a link --- Key: COCOON-1678 URL: http://issues.apache.org/jira/browse/COCOON-1678 Project: Cocoon Type: Bug Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Critical I do the following test on http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea : Type some text in the in a table HTMLArea. Select a portion of the text, click on the link button. Type the address : http://www.google.com Type a title : test Select a target. Submit, The result is : result data1br //data1 data2 html body p a a href=http://www.google.fr;new/a test /p /body /html /data2 /result -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: cforms and ajax - circular reference
Jorg Heymans wrote: Sylvain Wallez wrote: Uh? What tests? *cough* the ones I copied from CForms and forgot to delete again - sorry for the noise :( No problem, and thanks for the reminder that the Ajax block is lacking some tests :-P Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [M10N] new block layout
Ralph Goers wrote: Jorg Heymans wrote: What if there is no real need for an api block? Do we still add it and define for example the cocoon-core dependency there or do we leave it out alltogether ? I would lead it out altogether. Leaving it in kind of implies that there should be an api and will probably just confuse people. Yepp, if no api, no sub project for it; the same for samples and perhaps impl as well. Apart from that: +1 We should also note that this is the best-practice layout which you should use. But of course you're not forced to use it. For example a block might have to samples where each sample is a separate sub project (think of the portal block with two different portals as samples). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] new block layout
Carsten Ziegeler wrote: Yepp, if no api, no sub project for it; the same for samples and perhaps impl as well. no implementation for a block , is that realistic ? Apart from that: +1 We should also note that this is the best-practice layout which you should use. But of course you're not forced to use it. For example a Indeed, it's the best practice layout. It is also the layout that will be created when doing mvn archetype:create cocoon-block It is up to the block developer then to remove the unnecessary parts and adjust poms accordingly. We should proactively encourage ie enforce following things though : - the block root directory has a pom containing all the modules for that block. - if there is an api module then it should be called api. - impl is the preferred module name if there is only one implementation. Otherwise you're free to choose but an impl suffix is preferred. Same should go for samples. Jorg
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Sylvain Wallez sylvain at apache.org writes:
Now the question is: do you find the \3A quirk to be a blocking issue?
It seems to me that more often inputs in a form will be styled using
classes, so as all inputs share the same styling rule. Also, a way to
avoid the quirk is to use the ancestor selector, which works in all
tested browsers:
#datasource\.SQL\.login input { background: #FF }
Sorry to go back to the origin of this discussion, but wouldn't it then be
better to generate an id for the ajax wrapper element instead of the input
element? Nobody cares about the wrapper element, but nearly everybody about the
styling of the form and so the inputs. So giving them the id they have in the
form definition seems to be more than obvious.
Jörg
[jira] Commented: (COCOON-1678) HTMLArea unable to set target and title to a link
[ http://issues.apache.org/jira/browse/COCOON-1678?page=comments#action_12356761 ] Jeroen Reijn commented on COCOON-1678: -- This is caused by the HTMLCleanerConfiguration found in: http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/datatype/convertor/HtmlCleanerConfiguration.xml?view=markup !-- linking -- element name=a attribute name=href/ /element If you add your attributes, it should work. HTMLArea unable to set target and title to a link --- Key: COCOON-1678 URL: http://issues.apache.org/jira/browse/COCOON-1678 Project: Cocoon Type: Bug Versions: 2.1.8-dev (Current SVN) Reporter: Philippe Gassmann Priority: Critical I do the following test on http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/htmlarea : Type some text in the in a table HTMLArea. Select a portion of the text, click on the link button. Type the address : http://www.google.com Type a title : test Select a target. Submit, The result is : result data1br //data1 data2 html body p a a href=http://www.google.fr;new/a test /p /body /html /data2 /result -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [M10N] new block layout
Jorg Heymans wrote: Carsten Ziegeler wrote: Yepp, if no api, no sub project for it; the same for samples and perhaps impl as well. no implementation for a block , is that realistic ? :) Don't know - but there might be cases where everything your block provides is api. Anyway, let's not discuss this into detail. I think the important part is that this is the suggested best-practice layout and if for any reason you can't follow this layout, you can change it for your own block. Indeed, it's the best practice layout. It is also the layout that will be created when doing mvn archetype:create cocoon-block It is up to the block developer then to remove the unnecessary parts and adjust poms accordingly. We should proactively encourage ie enforce following things though : - the block root directory has a pom containing all the modules for that block. - if there is an api module then it should be called api. - impl is the preferred module name if there is only one implementation. Otherwise you're free to choose but an impl suffix is preferred. Same should go for samples. +1 Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Promoting ApacheCon
Our web site does currently provide no sign of the upcoming ApacheCon in December. Can someone please add the logo there? And perhaps we can list all Cocoon related sessions? Thanks Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1679) New cocoon logo proposal
New cocoon logo proposal Key: COCOON-1679 URL: http://issues.apache.org/jira/browse/COCOON-1679 Project: Cocoon Type: Improvement Reporter: Milan Andrejevic Priority: Trivial Attachments: cocoon.png, cocoon.svg This is just an idea of new cocoon logo. See attachment. Spent some hours to create. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Promoting ApacheCon
On 04.11.2005, at 11:30, Carsten Ziegeler wrote: Our web site does currently provide no sign of the upcoming ApacheCon in December. Can someone please add the logo there? Hmm... I did add it directly to the site and Bertrand committed the change - where is it gone? And perhaps we can list all Cocoon related sessions? Good idea! cheers -- Torsten PGP.sig Description: This is a digitally signed message part
[jira] Commented: (COCOON-1679) New cocoon logo proposal
[ http://issues.apache.org/jira/browse/COCOON-1679?page=comments#action_12356763 ] Sylvain Wallez commented on COCOON-1679: We value you efforts, but honestly this logo is all but readable... New cocoon logo proposal Key: COCOON-1679 URL: http://issues.apache.org/jira/browse/COCOON-1679 Project: Cocoon Type: Improvement Reporter: Milan Andrejevic Priority: Trivial Attachments: cocoon.png, cocoon.svg This is just an idea of new cocoon logo. See attachment. Spent some hours to create. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1679) New cocoon logo proposal
[ http://issues.apache.org/jira/browse/COCOON-1679?page=comments#action_12356766 ] Upayavira commented on COCOON-1679: --- This logo is really quite clever, and I rather like it. However, we've already agreed that we want for the time being to keep our old logo. What we need is more on the web-site skinning front. If you have time/inclination, go to http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/, and show us what you would do to that page to make it look more modern. A plain old HTML/CSS mockup would be enough. New cocoon logo proposal Key: COCOON-1679 URL: http://issues.apache.org/jira/browse/COCOON-1679 Project: Cocoon Type: Improvement Reporter: Milan Andrejevic Priority: Trivial Attachments: cocoon.png, cocoon.svg This is just an idea of new cocoon logo. See attachment. Spent some hours to create. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Joerg Heinicke wrote:
Sylvain Wallez sylvain at apache.org writes:
Now the question is: do you find the \3A quirk to be a blocking issue?
It seems to me that more often inputs in a form will be styled using
classes, so as all inputs share the same styling rule. Also, a way to
avoid the quirk is to use the ancestor selector, which works in all
tested browsers:
#datasource\.SQL\.login input { background: #FF }
Sorry to go back to the origin of this discussion, but wouldn't it then be
better to generate an id for the ajax wrapper element instead of the input
element? Nobody cares about the wrapper element, but nearly everybody about the
styling of the form and so the inputs. So giving them the id they have in the
form definition seems to be more than obvious.
So you suggest:
span id=foo:containerinput name=foo id=foo/span ?
Ajax cares *alot* about the container id, as it's the element that is
updated. If the container's id isn't the widget's full name, it means
we'll have to take into account this special naming for HTML rendering
of widgets everywhere
My impression (but that's only mine) is that access to individual inputs
is mostly needed from JS code (to plug some additional behaviour) rather
than from CSS (use classes to style globally rather than individually),
so the unicode escape quirk is should not really be an issue.
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [M10N] new block layout
Jorg Heymans wrote: What if there is no real need for an api block? Do we still add it and define for example the cocoon-core dependency there or do we leave it out alltogether ? If we don't need an api block we just leave it out. I think our goal should be to have well defined apis (preferably in unique packages) for all important blocks where apis make sense. But we are not there now, and it would require some work to identify the apis and in some cases refactor the blocks to get there. /Daniel
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Sylvain Wallez sylvain at apache.org writes: Sorry to go back to the origin of this discussion, but wouldn't it then be better to generate an id for the ajax wrapper element instead of the input element? Nobody cares about the wrapper element, but nearly everybody about the styling of the form and so the inputs. So giving them the id they have in the form definition seems to be more than obvious. So you suggest: span id=foo:containerinput name=foo id=foo/span ? Yes. Ajax cares *alot* about the container id, as it's the element that is updated. Of course it does, I did not question this. But the CForms user don't care about which id the container has. If the container's id isn't the widget's full name, it means we'll have to take into account this special naming for HTML rendering of widgets everywhere Can't follow you? What do you have in mind? My impression (but that's only mine) is that access to individual inputs is mostly needed from JS code (to plug some additional behaviour) rather than from CSS (use classes to style globally rather than individually), so the unicode escape quirk is should not really be an issue. The manipulated input id might be a minor issue. But if it is possible to avoid the manipulation at all, we should do it. So you probably just need to explain why the container id should be the widget id for simplicity. Jörg
jira karma
Hi all, I just made an account in Jira (mpfingsthorn, email: [EMAIL PROTECTED]), can you add me to the right groups? After two weeks of exams and subsequently needed rest, I am finally ready to dive into cocoon again ;) Thanks a lot! max
Re: [M10N] new repo layout
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: Vadim Gritsenko wrote: IIRC, we already have separated out blocks out of the core, into svn:/cocoon/blocks/ Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. The current structure with trunk/tags/branches under each block will become rather unconvenient as soon as we start to relase and tag things. I would say unavoidable rather than inconvenient. Where would you put block's tags if not under the tags, then? A common tags or rather release area. We only use tags for releases, so it would be clearer to call it releases. Right now you can just check out svn:/cocoon/blocks without any problems, but with a number of tags for each blocks you soon get quite a lot to check out, then you either need to check out each blocks/name/trunk separately or we have to provide a directory with externals to each block trunk. But that was extremely slow when we tried that a while ago. Yes. That was the known issue (iirc i myself brought this up back then), and back then it was recognized that svn:externals is only a temporary measure. Having one external per block is too slow, and having one external for all blocks is not possible, so IMHO best way is to write simple sh/bat file for checking out trunks of all blocks into pre-defined directory structure. Even better if maven somehow can help out here... Either through standard tools or custom plugin... Needing to check out a script for chrcking out Cocoon doesn't seem to increase usability. Not sure that it would work that well with IDEs either. Read the links in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112790057318179w=2 for description of a better way to solve it. It essentially proposes [1] to move ttb's up one level. something like /trunk /cocoon /blocks /axis /forms /tags /cocoon-2.1.8 /cocoon-axis-1.0 /cocoon-forms-1.0 /branches /cocoon-2.1 ... (note: 'releases' in [1] is 'tags' here) Why do you think that this structure should work better? If you want to work on all of Cocoon you just checkout trunk, no need for scripts or externals. If you want to work on a single block or a few of them you just check them out. I would think that it is much easier to use standard ttb layout and let m2 handle each block as separate project, rather than building non standard layout. Jorg says that the layout above works well with m2. If I am not mistaken, following should work with m2 right away: /cocoon-core /trunk pom.xml /cocoon-blocks-axis /trunk pom.xml /cocoon-blocks-forms /trunk pom.xml /cocoon-standard /trunk pom.xml (references cocoon-core, cocoon-forms, cocoon-template) /cocoon /trunk pom.xml (references all blocks) So, what do I miss? See above. Why do you want to reverse this and combine blocks with cocoon core? It doesn't reverese anything, all blocks under /trunk will be independent projects, their interdependencies are completely described in the respective POMs. Where tags and brnaches will live? It is explained in one of the links I asked you to read: http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/[EMAIL PROTECTED] I suggest that you read it. Brett Porter of Maven fame says: http://mail-archives.apache.org/mod_mbox/incubator-oscar-dev/200508.mbox/[EMAIL PROTECTED] about top level trunk. I explained about tags above. For branches it depends, quoting Niclas: Branches are handled differently depending on whether it is an experiment (in which case it is just copied to my laboratory) or it is maintenance of released code, in which case I first copy the release into a temporary area, do the changes and then create a new release make readonly and so forth. Substitute laboratory with whiteboard above. /Daniel
Re: [M10N] new block layout
Le 4 nov. 05, à 11:09, Jorg Heymans a écrit : ...no implementation for a block , is that realistic ? Yes - we already have blocks which contain only samples (core-samples-main for example). I'm no Maven Maven, but I assume it makes sense to handle those blocks using the same layout. -Bertrand
[Documentation] Empty TOC at the top of FAQ pages
Ross or David, on verifying that the FAQ pages are now correctly generated I came across a cosmetic glitch: http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/documentation/faq/gettingstarted/faq-configure-environment.html has an empty TOC at the top. The other FAQ pages all have an extra line, separating the title from the first section. Could either one of you remove the empty TOC and the empty line? I don't mind the line, if that's a big problem, but the empty TOC is rather ugly. Thanks. Bye, Helma
Re: Promoting ApacheCon
Le 4 nov. 05, à 11:47, Torsten Curdt a écrit : On 04.11.2005, at 11:30, Carsten Ziegeler wrote: Our web site does currently provide no sign of the upcoming ApacheCon in December. Can someone please add the logo there? Hmm... I did add it directly to the site and Bertrand committed the change - where is it gone?... I've restored the ApacheCon logo, it was lost when Vadim regenerated the site. I'm a bit lost about how we handle this index.html page, is it meant to be generated? Anyway it's ok now, synced on people.apache.org:/www/cocoon.apache.org, should be online in a few hours. -Bertrand
[EMAIL PROTECTED]: 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 57 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-ajax : Ajax - Utilities and resources for Ajax applications. - 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-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : 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-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - 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-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.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] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-04112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-04112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-04112005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.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: 17 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 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-04112005.jar
[EMAIL PROTECTED]: 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 57 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-ajax : Ajax - Utilities and resources for Ajax applications. - 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-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : 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-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - 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-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.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] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-04112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-04112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-04112005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.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: 17 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 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-04112005.jar
Re: [M10N] new block layout
Bertrand Delacretaz wrote: Yes - we already have blocks which contain only samples (core-samples-main for example). given the new structure, does it still make sense to keep this as a separate top-level block, or can this become a submodule of cocoon-core? I'm no Maven Maven, but I assume it makes sense to handle those blocks using the same layout. I never really thought about what maven actually means :-) Jorg
Re: [M10N] new block layout
Le 4 nov. 05, à 14:49, Jorg Heymans a écrit : Bertrand Delacretaz wrote: Yes - we already have blocks which contain only samples (core-samples-main for example). given the new structure, does it still make sense to keep this as a separate top-level block, or can this become a submodule of cocoon-core? A submodule seems to make sense in this case, but in the general case I think it's good to allow samples-only blocks. Another kind of block is XSLTAL which does not contain java code, only XSLT, a dead simple sitemap configuration and samples. So it's good to remain flexible in the parts that a block contains. I'm no Maven Maven, but I assume it makes sense to handle those blocks using the same layout. I never really thought about what maven actually means :-) This one's not from me, I first heard the term Maven Maven used by Carsten at his ApacheCon EU 2005 talk (which played a big role in moving us to Maven by the way!) -Bertrand
Re: jira karma
On 4 Nov 2005, at 12:31, Max Pfingsthorn wrote: Hi all, I just made an account in Jira (mpfingsthorn, email: [EMAIL PROTECTED]), can you add me to the right groups? After two weeks of exams and subsequently needed rest, I am finally ready to dive into cocoon again ;) Dun! :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Joerg Heinicke wrote: Sylvain Wallez sylvain at apache.org writes: Sorry to go back to the origin of this discussion, but wouldn't it then be better to generate an id for the ajax wrapper element instead of the input element? Nobody cares about the wrapper element, but nearly everybody about the styling of the form and so the inputs. So giving them the id they have in the form definition seems to be more than obvious. So you suggest: span id=foo:containerinput name=foo id=foo/span ? Yes. Ajax cares *alot* about the container id, as it's the element that is updated. Of course it does, I did not question this. But the CForms user don't care about which id the container has. If the container's id isn't the widget's full name, it means we'll have to take into account this special naming for HTML rendering of widgets everywhere Can't follow you? What do you have in mind? This is related to the Ajax BrowserUpdateTransformer: that means that the template would have to produce bu:replace id=foo:container instead of bu:replace id=foo, and thus migrates this :container suffix concern higher in the framework, in places where we don't care of the actual markup language produced, nor if there must be a distinction between container elements and inputs. Also, what about container widgets such as repeater and group ? Shoud ft:repeater id=bardiv... produce div id=bar:container...? This definitely doesn't look good. My impression (but that's only mine) is that access to individual inputs is mostly needed from JS code (to plug some additional behaviour) rather than from CSS (use classes to style globally rather than individually), so the unicode escape quirk is should not really be an issue. The manipulated input id might be a minor issue. But if it is possible to avoid the manipulation at all, we should do it. So you probably just need to explain why the container id should be the widget id for simplicity. My concern is to have consistency in the ids of refresheable units in a page. By refresheable, I mean parts of the page that can be updated using Ajax requests. My feeling is that more and more, application that have some client-side behaviour will make heavy use of Ajax. Consider e.g. the following: div id=content div id=preview Here comes some preview of the current foobar /div div id=news Here comes a periodically updated news feed /div ft:form-template id=sheet ft:widget id=name/ ft:repeater id=phones div Phone numbers: ul ft:repeater-rows li ft:widget id=type/ ft:widget id=number/ /li /ft:repeater-rows /ul /div /ft:repeater /ft:form /div In this template, you can refresh (or animate) elements in a consistent manner using the id, i.e. preview, news, sheet.phones, sheet.phones.1 or sheet.phones.1.number. The :input suffix is visible if you want to access an input using its id, because that would be sheet.phones.1.number:input. But there's another way, which is using its name in the form: document.getElementById(sheet)['phones.1.number']. So, by having the container element having the widget's id we have an overall consistent naming for elements that are manipulated with Ajax, whereas we use widget ids (or full names, actually) in the form's input array to access the input elements. There's still the unicode quirk for CSS, but as I said my feeling is that classes will more often be used to style a group of inputs rather than styling each input individually. future-thinking And this feeling is strengthened by the Ajax trend, where we are more likely to see several instances of a single form definition inserted dynamically in a page. Let's consider CRUD applications: why should we have to go from the list page to an edit page? We just have to open the edit form in place in the list. And the user could even open several of these edit forms at the same time! In that case, we'll have to generate form IDs dynamically, but the input _names_ in the form won't change. That means that CSS rules based on IDs won't be applicable anyway (you'll have to use classes), and that it will be easier to access inputs through the form, with some JS libraries that abstract away the dynamic ID, e.g. AjaxForms.getForm(currentRow).inputs.foo. /future-thinking Thoughts? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [jira] Closed: (COCOON-1594) SQLTransformer swallowing whitespace on substitute-value
Jeremy Quinn (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1594?page=all ] Jeremy Quinn closed COCOON-1594: Resolution: Fixed updated SQLTransformer and TextRecorder to not strip spaces from the SQL Query Is there a sample in databases block to verify the fix? It would be good to have one if it's not there... Vadim
Re: [M10N] new block layout
Jorg Heymans wrote: Bertrand Delacretaz wrote: Yes - we already have blocks which contain only samples (core-samples-main for example). given the new structure, does it still make sense to keep this as a separate top-level block, or can this become a submodule of cocoon-core? I prefer working to make core as small and focused as possible. And then there will not be much left to show in a core specific sample block. Also I think that the basic samples should be more of a demo of what one can with some minimal set of basic blocks using best practices, than a demo of what happens to be in the core block. OTH, the core samples can depend on other blocks, so it doesn't matter that much if it is in trunk/core in an own module. /Daniel
Re: [M10N] new repo layout
Daniel Fagerstrom wrote: I explained about tags above. For branches it depends, quoting Niclas: I understand about tags. Please help me out with branches. Here is current situation, in english: cocoon 2.1 branch depends on cocoon-blocks-xsp 2.1 branch cocoon 2.1 branch depends on cocoon-blocks-forms 1.0 branch cocoon 2.2 branch depends on cocoon-blocks-xsp 2.2 branch cocoon 2.2 branch depends on cocoon-blocks-forms 1.0 branch cocoon 2.2 branch depends on cocoon-blocks-template 1.0 branch cocoon trunk depends on cocoon-blocks-xsp trunk cocoon trunk depends on cocoon-blocks-forms trunk cocoon trunk depends on cocoon-blocks-template trunk How this can be translated into the svn directories, in your view? I can see how standard m2 layout handles it, I don't see how your proposed layout can accomodate this. (Note: as soon as 2.2 is out we will have to branch it out for maintenance and continue 2.3/3.0 development in the trunk. Above shows post 2.2 release situation.) Vadim
[docs] daisy sites not available?
Hi, any reason the sites on http://cocoon.zones.apache.org/daisy/ have been made inaccessible? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Sylvain Wallez wrote:
Antonio Gallardo wrote:
Joerg Heinicke wrote:
On 04.11.2005 02:09, Antonio Gallardo wrote:
Yep. The . and / are already checked in
AbstractWidgetDefinition.setCommonProperties(). We just need to
add :.
Why we need to use a symbol at any cost ? Can we use a simple word
prefix? As cform-[widgetID]?
If you prefix the widget id with a simple word (your proposal) or
suffix it with another one (Sylvain's way), with both you have to
care about the validness of user-chosen ids. To check them easily
you use the unique separator.
Agreed. I think checking a prefix is often faster than checking a
suffix in a string. On the other side a prefix can rest code
readibility. IMHO, the first is better for generated (X)HTML code.
The suffix is also ok. The problem was that a -input suffix is too
generic and seems to broke some javascript code somewhere. ajax is
the main reason for change? If yes, then we can use -cf-input as
the suffix or something like that.
You missed the essence of the problem: if you add a suffix that makes
the generated id a valid widget name, then you have the possibility
for someone to write a form definition where there is a widget that
has the same name than the generated id, then leading to conflicts in
the page. That's why I proposed a character that isn't allowed in
widget names. That way, there is *no* possibility for conflicting ids.
I am just afraid of adding a : in the name. Maybe does not make
sense. Here are some points:
1-It can breaks compatibility somewhere. As sample, all browsers
claims to support CSS standards. The point is at wich level and how
they interpret the word support.
The : has been a valid character for ID in HTML and XML for years:
- http://www.w3.org/TR/REC-html40/types.html#type-id
- http://www.w3.org/TR/REC-xml/#id
The CSS specification says how to use '\' to escape special characters:
- http://www.w3.org/TR/REC-CSS2/syndata.html#q4
So writing a CSS rule for the input of widget foo should be
#foo\:input { }
However, f*cking IE goes in the way, and although it properly escapes
'.' (used for container widgets), it is the only one among the 4
browsers I tested that doesn't understand '\:'. That means that the
'\3A' unicode escape sequence must be used.
Happens to be that the 1 of the 4 tested, the IE is btw, the one with
more than 90% of the market share! :-)
Reading the above, I realized it directly affect the cocoon learning
curve. If we imlement this way a cocoon newbie will need to know that
when they want to code '\:' as '\3A'. I can see a lot of wasted hours
dedicated to debug this. And this directly impact the overall user
perception of cocoon.
Seems to be like another brick in the cocoon learning wall. ;-)
Is there another solution? I like AJAX. I want to have AJAX. I know your
are a brilliant programmer. For this reason I am pretty sure you can
come with a more elegant solution! :-)
WDYT?
Best Regards,
Antonio Gallardo.
Re: svn commit: r330329 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal: coplet/ layout/ layout/renderer/aspect/impl/ layout/renderer/impl/ persistence/castor/
Carsten Ziegeler wrote: Ralph Goers wrote: And what about the case that I added support for - full screen with all the navigation still present? Actually, your changes broke the full screen feature if no tab is available. If you look at the current portal demo, full screen does not work anymore in the anonymous section as there is no tab. OK. I took a more comprehensive approach and believe I have fixed this. Please give it a whirl and let me know if you have any problems. I haven't had a chance to look into your latest changes on trunk. I'll take a look at them and see if it makes sense to me. Ralph
Re: [docs] daisy sites not available?
Bruno Dumon wrote: Hi, any reason the sites on http://cocoon.zones.apache.org/daisy/ have been made inaccessible? no idea, unless someone decided to implement: you need to login to read the docs. Bye, Helma
Re: [docs] daisy sites not available?
Le 4 nov. 05, à 17:53, Bruno Dumon a écrit : any reason the sites on http://cocoon.zones.apache.org/daisy/ have been made inaccessible? No idea, but the sites are here if you login. -Bertrand
Re: [Documentation] Empty TOC at the top of FAQ pages
What's more, there are 4 links in this page, 3 of them not working... On 11/4/05, hepabolu [EMAIL PROTECTED] wrote: Ross or David, on verifying that the FAQ pages are now correctly generated I came across a cosmetic glitch: http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/documentation/faq/gettingstarted/faq-configure-environment.html has an empty TOC at the top. The other FAQ pages all have an extra line, separating the title from the first section. Could either one of you remove the empty TOC and the empty line? I don't mind the line, if that's a big problem, but the empty TOC is rather ugly. Thanks. Bye, Helma -- Patrick Neutiquam erro. Magister mundi sum!
Re: [docs] daisy sites not available?
Bertrand Delacretaz wrote: Le 4 nov. 05, à 17:53, Bruno Dumon a écrit : any reason the sites on http://cocoon.zones.apache.org/daisy/ have been made inaccessible? No idea, but the sites are here if you login. Wow, you guys are really fast. I made the ACL implement the you must log in to edit but realised that this made all the sites disappear from the home page as well (unless you logged in). This took me about 2 minutes to realise and I quickly reverted the change. It should currently be, and is acording to my test just now, behaving as it was prior to my test. I can only assume that you tried to access the site during those two minutes. Ross
Re: [Documentation] Empty TOC at the top of FAQ pages
Patrick Ahles wrote: What's more, there are 4 links in this page, 3 of them not working... That's strange, this page has not been republished since 29 Oct 2005, but other pages are republished every three hours. I'll look into this. Ross
Re: [Documentation] Empty TOC at the top of FAQ pages
hepabolu wrote: Ross or David, on verifying that the FAQ pages are now correctly generated I came across a cosmetic glitch: http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/documentation/faq/gettingstarted/faq-configure-environment.html has an empty TOC at the top. Looks like a side effect of the move of the TOC to the menu. I'll look at it ASAP (should manage over the weekend). Ross
how to update the Cocoon website (Was: Promoting ApacheCon)
Bertrand Delacretaz wrote: Torsten Curdt a ?crit : Carsten Ziegeler wrote: Our web site does currently provide no sign of the upcoming ApacheCon in December. Can someone please add the logo there? Hmm... I did add it directly to the site and Bertrand committed the change - where is it gone?... I've restored the ApacheCon logo, it was lost when Vadim regenerated the site. Yes, and it will happen again next time the top-level site is regenerated. I'm a bit lost about how we handle this index.html page, is it meant to be generated? Anyway it's ok now, synced on people.apache.org:/www/cocoon.apache.org, should be online in a few hours. The whole top-level site is described here. [1] http://wiki.apache.org/cocoon/CocoonWebsiteUpdate ... same as it has always been. Yesterday i upgraded that to use forrest_07. Look at the automated production here. http://forrest.zones.apache.org/ See cocoon-site. I will do the update of the top-level site on Monday (away for the weekend) unless someone beats me to it. I left the instructions at [1] for 2.1 alone, as i don't quite understand what is happening for that. -David
Docs nav menu (was Re: [Documentation] Empty TOC at the top of FAQ pages)
On Nov 4, 2005, at 2:15 PM, Ross Gardler wrote: Looks like a side effect of the move of the TOC to the menu. I'll look at it ASAP (should manage over the weekend). Speakin' of... Would it be possible/desirable to display this page with the first level of cascading nav items pre-expanded? There's enough vertical for this, and it would give a better first glance of what's there instead of having to drill down just to see the first level of stuff (uh... I'll take Door Number 3! :-) —ml—
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 04 November 11:10 PM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-04 11:10:05 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
Other ID naming proposals (was Re: CForms widget ID naming)
Antonio Gallardo wrote:
Sylvain Wallez wrote:
The : has been a valid character for ID in HTML and XML for years:
- http://www.w3.org/TR/REC-html40/types.html#type-id
- http://www.w3.org/TR/REC-xml/#id
The CSS specification says how to use '\' to escape special characters:
- http://www.w3.org/TR/REC-CSS2/syndata.html#q4
So writing a CSS rule for the input of widget foo should be
#foo\:input { }
However, f*cking IE goes in the way, and although it properly escapes
'.' (used for container widgets), it is the only one among the 4
browsers I tested that doesn't understand '\:'. That means that the
'\3A' unicode escape sequence must be used.
Happens to be that the 1 of the 4 tested, the IE is btw, the one with
more than 90% of the market share! :-)
Reading the above, I realized it directly affect the cocoon learning
curve. If we imlement this way a cocoon newbie will need to know that
when they want to code '\:' as '\3A'. I can see a lot of wasted hours
dedicated to debug this. And this directly impact the overall user
perception of cocoon.
Seems to be like another brick in the cocoon learning wall. ;-)
Ok. Even if I don't think these CSS rules will be used often, you're
right that the IE quirk will go in the way of people.
Let's recap the various aspects of the problem:
- generated IDs should not be valid widget full names, to avoid any
potential conflict,
- this isn't just about the input, but about a common rule for all
generated IDs
- an HTML ID can contain letters, digits, underscores '_', colons ':'
and periods '.'.
- because of lookup paths, a widget ID cannot contain '/' nor '.'.
Libraries also add ':' to the forbidden characters.
Since '.' is used as the combination character to build full names, I
thought ':' was a good choice. Now it leads to some (unjustified) fears
about namespace prefixes, and requires a weird CSS syntax.
A thing that wasn't formally said up to now is that a widget name *must*
be a valid HTML/XML identifier. XML is more permissive as it allows
(letter | '_' | ':') as the first character, whereas HTML requires the
first character to be a letter. So a widget name *must* start with a
letter (top-level ones, actually).
So let's make other proposals. Let's consider wiget foo.bar (e.g. a
fd:field in a fd:group) and the ID of its input.
- foo.bar..input: the '.' is doubled, which can never conflict with a
widget's full name
- foo.bar._input: generated element's name starts with a character
that we can forbid as the first character of widget names
I prefer the first one (double '.') which is IMO more readable than the
second.
Other ideas?
Let's make a choice and have 2.1.8 out!
Is there another solution? I like AJAX. I want to have AJAX. I know
your are a brilliant programmer. For this reason I am pretty sure you
can come with a more elegant solution! :-)
Well, as I said in my answer to Jörg, my guess is that Ajax will lead
people to use CSS rules with classes rather than IDs. But I made other
proposals above, so let's choose one.
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [docs] daisy sites not available?
On 04 Nov 2005, at 17:53, Bruno Dumon wrote: Hi, any reason the sites on http://cocoon.zones.apache.org/daisy/ have been made inaccessible? I saw the ACL change notification message this morning but didn't really check what it was, nor who it initiated. Anyway, I now found out who it was (Ross), and I reverted his actions. But it seems like Ross corrected stuff himself in parallel. In the future, even though it is easy to play around with ACL config, we should refrain from doing so without prior warning here. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 12:13 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 12:10:57 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
Re: [docs] daisy sites not available?
Steven Noels wrote: On 04 Nov 2005, at 17:53, Bruno Dumon wrote: Hi, any reason the sites on http://cocoon.zones.apache.org/daisy/ have been made inaccessible? I saw the ACL change notification message this morning but didn't really check what it was, nor who it initiated. Anyway, I now found out who it was (Ross), and I reverted his actions. But it seems like Ross corrected stuff himself in parallel. In the future, even though it is easy to play around with ACL config, we should refrain from doing so without prior warning here. This change had been discussed onlist (must register to edit). However, as you correctly point out I reverted the change after just a couple of minutes since the effect was less than desirable and I don't currently have the time to change the default page displayed when not logged in. I would have annouced it had I left it in place, but in the two minutes it was like that I didn't expect so many people to spot it. I'll announce *before* I experiment in the future ;-) Ross
Re: Docs nav menu (was Re: [Documentation] Empty TOC at the top of FAQ pages)
Mark Lundquist wrote: On Nov 4, 2005, at 2:15 PM, Ross Gardler wrote: Looks like a side effect of the move of the TOC to the menu. I'll look at it ASAP (should manage over the weekend). Speakin' of... Would it be possible/desirable to display this page with the first level of cascading nav items pre-expanded? There's enough vertical for this, and it would give a better first glance of what's there instead of having to drill down just to see the first level of stuff (uh... I'll take Door Number 3! :-) I don't follow you, unless you mean all pages rather than this page. If so, the answer is, unfortunately, yes, but it requires a tweak of the skins stylesheet. If I get time I'll look into it. Ross
Re: [docs] daisy sites not available?
On 05.11.2005 01:39, Ross Gardler wrote: I would have annouced it had I left it in place, but in the two minutes it was like that I didn't expect so many people to spot it. It must have been online much longer. Bruno sent his mail at 17:53, I had a look at it around 21:00 and the page was still not accessible. Don't know why. But this explains why many people have seen it that way. Jörg
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 01:10 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 01:10:11 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 02:11 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 02:10:24 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 03:12 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 03:10:52 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 04:10 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 04:10:12 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 05:10 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 05:10:06 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 06:12 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 06:11:09 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
ForrestBot build for cocoon-site FAILED
Automated build for cocoon-site FAILED Log attached. -- Forrestbot run ended at 05 November 07:10 AM Using Forrest 0.7 Forrestbot administrator: Cocoon developers -- [echo] ... Forrest render START 2005-11-05 07:10:15 ... Rendering docs in /export/home/config/forrestbot-release/conf/work/cocoon-site check-java-version: [echo] This is apache-forrest-0.7 [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: init-plugins: [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [copy] Copying 1 file to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp [echo] Installing plugin: org.apache.forrest.plugin.output.pdf check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-release/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp init: -prepare-classpath: check-contentdir: examine-proj: validation-props: validate-xdocs: [xmlvalidate] 37 file(s) have been successfully validated. [echo] ...validated xdocs validate-skinconf: [xmlvalidate] 1 file(s) have been successfully validated. [echo] ...validated skinconf validate-sitemap: [echo] ...validated project sitemap validate-skins-stylesheets: validate-skins: validate-skinchoice: [echo] ...validated existence of skin 'pelt' validate-stylesheets: validate: site: [echo] Copying the various non-generated resources to site. Warnings will be issued if the optional project resources are not found. This is often the case, because they are optional and so may not be available. [echo] Copying project resources and images to site ... [copy] Warning: /export/home/config/forrestbot-release/conf/work/cocoon-site/webapp/resources not found. [echo] Copying main skin images to site ... [copy] Copying 23 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [copy] Copying 14 files to /var/apache2/htdocs/fr/build/cocoon-site/skin/images [echo] Copying project skin images to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common/images not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt/images not found. [echo] Copying main skin css and js files to site ... [java] [java] cocoon 2.2.0-dev [java] Copyright (c) 1999-2005 Apache Software Foundation. All rights reserved. [java] [java] [java] [copy] Copying 12 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [copy] Copying 6 files to /var/apache2/htdocs/fr/build/cocoon-site/skin [echo] Copying project skin css and js files to site ... [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/common not found. [copy] Warning: /var/apache2/htdocs/fr/src/documentation/skins/pelt not found. [echo] Finished copying the non-generated resources. Now Cocoon will generate the rest ... [echo] Static site will be generated at: /var/apache2/htdocs/fr/build/cocoon-site Note that there are various reasons for build failed messages. * Cocoon will report the status of each document: - in column 1: *=okay X=brokenLink ^=pageSkipped (see FAQ). * Even if only one link is broken, you will still get failed. * Your site would still be generated, but some pages would be broken. * Please check the file: /export/home/config/forrestbot-release/conf/work/cocoon-site/tmp/brokenlinks.xml for any broken links in the generated site. [java] Lazy mode: true [java] Cannot find CatalogManager.properties [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] Lazy mode: true [java] ^
Re: Other ID naming proposals (was Re: CForms widget ID naming)
Sylvain Wallez wrote:
Antonio Gallardo wrote:
Sylvain Wallez wrote:
The : has been a valid character for ID in HTML and XML for years:
- http://www.w3.org/TR/REC-html40/types.html#type-id
- http://www.w3.org/TR/REC-xml/#id
The CSS specification says how to use '\' to escape special characters:
- http://www.w3.org/TR/REC-CSS2/syndata.html#q4
So writing a CSS rule for the input of widget foo should be
#foo\:input { }
However, f*cking IE goes in the way, and although it properly
escapes '.' (used for container widgets), it is the only one among
the 4 browsers I tested that doesn't understand '\:'. That means
that the '\3A' unicode escape sequence must be used.
Happens to be that the 1 of the 4 tested, the IE is btw, the one with
more than 90% of the market share! :-)
Reading the above, I realized it directly affect the cocoon learning
curve. If we imlement this way a cocoon newbie will need to know that
when they want to code '\:' as '\3A'. I can see a lot of wasted hours
dedicated to debug this. And this directly impact the overall user
perception of cocoon.
Seems to be like another brick in the cocoon learning wall. ;-)
Ok. Even if I don't think these CSS rules will be used often, you're
right that the IE quirk will go in the way of people.
Let's recap the various aspects of the problem:
- generated IDs should not be valid widget full names, to avoid any
potential conflict,
- this isn't just about the input, but about a common rule for all
generated IDs - an HTML ID can contain letters, digits, underscores
'_', colons ':' and periods '.'.
- because of lookup paths, a widget ID cannot contain '/' nor '.'.
Libraries also add ':' to the forbidden characters.
Since '.' is used as the combination character to build full names, I
thought ':' was a good choice. Now it leads to some (unjustified)
fears about namespace prefixes, and requires a weird CSS syntax.
A thing that wasn't formally said up to now is that a widget name
*must* be a valid HTML/XML identifier. XML is more permissive as it
allows (letter | '_' | ':') as the first character, whereas HTML
requires the first character to be a letter. So a widget name *must*
start with a letter (top-level ones, actually).
So let's make other proposals. Let's consider wiget foo.bar (e.g. a
fd:field in a fd:group) and the ID of its input.
- foo.bar..input: the '.' is doubled, which can never conflict with
a widget's full name
- foo.bar._input: generated element's name starts with a character
that we can forbid as the first character of widget names
I prefer the first one (double '.') which is IMO more readable than
the second.
Another one, which looks more natural: foo.bar.input.: the trailing
'.' ensures it cannot conflict with a widget's full name
Other ideas?
Let's make a choice and have 2.1.8 out!
Is there another solution? I like AJAX. I want to have AJAX. I know
your are a brilliant programmer. For this reason I am pretty sure you
can come with a more elegant solution! :-)
Well, as I said in my answer to Jörg, my guess is that Ajax will lead
people to use CSS rules with classes rather than IDs. But I made other
proposals above, so let's choose one.
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
