[jira] Created: (COCOON-1853) blocks-tobeconverted
blocks-tobeconverted Key: COCOON-1853 URL: http://issues.apache.org/jira/browse/COCOON-1853 Project: Cocoon Type: Bug Components: Blocks: Validation Versions: 2.1.10-dev (current SVN) Reporter: Ben Pope Moving blocks-tobeconverted, breaks the svn:external in 2.1 dev. Also, removing WEB-INF also breaks it, and I don't think the samples are quite right, either. -- 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-1838) Always use 3-digit version number
[ http://issues.apache.org/jira/browse/COCOON-1838?page=comments#action_12412136 ] Ben Pope commented on COCOON-1838: -- A while go I had a look at all the pom files, but I wasn't entirely sure how they worked with respect to the missing version numbers, you've just clarified that. I have to say that I didn't see any 1 digit version numbers that were not just listing other modules, so I think it's fair to close this issue on that basis. I do recall seeing some 2 digit version numbers, so it migth be worth checking for those and fixing them. Always use 3-digit version number - Key: COCOON-1838 URL: http://issues.apache.org/jira/browse/COCOON-1838 Project: Cocoon Type: Improvement Components: - Build System: Maven Versions: 2.2-dev (Current SVN) Reporter: Ben Pope Priority: Trivial Attachments: version.patch Continuing the theme of Carsten in commit 394739 (This sits on top of my other patch JIRA 1837, so 1 or two files might fail if that one is not commited) License granted to ASF. The patch is essentially a search and replace of version1-SNAPSHOT/version and version1.0-SNAPSHOT/version to version1.0.0-SNAPSHOT/version -- 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: Running Cocoon in OSGi mode
On 24/04/06, Reinhard Poetz [EMAIL PROTECTED] wrote: I checked in my changes on cocoon-core. This should solve all the reported problems. Could you try it again please? I get a 404 page, but otherwise everything seems to work. Ben Pope -- I'm not just a number. To many, I'm known as a string...
[jira] Commented: (COCOON-1838) Always use 3-digit version number
[ http://issues.apache.org/jira/browse/COCOON-1838?page=comments#action_12375010 ] Ben Pope commented on COCOON-1838: -- Ah, thats a different story... much harder! There are a few places where there is a missing groupId or version number altogether. Is there a maven tool that can check these things or summarise? I thought it would be an easy patch, but I'm mistaken, I don;t have the time right now to manually check everything, nor do I know if, for example, minimal webapp should be 1 or 1.0.0. Always use 3-digit version number - Key: COCOON-1838 URL: http://issues.apache.org/jira/browse/COCOON-1838 Project: Cocoon Type: Improvement Components: - Build System: Maven Versions: 2.2-dev (Current SVN) Reporter: Ben Pope Priority: Trivial Attachments: version.patch Continuing the theme of Carsten in commit 394739 (This sits on top of my other patch JIRA 1837, so 1 or two files might fail if that one is not commited) License granted to ASF. The patch is essentially a search and replace of version1-SNAPSHOT/version and version1.0-SNAPSHOT/version to version1.0.0-SNAPSHOT/version -- 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] Updated: (COCOON-1837) [lcocoon-licenses] New dependancy on cocoon-licensesbreaks trunk because cocoon-licenses is not a module!
[ http://issues.apache.org/jira/browse/COCOON-1837?page=all ] Ben Pope updated COCOON-1837: - Attachment: legal.patch Corrects the parent artifactId, grants license to ASF. [lcocoon-licenses] New dependancy on cocoon-licensesbreaks trunk because cocoon-licenses is not a module! - Key: COCOON-1837 URL: http://issues.apache.org/jira/browse/COCOON-1837 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Reporter: Ben Pope Priority: Minor Attachments: legal.patch, legal.patch The new dependancy on cocoon-licenses breaks because cocoon-licenses is not set to be built. Patch attached which creates a pom.xml for commons which includes legal, and adds it as a module for the root pom.ml -- 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] Created: (COCOON-1838) Always use 3-digit version number
Always use 3-digit version number - Key: COCOON-1838 URL: http://issues.apache.org/jira/browse/COCOON-1838 Project: Cocoon Type: Improvement Components: - Build System: Maven Versions: 2.2-dev (Current SVN) Reporter: Ben Pope Priority: Trivial Attachments: version.patch Continuing the theme of Carsten in commit 394739 (This sits on top of my other patch JIRA 1837, so 1 or two files might fail if that one is not commited) License granted to ASF. The patch is essentially a search and replace of version1-SNAPSHOT/version and version1.0-SNAPSHOT/version to version1.0.0-SNAPSHOT/version -- 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: upgrade jakarta-bcel ?
On 11/04/06, Torsten Curdt [EMAIL PROTECTED] wrote: Rebuilt, and it compiled ok. I also ran the webapp, and nothing spurious happened, but I'm not sure where bcel is used, so I don't know if that tested it or not. ...at least javaflow uses it. Thanks for testing! Glad to be of service. Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: upgrade jakarta-bcel ?
On 10/04/06, Antonio Gallardo [EMAIL PROTECTED] wrote: Jorg Heymans escribió: Hi, At the moment we are using jakarta-bcel-20040329.jar . Is there any reason not to upgrade to a more recent 5.0 or 5.1 ? Moving to 5.0 or 5.1 means downgrade. http://jakarta.apache.org/bcel/news.html With a little digging around, 5.2RC1 has recently been released: http://article.gmane.org/gmane.comp.jakarta.bcel.devel/1052 And they're looking for testers, perhaps it is still time to upgrade? Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: upgrade jakarta-bcel ?
On 10/04/06, Antonio Gallardo [EMAIL PROTECTED] wrote: Ben Pope escribió: With a little digging around, 5.2RC1 has recently been released: http://article.gmane.org/gmane.comp.jakarta.bcel.devel/1052 And they're looking for testers, perhaps it is still time to upgrade? Thanks for the link. This link points to the Torsten site in apache. I will not consider it an official release until it shows up in the bcel main site. I guess Jorg is trying to solve maven2 dependencies hell. Using this newer release will be the same as the current one for his goal. Understood, I was pointing out that a newer release is on the horizon, that it might better prepare cocoon for 5.2 when it does arrive, as well as providing a testing ground for bcel. Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: upgrade jakarta-bcel ?
On 10/04/06, Ben Pope [EMAIL PROTECTED] wrote: On 10/04/06, Antonio Gallardo [EMAIL PROTECTED] wrote: Ben Pope escribió: With a little digging around, 5.2RC1 has recently been released: http://article.gmane.org/gmane.comp.jakarta.bcel.devel/1052 And they're looking for testers, perhaps it is still time to upgrade? Thanks for the link. This link points to the Torsten site in apache. I will not consider it an official release until it shows up in the bcel main site. I guess Jorg is trying to solve maven2 dependencies hell. Using this newer release will be the same as the current one for his goal. Understood, I was pointing out that a newer release is on the horizon, that it might better prepare cocoon for 5.2 when it does arrive, as well as providing a testing ground for bcel. In case you or anybody else is interested, I downloaded bcel-5.2rc1.zip, extracted bcel-5.2rc1.jar, ran: mvn install:install-file -DgroupId=jakarta-bcel -DartifactId=jakarta-bcel -Dversion=5.2rc1 -Dpackaging=jar -Dfile=./bcel-5.2rc1.jar Changed: core/cocoon-core/pom.xml: Index: pom.xml === --- pom.xml (revision 393100) +++ pom.xml (working copy) @@ -313,7 +313,7 @@ dependency groupIdjakarta-bcel/groupId artifactIdjakarta-bcel/artifactId - version20040329/version + version5.2rc1/version /dependency dependency groupIdorg.springframework/groupId Rebuilt, and it compiled ok. I also ran the webapp, and nothing spurious happened, but I'm not sure where bcel is used, so I don't know if that tested it or not. Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: upgrade jakarta-bcel ?
On 11/04/06, Antonio Gallardo [EMAIL PROTECTED] wrote: Thanks Ben. FYI, in xalan, bcel is used for xsltc. So I guess it's used in cached pipelines, and I guess the default pipeline is cached, so I guess it was tested ;) Ben Pope -- I'm not just a number. To many, I'm known as a string...
[2.2] Webapp
Hi everybody, I've just read the simple release plan, and I feel obliged to make some comments. I think the main doubts about the stabilty of trunk is that it isn't possible to get the samples running. The only way to solve the problem of the lack of confidence in trunk is to get the samples working. Without the samples, I personally find it very hard to try 2.2, let alone get stuck in proper. At the moment (well, since I started trying out 2.2 about 6 weeks ago, up until last weekend) I have not been able to get any samples up and running, despite following the provided instructions, and this is forms and templates samples, pretty core stuff I'm sure we're all agreed. I hear over and over again how easy it would be to create a script that copies the blocks over, but I can't do it manually with any success, so even if I could write the Ant Task, M2 Mojo or whatever, I doubt I'd succeed. Nobody has written this script yet. Don't get me wrong, I think the progress so far is great, I love the idea of OSGi, Spring, blocks and Maven, and everybody has done a great job. However, I think something has gone wrong. There seems to be lots of people doing their own thing, everybody insists that that what they have done doesn't break anything, but I can't make it work. I'm pretty sure I'm not alone. I think there needs to be some effort towards getting the samples back up and running. I know, it will divert effort away from your own projects, but at the moment the lack of samples and working test cases are now making development harder and introducing more and more problems. Can the few people that are able, please consider getting these two things back up and running, I think that is the only way to prevent others from wanting to branch trunk, go back to ant, and generally shy away from development on or with 2.2. How much effort is really required, when you consider how much gain can be had in terms of additional help and testing, as well as everybody working towards the same goal? Thanks for your time. Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: Using trunk
On 25/02/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Carsten Ziegeler schrieb: Daniel Fagerstrom wrote: So the problems this far seem to be that default types not are handled in a back compatible ways for component includes and that components are not inherited properly to subsitemaps. Hopefully Carsten have an idea about what is going on. I'll have a look at it; I guess the included configs contain own definitions for sitemap components which simply overwrite the definition of the core and thus they overwrite the default components as well. I've just committed a fix which should solve this issue. It seems to fix the first bit of it. As before I've added the following to the pom: cocoon-template-impl cocoon-forms-impl cocoon-ajax-impl cocoon-forms-sample cocoon-ajax-sample There was no mention in Daniels original post of the requirement to copy: src/gump/module.xml to cocoon-webapp/src/main/webapp/samples/blocks After that, I could navigate to: http://localhost:/cocoon-webapp/samples/ which redirects me to: http://localhost:/cocoon-webapp/samples/blocks/main-samples Where I see the forms and ajax samples pages. Clicking on the forms link: http://localhost:/cocoon-webapp/samples/blocks/forms/ I get: Type 'jx' does not exist for 'map:generate' at file:/C:/Development/Java/Cocoon%202.2%20new/cocoon-webapp/src/main/webapp/samples/blocks/forms/sitemap.xmap:126:72 So it appears as though components are still not inherited properly into sub sitemaps. (I have copied the cocoon-template stuff into the WEB-INF/xconf and WEB-INF/sitemap-additions directories Good work on the defaults though. Also, is it necessary for me to include forms-impl, ajax-impl and ajax-samples to the webapp pom? I would expect that ajax-samples relies on the former two, and that I would only require to add the ajax-samples to the pom. It seems that the pom files for each of these blocks do not yet include their dependancies, or is that intentional? Ben Pope -- I'm not just a number. To many, I'm known as a string...
svn:externals and https
Hi, On my current connection ot the internet, there is a proxy which messes with http, to such an extent that it breaks svn. Thats fine, I can download trunk through https. However, it fails on the externals, since they are http. I can relocate the directory relating to the external on my local copy, and download it, but as soon as I update the root, it changes it back to http and fails. I don't think I can solve this problem locally, or whether it's possible to get externals through the same protocol as the main trunk. Does this affect anybody else? Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: svn:externals and https
On 05/02/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ben Pope schrieb: On my current connection ot the internet, there is a proxy which messes with http, to such an extent that it breaks svn. Thats fine, I can download trunk through https. However, it fails on the externals, since they are http. Actually this can be considered a bug - the externals should use https in order to give us committers an easy way to commit. Can you please point out the externals which are wrong? Well, I can only tell you the first one that fails, but I'm sure there is more than one. cocoon-archetypes\cocoon-archetype-core\src\main\resources\archetype-resources\src\main\webapp Cheers, Ben Pope -- I'm not just a number. To many, I'm known as a string... Btw, I thought we don't want to use externals anyway, so perhaps moving the stuff is the correct way. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1734) Forms library not honouring cross-referencing classes
[ http://issues.apache.org/jira/browse/COCOON-1734?page=comments#action_12364020 ] Ben Pope commented on COCOON-1734: -- Sorry, but it looks like your added methods in Binding.java broke a subclass, I get a failed compile (on 2.2): \cocoon-forms\cocoon-forms-impl\src\main\java\org\apache\cocoon\forms\samples\bindings\CustomValueWrapBinding.java:[29,7] org.apache.cocoon.forms.samples.bindings.CustomValueWrapBinding is not abstract and does not override abstract method setEnclosingLibary(org.apache.cocoon.forms.binding.library.Library) in org.apache.cocoon.forms.binding.Binding Forms library not honouring cross-referencing classes - Key: COCOON-1734 URL: http://issues.apache.org/jira/browse/COCOON-1734 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assignee: Max Pfingsthorn Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112774826126525w=4 We also encountered a problem with classes: if a library defines several cross-referencing classes (i.e. class A has a fd:new id=B and class B has a fd:new id=A), then the second fd:new fails because it searches in the current form whereas it should search in the originating definition. -- 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] Updated: (COCOON-1734) Forms library not honouring cross-referencing classes
[ http://issues.apache.org/jira/browse/COCOON-1734?page=all ] Ben Pope updated COCOON-1734: - Attachment: CustomValueWrapBinding.diff I don't know if this is in the spirit of your additions, but it makes it compile :) Forms library not honouring cross-referencing classes - Key: COCOON-1734 URL: http://issues.apache.org/jira/browse/COCOON-1734 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assignee: Max Pfingsthorn Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Attachments: CustomValueWrapBinding.diff See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112774826126525w=4 We also encountered a problem with classes: if a library defines several cross-referencing classes (i.e. class A has a fd:new id=B and class B has a fd:new id=A), then the second fd:new fails because it searches in the current form whereas it should search in the originating definition. -- 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
On 15/01/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Ben Pope skrev: When Building Cocoon Block Deployer I get a compile error: java.lang.IllegalStateException: basedir src\main\resources\xsd does not exist I get the same error, the directory is there but the castor plugin doesn't find it. Hopefully Reinhard can give a better answer on what is going on. At least I'm not going mad. I then try to create my own block and webapp using the instructions here: http://cocoon.zones.apache.org/daisy/documentation/g2/796.html and here: http://cocoon.zones.apache.org/daisy/documentation/g2/797.html These documents descreibe what we want to achieve rather than what we have. So you have either to wait, or get involved ;) OK, understood. It might take me a while to catch up, but if there's anything I can do to help I'll try. I'll have a look; I'll probably be more useful in the easy, but time consuming, rather than complicated stuff ;) If the current workaround is to wait 'til it works, then thats ok :P You are right about the current workaround. We are making good progress, so the waiting will hopefully not be to long. I can see the good progress and it's very interesting. Thanks for being eager to use the new stuff. ...I just wish I understood the implementation more so that I could contribute. Thanks for your response. Ben Pope -- I'm not just a number. To many, I'm known as a string...
M10N
Hi, I am currently unable to get the 2.2 trunk working with maven, as descibed in the docs. It might just be that it's broken what with all the refactoring, I dunno. I've been following this page: http://cocoon.zones.apache.org/daisy/documentation/g2/756.html When Building Cocoon Block Deployer I get a compile error: java.lang.IllegalStateException: basedir src\main\resources\xsd does not exist I can compile successfully if I remove both modulecocoon-deployer/module modulecocoon-plugins/module from the top-level pom.xml OK, that seems to work and I can successfully run jetty6. I then try to create my own block and webapp using the instructions here: http://cocoon.zones.apache.org/daisy/documentation/g2/796.html and here: http://cocoon.zones.apache.org/daisy/documentation/g2/797.html But both fail with a file that cannot be downloaded: Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/block/1.0/block-1.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) and Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/webapp/1.0/webapp-1.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Are these things known to be broken? Whats the current workaround? If the current workaround is to wait 'til it works, then thats ok :P Thanks for your time, Ben Pope.
Re: cocoon-refdoc initial code is in the whiteboard
Robert Graham wrote:
I grabbed the trunk off of SVN and the whiteboard and tried to build
this, but it failed trying to build the javadocs and I'm not sure why.
I thought someone might be able to enlighten me.I've got 2.1 running
on the same setup and have no trouble building it. I've edited it for
simplicity as best I can:
BUILD FAILED
{COCOONDIR}\docs-build.xml:57: The following error occurred while
executing this line:
{COCOONDIR}\...\blocks-build.xml:641: Javadoc failed:
java.io.IOException: CreateProcess: {DIR}\...\javadoc.exe -J-Xmx192m
-stylesheetfile {DIR}\...\trunk\src\resources\javadoc\javadoc.css
-windowtitle Cocoon API 2.2.0-dev [July 9 2005] -splitindex -use -d
{DIR}\...\trunk\build\cocoon\javadocs -doctitle Cocoon API
2.2.0-dev -classpath {DIR}\...\trunk\tools\lib\ant-contrib-0.6.jar;
DIR\...\trunk\tools\lib\ant-junit.jar; etc.
Last I heard, you can't use the ant build to build the docs in trunk, that
might have chnged by now. Just disable the docs to get the rest of cocoon
built.
Ben
Re: Marking cforms stable in 2.1.8
Reinhard Poetz wrote: Ben Pope wrote: Yes, I agree. The question still remains as to who's itch is irritating enough. I also agree that if Cocoon is going to have a small core, that ultimately will consist of CForms, JXTemplate (or CTemplate?) and, well, core, then it needs to marked stable ASAP. As far as I can tell, much work is being done in the templating areas, and CForms is hardly inactive. That's not true. cForms is one of the most active developed parts in Cocoon. I think you misread what I wrote. :-) To me, it looks like all these things will come together for 2.2, I'm not sure there is enough interest out there to get 2.1 stable. It looks like the major contributors here see problems and/or inconsistancies with the core APIs that they would like fixed for 2.2, and that seems to be the primary push here. I see very little talk of the direction for 2.1, it seems that it is already history in the minds of many commitors, in many respects. A lot of people, including committers, are using it in many projects, mostly 2.1 (I'm probably the only one who is using it based on 2.2). Please read Sylvain's mail (http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111826132000272w=2) which explains very well why we are hesitating to mark the block as stable. Yeah, I caught that one just after I posted. The problem is that the work Sylvain describes doesn't help somebody who is already knowing and using Cocoon. *I* know why there are three different Flowscript APIs and *I* know what I can use of them and what not. *I* also don't have a problem to modify the forms.xconf in the future if they change, etc. Somebody who is not that familiar with Cocoon will get lost, sooner or later. Yes, this is what I understood. Basically it's going to make life easier in the end but break existing stuff meanwhile. Ben
Re: Unsubscribe
Kumar, Kiran wrote: ubsubscribe You'd do better looking here: http://cocoon.apache.org/community/mail-lists.html And sending the mail to: mailto:[EMAIL PROTECTED] Ben
Re: Marking cforms stable in 2.1.8
Ralph Goers wrote: The problem is that we are recommending (and have been recommending) CForms as our forms framework for a long time. Even if you haven't marked it stable, it already should be, based upon those recommendations. Yes, in an ideal world the API would be fixed, but it seems this is not a big enough itch for anybody, plus the fact that other things need fixing for it to happen. I would prefer that CForms be marked stable unless the necessary work can be done in the next 6 weeks. Just so you know, I will be requiring a stable CForms on the next Cocoon release or I will vote -1. It makes very little sense to mark it stable without it actually being what is generally considered (by this community) as stable. You might as well just throw away all semantics, I doubt there are many people here who want to release something whose API they know will change, and then have to support it. With all due respect, you've been around here long enough to know that you have to scratch your own itches or wait for somebody else to. Ben
Re: Right word for docs: cachability or cacheability
Antonio Gallardo wrote: Hi, I found a source that contains both words: cachability and cacheability I wonder wich one is the right. I guess the second is the right word. Please english native speakers tell me wich is the right one. In dictionary.com don't contain none of them and googling returns hits for both. Only that the first word has less hits than the 2nd. If useful, the word context is: ... this might have issues concerning cachability of the generated output ... Well I don't think it's a word, although it's obvious what it means. Perhaps: Note that this might prevent the generated output of this transformer from being cached as the caching algorithm... Although that probably isn't what is meant. It's not the cachability of the output, it can still be cached, but whether the next request matches whats in the cache. Perhaps: Note that this has implications for the caching of the output of this transformer as the caching algorithm... WDYT? Ben Pope.
Re: Right word for docs: cachability or cacheability
Antonio Gallardo wrote: Thanks for the reply. This is the code in question: http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/transformation/TraxTransformer.java?view=markup Used to generate this doc: http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/TraxTransformer.html Can you send me a patch for a correct english of this? ;-) Hehe, and I thought it was on the docs website here: http://cocoon.apache.org/2.1/userdocs/transformers/xslt-transformer.html The change is slightly different to what I would apply to the docs, I'm sure you can all work it out. Ben Pope. Index: TraxTransformer.java === --- TraxTransformer.java(revision 165470) +++ TraxTransformer.java(working copy) @@ -85,8 +85,8 @@ * /pre * * The lt;use-request-parametergt; configuration forces the transformer to make all - * request parameters available in the XSLT stylesheet. Note that this might have issues - * concerning cachability of the generated output of this transformer.br + * request parameters available in the XSLT stylesheet. Note that this has implications + * for caching of the generated output of this transformer.br * This property is false by default. * p * The lt;use-cookiesgt; configuration forces the transformer to make all
Re: Right word for docs: cachability or cacheability
Antonio Gallardo wrote: Can you send me a patch for a correct english of this? ;-) Apologies... That last patch was imcomplete. This covers all instances of cach(e)ability, and replaces a br with a p to increase clarity. Ben Pope. Index: TraxTransformer.java === --- TraxTransformer.java(revision 165470) +++ TraxTransformer.java(working copy) @@ -85,13 +85,13 @@ * /pre * * The lt;use-request-parametergt; configuration forces the transformer to make all - * request parameters available in the XSLT stylesheet. Note that this might have issues - * concerning cachability of the generated output of this transformer.br + * request parameters available in the XSLT stylesheet. Note that this has implications + * for caching of the generated output of this transformer.br * This property is false by default. * p * The lt;use-cookiesgt; configuration forces the transformer to make all * cookies from the request available in the XSLT stylesheetas. - * Note that this might have issues concerning cachability of the generated output of this + * Note that this has implications for caching of the generated output of this * transformer.br * This property is false by default. * p @@ -101,10 +101,10 @@ * session-id-from-cookie, session-id-from-url, session-valid, session-id.br * This property is false by default. * - * pNote that these properties might introduces issues concerning - * cacheability of the generated output of this transformer.br + * pNote that these properties have implications for caching of the generated + * output of this transformer. * - * + * p * The lt;xslt-processor-rolegt; configuration allows to specify the TrAX processor (defined in * the cocoon.xconf) that will be used to obtain the XSLT processor. This allows to have * several XSLT processors in the configuration (e.g. Xalan, XSTLC, Saxon, ...) and choose
Re: Sharing sessions.. change to JDK1.5
Kumar, Kiran wrote: From: Torsten Curdt The only way to do proper synchronization is synchronize all access ...or use Dough's concurrent utils (which are now also part of java 1.5) but I am in trouble now as I cannot switch to 1.5 until some more time. It might take some time to migrate existing applications to 1.5. by the way we deploy the java on websphere AS400 You can use the concurrent utils without going to java 1.5, as far as I know... they are packaged with cocoon now. But they come as standard with java 1.5. Ben
Re: Sharing sessions.. change to JDK1.5
Kumar, Kiran wrote: does any give me an overview of what exactly I need to on using concurrent utils to create non-shareable DOM objects We're probably in the wrong place to be discussing general concurrent programming issues. Try here for a basic guide to the concurrent package: http://java.sun.com/developer/JDCTechTips/2005/tt0216.html#1 I haven't really been following your thread here as it's not really presented in an easy-to-read format, so I'm not sure what you require. If you want to create a non-shareable DOM object don't give the other threads access to it! If you want to protect it from concurrent access, whilst allowing multiple threads to access it, at different times, then semaphores are probably what you're after. Ben
Re: Transparent and automatic AJAX support for CForms
Sylvain Wallez wrote: Hi all, I've been thinking for a few weeks to add AJAX support to CForms. Ajax is the current buzzword in the blogosphere since Google maps [1] started and the folks at Adaptivepath found this name for the XmlHttpRequest + JS + XML combo [2]. snip/ Two days hacking, most of which dedicated to writing client-side JS and solving cross-browser compatibility problems and here we are: adding ajax=true on ft:form-template turns on the magic. snip/ I have turned on ajax mode on the following samples: - http://localhost:/forms-samples/carselector - http://localhost:/forms-samples/do-dynaRepeater.flow - http://localhost:/forms-samples/do-datasourceChooser.flow - http://localhost:/forms-samples/do-taskTree.flow snip/ Enjoy, Sylvain Well I have only just read this mail, and haven't had a chance to look at the samples, but it looks pretty useful to me. I'll look into it soon. Nice one Silvain... I'm sure there are others that appreciate this effort. Ben
Re: Transparent and automatic AJAX support for CForms
Sylvain Wallez wrote: Leszek Gawron wrote: It looks really promising. I was not able to run the samples. Firefox has rendered the retrieved list as text (outside selection widget). IE just showed javascript error and did nothing. Doh! I understand why you say promising :-( I tested it successfully with Firefox 1.0 on MacOS and Windows and IE 6. The behaviour you describe with Firefox is what I had to fight a lot with: Node.importNode() effectively imports nodes, but that doesn't mean they're considered as HTML nodes, in which case only their text is displayed. If you look at the new DOMUtils.importNode() in the new cforms.js, you'll see the quirks I used to workaround this weirdness: use .xml and .innerHTML properties with IE, and traverse the node tree for other browsers. I'm far from being a JS-on-browsers expert, so that may for sure not be the most compatible solution. Is there something printed in Firefox's JS console, and what is the IE error? I.e. says: Line: 91 Char: 5 Error: Object doesn't support this property or method. Code: 0 The line in question: xmlhttp.open(GET, xhr_cars/ + make.value, true); Perhaps thats make.value with the problem? Firefox on Windows doesn't say anything, it's quite happy. Ben
Re: Transparent and automatic AJAX support for CForms
Sylvain Wallez wrote: This is the XHR-powered carselector Ugo added months ago as a first experiment. Try the regular carselector, and also dynamic repeater, datasource selector and task tree (right column). I did wonder, as it wasn't what you'd mentioned. However, Firefox renders carselector fine, and IE is also quite happy. The carselector uses form submit onChange, and doesn't need Ajax? I also don't see the need for Ajax in the other samples. I really need to take a closer look at these samples! I'll stop with the noise until I've had a closer look. Ben
Re: JX generates weird NameSpace???
Sylvain Wallez wrote: oceatoon wrote: Hi everyone Is anybody aware of such a thing as JX generating a weirds namespaces?? head xmlns:[EMAIL PROTECTED]@#=[EMAIL PROTECTED]@# weird !! and blocking...g This seems to happen only on a cforms / jx mixed page, I tested simple jx is ok. Fixed. The problem comes from the fact that including macros starts some prefix mappings and ends them with no elements inbetween, and this seems to confuse Xalan a lot. This was a blocker for Ajax-in-CForms as Firefox's parser was failing on error when encountering this namespace. I added a o.a.c.xml.RedundantNamespacesFilter class that filters the output of JXTG to ensure namespaces are not mulitply declared and that empty namespaces scopes are filtered out. Could this be made into a transformer and still used for it's given purpose? Or perhaps wrap it with a transformer? Seems to be that would make a pretty useful transformer... much of what I output as xhtml has redundant namespaces and fails validation. I've had a little look at the source, and it seems that it would not require much work to have that as a transformer. I did give it a go, but didn't know what to put in the setup method and wound up with a NPE. Ben
Re: Proposed fix: crazy infinite loop w/ ft:continuation-id
Hi,
I saw that approach in the samples, but thought it would be nice to be
able to navigate the site passing parameters with POST sometimes, so
instead I came up with this:
map match ...
map:select type=request-parameter
map:parameter name=parameter-name value=continuation-id/
map:when test={request-param:continuation-id}
map:call continuation={request-param:continuation-id}/
/map:when
map:otherwise
map:call function...
If the continuation parameter is not present, the test returns null, and
goes to otherwise, which calls the form handler. If the parameter
exists (regardless of whether GET/POST) it calls the continuation.
Just a thought...
Ben Pope.
Eric E. Meyer wrote:
This is how I work with hidden continuation ids since my form posts.
You can select based upon the request:method - continuing only on POST:
map:select type=oacl-simple
map:parameter name=value value={request:method}/
map:when test=GET
map:call function=functionName
map:parameter name=searchType
value={0} /
/map:call
/map:when
map:when test=POST
map:call
continuation={request-param:continuation-id}
/
/map:when
/map:select
Regards,
Eric
Re: [CForms] Repeater: why not hashCode for id?
Sylvain Wallez wrote: No, no identity at all! Since you replay the add/move/delete events, you just need to be able to remove/add items at specific positions. That means that the underlying collection should be a java.util.list or a dom Element. But actually this can be even simpler and we don't need this record/replay thing :-) Have a look at the dynamic template sample [1] and play with add/delete/move actions: each row has an ID which indicates the row's creation order. In the case of binding, we won't use exactly use this ID, but store in rows the position in the original collection as an attribute (e.g. load-position). When the repeater is saved, with this information it's easy to know where and how to bind its rows: - if the load-position attribute exists, we bind to the corresponding object in the original collection, - if the load-position attribute doesn't exist, that means the row is newly created, and we therefore create a new object to save it. Row moves can be managed either by reordering the original collection or by creating a new collection to which objects will be added. I like this more, and this has the potential to kill both the current (complicated) repeater binding and also the simple-repeater binding which becomes useless :-) Sylvain [1] http://localhost:/samples/blocks/forms/do-dynaRepeater.flow What if the underlying structure can have different (previous) rows removed from it between when you load the model and save it back? Obviously you would usually lock the back end model, but you should only need to lock the rows that you have retrieved, and deal with unique IDs in a common manner. If you're just playing back positions and actions over the model, then you prevent simultaneous access to the data. Either that or you just push the complications into the users model. I suppose you could just tag old rows as dead, instead of removing them. And then clean up when nothing is locked. Having the identity solved this problem. Or have I missed something? Ben
Re: [CForms] Repeater: why not hashCode for id?
Sylvain Wallez wrote: Ben Pope wrote: Sylvain Wallez wrote: No, no identity at all! Since you replay the add/move/delete events, you just need to be able to remove/add items at specific positions. That means that the underlying collection should be a java.util.list or a dom Element. But actually this can be even simpler and we don't need this record/replay thing :-) Have a look at the dynamic template sample [1] and play with add/delete/move actions: each row has an ID which indicates the row's creation order. In the case of binding, we won't use exactly use this ID, but store in rows the position in the original collection as an attribute (e.g. load-position). When the repeater is saved, with this information it's easy to know where and how to bind its rows: - if the load-position attribute exists, we bind to the corresponding object in the original collection, - if the load-position attribute doesn't exist, that means the row is newly created, and we therefore create a new object to save it. Row moves can be managed either by reordering the original collection or by creating a new collection to which objects will be added. I like this more, and this has the potential to kill both the current (complicated) repeater binding and also the simple-repeater binding which becomes useless :-) Sylvain [1] http://localhost:/samples/blocks/forms/do-dynaRepeater.flow What if the underlying structure can have different (previous) rows removed from it between when you load the model and save it back? Obviously you would usually lock the back end model, but you should only need to lock the rows that you have retrieved, and deal with unique IDs in a common manner. If you're just playing back positions and actions over the model, then you prevent simultaneous access to the data. Either that or you just push the complications into the users model. I suppose you could just tag old rows as dead, instead of removing them. And then clean up when nothing is locked. Having the identity solved this problem. Or have I missed something? It all depends if you consider the repeater and the underlying collection to be part of the application data model or just a convenience container to show a set of independent objects to the user. If it's a application-level collection, then the repeater should be considered just the same as finer-grained objects and locked as a whole, or checked for concurrent modification to prevent lost update if locking isn't an option. With the identity mapping, as it is now, it's possible to select a subset of the children contained within a node: fruits fruit id=0 nameApple/name colourgreen/colour /fruit fruit id=1 nameOrange/name colourorange/colour /fruit fruit id=2 nameMango/name colourorange/colour /fruit fb:reapeater parent-path=fruits row-path=fruit[colour='orange'] row-path-insert=fruit So now I can modify orange fruits without locking apple (or any other non-orange fruit). You could easily modify green fruit, as long as the id is being tracked. If I start modifying orange fruit, then you start modifying green fruit by deleting apple, then I save the model back, obviously we have a problem as the positions are now off-by-one. So unless the replaying can take into account simultaneous accesses, all of the ones that happend since the form was loaded (what if using hibernate!), we've lost functionality. If it's just a holder, then only individual rows are bound and saved to the underlying storage. Modified rows lead to an update and new rows lead to an insert. There is a problem though for deleted rows as the repeater does not track rows that have been deleted (and the corresponding IDs). But if the repeater is just a dumb container, deletion can occur as soon as the users triggers the delete action. Does this answer your concerns, or did I missed something also? I'm concerned that functionality has been lost - perhaps it's bad practice to bind directly to the back end model. Perhaps it should be discouraged in favour of having the user always deal with an intermediate layer which, for example, uses an identity. So surely by simplifying the repeater, you're just pushing the complicated identity stuff to the user? I know that the repeater is a complicated beast as I've been trying to modify it for my own purposes. I'd love for there to be a much easier way of dealing with the binding, I just feel that using the identity is a very robust way of doing it and it's better to have it in the binding framework than the users code. Thanks for your time, Ben.
Re: Couple of tests I ran on Cocoon, VMs and JDKs
Stefano Mazzocchi wrote: Pier Fumagalli wrote: FYI, might be interesting for the Cocooners out there, as that's what I've tested. http://www.betaversion.org/~pier/wiki/display/pier/32+Versus+64 Interesting. It would also be kinda cool to have some other data in terms of concurrency, you are stressing with 10 threads, but it would be interesting to see if the 64bit architecture handles load better or worse (don't know why, but it's another axis to consider that you haven't in your exercise). yes, I know you might not care :-) Anybody done any comparisons between Java 1.5 and 1.4.2? ...Since Cocoon now compiles cleanly on 1.5. Ben
RE: CForms Binding - Cross Referenced Data (duplicate of post on users)
Sylvain Wallez wrote: Ben Pope wrote: project people person id=0 nameMe/name /person person id=1 nameYou/name /person person id=2 nameHim/name /person /people rooms room id=0 nameLounge/name person idref=0/ person idref=1/ /room room id=1 nameKitchen/name person idref=2/ /room /rooms /project That describes a list of people which are in a particular room, so Me and You are in the Lounge and Him is in the Kitchen. I want to have a form that displays, for a given room, a list of the people in it. SNIP / Hmm... I hope I'm not the only one to do fancy CForms stuff :-/ Your room repeater links to existing people through their ID but should display their name. This is typically a selection-list with IDs as labels and names as values. Ahh yes. That makes sense for name. My first reaction is how do I easily add fields such as age, favourite colour etc, and have those bind as well. If I run a repeater over /rooms/person I want bindings that are equivalent to: fb:value id=name path=/project/people/[EMAIL PROTECTED]()/idref]/name / fb:value id=age path=/project/people/[EMAIL PROTECTED]()/idref]/age / Which would only be valid in an xslt, of course. As mentioned before, I started work on an xref-repeater which would understand my requirements - it's syntax was something like: fb:xref-repeater id=people source-parent-path=/project/[EMAIL PROTECTED]'0'] source-row-path=person target-parent-path=/project/people target-row-path=person / It would then likely need a source-identity and target-identity, or some other way of specifying the id=idref relationship. Unfortunately I didn't get very far with it as I don't really understand the o.a.c.forms.binding package, despite stepping through it in eclipse. About the ability to add new names at any level, this looks like a combo-box (editable dropdown). We've hacked such a thing for one of our projects, and basically the idea is to have a single widget be rendered as two inputs. Say you have fd:field id=personref fd:selection-list src=cocoon:/person-selection-list/ /fd:field That's identical (except names) to something I have to display a selectionlist of person/names now. The editable combobox renders this as : - a dropdown list of name personref with the contents of the selection-list - an input of name personref.label. When the user chooses in the dropdown, the selected value is copied to personref.label. OK, I'm with you. When the user types in the personref.label input, a new option is added to the dropdown, having new as a value, and the typed text as label. OK. On form submit, the flowscript checks if personref equals new and if true creates a new person with the name in the personref.label request parameter and replaces the new value with the newly created id. Binding can then go on as usual. This is a bit hacky, but it works :-) That's excellent, Sylvain. I'll give it a go later.
CForms Binding - Cross Referenced Data (duplicate of post on users)
Hi, First of, sorry for the post here, but I've asked a few times on users and not had this solved, so I'm gonna cross my fingers and post here: This is something I've been struggling with, on and off, for some time now. Assume I have some data as follows: project people person id=0 nameMe/name /person person id=1 nameYou/name /person person id=2 nameHim/name /person /people rooms room id=0 nameLounge/name person idref=0/ person idref=1/ /room room id=1 nameKitchen/name person idref=2/ /room /rooms /project That describes a list of people which are in a particular room, so Me and You are in the Lounge and Him is in the Kitchen. I want to have a form that displays, for a given room, a list of the people in it. A repeater is obviously the first choice, but there are a few counter-intuitive thingsd going on: I need to be able to modify the name of the person. Simply running the repeater over the rooms is not enough. Adding a row needs to add an rooms/room/person with an idref - I'll then use client side javascript and XMLHTTP to allow the user to select a person (by id) to fit in the space, as all the people are predefined. I do not want to have the repeater add /people/persons. I've toyed with a few ideas: id is passed in as a parameter, and this code is actually in a stylesheet - but ignore that for now. fb:repeater id=people parent-path=/project/rooms/[EMAIL PROTECTED] row-path=/project/people/[EMAIL PROTECTED]/project/rooms/[EMAIL PROTECTED]/person/@ idref] This solution has the result of being perfect for load. However, when I save it, it breaks, because I can't have an xpath predicate. So what do I set the row-path-insert to? If I set row-path-insert=/project/people/person and bind the id (which is fb:identity) in both directions, /project/people/ ends up correct, but /project/rooms/room/ doesn't get updated. I've tried fb:on-insert-row fb:context path=/project/rooms/[EMAIL PROTECTED]'0'] fb:insert-node person idref=5/ /fb:insert-node But then I get a new node in both /rooms/[EMAIL PROTECTED]'0']/ which is correct, and another node created in /project/people/ which is the usual binding for person and is a copy of the existing one. This doesn't seem correct to me. Hmm, I've had a little play with fb:javascript but I don't know what I'm doing... Ideally I would remove all the /rooms/[EMAIL PROTECTED]'x']/person fields and repopulate with the list of ids in the repeater. I can't seem to work out the correct APIs, it always says that such and such method doesn't exist - can anybody point me in the right direction? I've toyed with the idea of having two repeaters, and updating one from the other but it sounds like a recipe for disaster. Another idea was to have a play around with it in flow, but I suspect I'd end up with exactly the same problems I have using fb:javascript, with the disadvantage of distributing the binding code. Any help is much appreciated, I'm confused by the number of options and multitude of interfaces. I can't be the only person working with cross-referenced data! I'm either missing something or the repeater just doesn't understand this construct - I wonder if Sylvain has any ideas on this. I also started writing my own Repeater (well I copied the existing one, renamed it, changed some of it's parameters and managed to get Cforms to use it), but running through with eclipse in debug mode doesn't really throw any light on the subject - it's all too confusing for me. Hlp! Ben
RE: CForms Binding - Cross Referenced Data (duplicate of post on users)
Linden H van der (MI) wrote: Hi, Just a quick response. What you describe here are two entities: rooms and persons. It is much more common sense to treat them separately, i.e. a list for editing persons (just a repeater) and a list for editing rooms (simple list?) and finally, maybe a doubleList for adding persons to a room. Quite possibly, but I'm recreating some paper forms and want the user to be able to enter the information as quicky as possible using my system. Essentially all the peoples names and ids are predefined (there will no doubt be a form to enter those people, too), but can be modified at any point. More fields will be added to the people using this form (lets say; age, height, favourite colour). Unfortunately it has to be done this way. Thanks for your reply. Does anybody know how I can use fb:javascript (or flow, if not) to grab each id specified in the repeater and replace people elements inside of the room with the appropriate idrefs? Cheers, Ben Pope -Original Message- From: Ben Pope [mailto:[EMAIL PROTECTED] Sent: Sunday, 13 March 2005 18:12 To: dev@cocoon.apache.org Subject: CForms Binding - Cross Referenced Data (duplicate of post on users) Hi, First of, sorry for the post here, but I've asked a few times on users and not had this solved, so I'm gonna cross my fingers and post here: This is something I've been struggling with, on and off, for some time now. Assume I have some data as follows: project people person id=0 nameMe/name /person person id=1 nameYou/name /person person id=2 nameHim/name /person /people rooms room id=0 nameLounge/name person idref=0/ person idref=1/ /room room id=1 nameKitchen/name person idref=2/ /room /rooms /project That describes a list of people which are in a particular room, so Me and You are in the Lounge and Him is in the Kitchen. I want to have a form that displays, for a given room, a list of the people in it. A repeater is obviously the first choice, but there are a few counter-intuitive thingsd going on: I need to be able to modify the name of the person. Simply running the repeater over the rooms is not enough. Adding a row needs to add an rooms/room/person with an idref - I'll then use client side javascript and XMLHTTP to allow the user to select a person (by id) to fit in the space, as all the people are predefined. I do not want to have the repeater add /people/persons. I've toyed with a few ideas: id is passed in as a parameter, and this code is actually in a stylesheet - but ignore that for now. fb:repeater id=people parent-path=/project/rooms/[EMAIL PROTECTED] row-path=/project/people/[EMAIL PROTECTED]/project/rooms/[EMAIL PROTECTED] $id}]/person/@ idref] This solution has the result of being perfect for load. However, when I save it, it breaks, because I can't have an xpath predicate. So what do I set the row-path-insert to? If I set row-path-insert=/project/people/person and bind the id (which is fb:identity) in both directions, /project/people/ ends up correct, but /project/rooms/room/ doesn't get updated. I've tried fb:on-insert-row fb:context path=/project/rooms/[EMAIL PROTECTED]'0'] fb:insert-node person idref=5/ /fb:insert-node But then I get a new node in both /rooms/[EMAIL PROTECTED]'0']/ which is correct, and another node created in /project/people/ which is the usual binding for person and is a copy of the existing one. This doesn't seem correct to me. Hmm, I've had a little play with fb:javascript but I don't know what I'm doing... Ideally I would remove all the /rooms/[EMAIL PROTECTED]'x']/person fields and repopulate with the list of ids in the repeater. I can't seem to work out the correct APIs, it always says that such and such method doesn't exist - can anybody point me in the right direction? I've toyed with the idea of having two repeaters, and updating one from the other but it sounds like a recipe for disaster. Another idea was to have a play around with it in flow, but I suspect I'd end up with exactly the same problems I have using fb:javascript, with the disadvantage of distributing the binding code. Any help is much appreciated, I'm confused by the number of options and multitude of interfaces. I can't be the only person working with cross-referenced data! I'm either missing something or the repeater just doesn't understand this construct - I wonder if Sylvain has any ideas on this. I also started writing my own Repeater (well I copied the existing one, renamed it, changed some
RE: CForms Binding - Cross Referenced Data (duplicate of post on users)
Mark Lowe wrote: I dont think the dream team example covers nested repeaters.. I'll have to suck it and see if this can be done.. this is something I've done in the past with other frameworks and plain servlets and jsp. It appears as though nested repeaters are covered in Form Model GUI. However, I kind of need a pair of parallel repeaters :-) (one for people/persons with an id, and one for room/persons with an idref) Without having tried it yet, if it were the case that cocoon forms cant deal with nested lists/rows then i guess trying to use aggreate fields as child widgets would be worth a go. Pass the people as a tokenized string and then use flow to convert to tokens in save-form. During load-form or even on bind you could populate the aggregated field. You just confused me. Why would I use aggregate fields? I'd probably want my data xml strutured more like room person / /room It is? Or do you mean forget the cross referencing and have the actual person, with the name element inside the room? It's possible. I've been thinking of various other ways of doing this as I'm really struggling with the flat-table way of storing this data. It's not like more than one room can contain a person simultaneously. I really would prefer to have this flat structure, but perhaps I will have to forgo that. So the binder would know that there's a nested object inside room. I'll have a go when i get time, as i anticipate that this is the sort of thing that crops up a lot. Hopefully nested repeaters are supported. I think nested repeaters are supported but I'm confused as to their relevance here. I don't want to display all rooms at once, I want one room at a time, so it's not like I need to repeat over the rooms. Thanks for your time, all insights are welcomed! Ben Pope Mark On Sun, 13 Mar 2005 20:25:50 +0100, Linden H van der (MI) [EMAIL PROTECTED] wrote: You could make a multipage form if necessary. Also have a look at the samples in the forms block. I think the dreamteam sample and the dynamic repeater sample demonstrate what you are looking for. HTH. Bye, Helma -Original Message- From: Ben Pope [mailto:[EMAIL PROTECTED] Sent: Sunday, 13 March 2005 20:22 To: dev@cocoon.apache.org Subject: RE: CForms Binding - Cross Referenced Data (duplicate of post on users) Linden H van der (MI) wrote: Hi, Just a quick response. What you describe here are two entities: rooms and persons. It is much more common sense to treat them separately, i.e. a list for editing persons (just a repeater) and a list for editing rooms (simple list?) and finally, maybe a doubleList for adding persons to a room. Quite possibly, but I'm recreating some paper forms and want the user to be able to enter the information as quicky as possible using my system. Essentially all the peoples names and ids are predefined (there will no doubt be a form to enter those people, too), but can be modified at any point. More fields will be added to the people using this form (lets say; age, height, favourite colour). Unfortunately it has to be done this way. Thanks for your reply. Does anybody know how I can use fb:javascript (or flow, if not) to grab each id specified in the repeater and replace people elements inside of the room with the appropriate idrefs? Cheers, Ben Pope -Original Message- From: Ben Pope [mailto:[EMAIL PROTECTED] Sent: Sunday, 13 March 2005 18:12 To: dev@cocoon.apache.org Subject: CForms Binding - Cross Referenced Data (duplicate of post on users) Hi, First of, sorry for the post here, but I've asked a few times on users and not had this solved, so I'm gonna cross my fingers and post here: This is something I've been struggling with, on and off, for some time now. Assume I have some data as follows: project people person id=0 nameMe/name /person person id=1 nameYou/name /person person id=2 nameHim/name /person /people rooms room id=0 nameLounge/name person idref=0/ person idref=1/ /room room id=1 nameKitchen/name person idref=2/ /room /rooms /project That describes a list of people which are in a particular room, so Me and You are in the Lounge and Him is in the Kitchen. I want to have a form that displays, for a given room, a list of the people in it. A repeater is obviously the first choice, but there are a few counter-intuitive thingsd going
2.1.7-Dev - Commit 156144 - Borked, or am I mad?
Hi guys, Am I going mad, or did this break some of my stuff? It seems as though some of my forms are being cached now, and the change is to do with removing stuff from the cache... If this isn't the case, I apologise for pointing fingers, but I'm sure it worked a couple of days ago. I updated today, recompiled and it stopped working, reverted back and it works again. Anybody else seeing this behaviour? I restarted Jetty a couple of times, but it was definitely displaying data that was no longer in the data file! And none of my pages seem to change when I feed in a different parameter. I still get the same continuation id embedded in the page. Even accessed it from a different browser, one that has never visited said page. Ben
RE: 2.1.7-Dev - Commit 156144 - Borked, or am I mad?
I think I'm mad, so ignore me. Bit difficult to tell now, didn't realise a build clean just deleted the webapp directory. Shame really, as my work was there. Ben -Original Message- From: Ben Pope [mailto:[EMAIL PROTECTED] Sent: 04 March 2005 23:39 To: dev@cocoon.apache.org Subject: 2.1.7-Dev - Commit 156144 - Borked, or am I mad? Hi guys, Am I going mad, or did this break some of my stuff? It seems as though some of my forms are being cached now, and the change is to do with removing stuff from the cache... If this isn't the case, I apologise for pointing fingers, but I'm sure it worked a couple of days ago. I updated today, recompiled and it stopped working, reverted back and it works again. Anybody else seeing this behaviour? I restarted Jetty a couple of times, but it was definitely displaying data that was no longer in the data file! And none of my pages seem to change when I feed in a different parameter. I still get the same continuation id embedded in the page. Even accessed it from a different browser, one that has never visited said page. Ben
RE: Moving blocks
-Original Message- From: Reinhard Poetz [mailto:[EMAIL PROTECTED] Sent: 18 February 2005 17:41 To: dev@cocoon.apache.org Subject: Re: Moving blocks Upayavira wrote: Reinhard Poetz wrote: Could some people pls report back whether there have been any problems on updates? (Escpecially be careful if you had changes in one of the four moved blocks. In this case, sorry for any inconveniences!) Have you tried checking out the external references via http rather than https? Just want to be sure that they'll still work for non-committers using http. Yes, svn checkout http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks worked for me. I guess that people not using https have to accept the certificate once. That seems to be what just happened. TortoiseSVM deleted the blocks, and re-added them at the some location, but I had to accept the certificate. No major problem. Ben
Cforms Repeater Binding Cross-Referenced Data
Hi, I'll get straight to the point: I'm having some difficulty in working out how to bind the following data in both directions: project people person id=0 nameMe/name /person person id=1 nameYou/name /person person id=2 nameHe/name /person /people rooms room id=0 nameLounge/name person idref=0/ person idref=1/ /room room id=1 nameKitchen/name person idref=2/ /room /rooms /project Hopefully that describes the situation where Me and You are in the Lounge and He is in the Kitchen. Now, assume I would like to be able to modify the names of all people in the Lounge, and would therefore like to have a repeater that is in some sense repeating over /project/rooms/[EMAIL PROTECTED]/person but modifying a subset of the data in the /project/people/person branch. Is this possible with just the repeater? What would be the best way of doing this? I am willing to extend/modify/create a repeater that can do this (as I think this is a useful thing), but have not contributed to cocoon so far and would probably need prodding in the right direction. Thanks for your time, Ben.
