Re: URL Theory Best Practices
Hi! Interesting thread! Most things has been said allready, but I'll just add a little .02 (whatever currency) :-) On Thursday 07 November 2002 23:57, Tony Collen wrote: However, later I realize that using file extensions is bad. Read http://www.alistapart.com/stories/slashforward/ for more info on this idea. The article is interesting, but a little too narrow. Indeed, using file extensions are Bad[tm] for URIs because you tie the address to a specific technology, which you may not be using in some years. For that reason not changing the default cocoon in Cocoon URIs are also a Bad Thing[tm]. The authorative reference on this topic is TimBL's rant Cool URIs don't change: http://www.w3.org/Provider/Style/URI :-) So, using directories for everything is one possibility, and if you do, make sure to include the trailing /, to avoid useless 301 redirects. Another option is to use Content Negotation, which is well defined in HTTP 1.1 (and earlier, IIRC), it's weird that it isn't more widely used. But, both content negotation and using directories for everything are both solutions that exists mainly because URIs have been so strongly tied to the file system of the server, and the mentioned article seems to take as granted that this connection is a necessity, but as Cocoon proves, this is not so. Just use sensible matches. It also means that requiring a trailing slash on every URI is a bit too much, I only do that if there is logically a hierarchal substructure. As for the problem of serving different formats to the client, I really have no good solution. What the user agents should do, was to let the user easily manipulate the Accept-header, so if the user wants a PDF-file, he would send only application/pdf in the Accept header, and the server would know that the user wanted a PDF-file, and send that. Given that it doesn't exist, appending the type to the URI is probably not too bad. Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect in XSP
Hi Neil,
It is not very clean, but if you don't find another solution, you can read
in you Action the file content/table_names.xml to find your URL (if it is a
static file, you do it once). You can so add it in a sitemap parameter.
Ludovic
- Original Message -
From: Neil A [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 09, 2002 5:06 PM
Subject: Re: Redirect in XSP
Thanks Joerg and Artur, but in my case I'm building for WAP.
Unfortunately the WML equivalent of your client side redirect crashes
early Nokia 7110 phones.
I really want to use map:redirect-to but my URL is in the XML of the
pipeline and I can't get it into a sitemap parameter:
map:match pattern=link/id*
map:generate src=content/table_names.xml/
map:transform src=directory/format_link_query.xsl type=xslt
map:parameter name=link_id value={1}/
/map:transform
map:transform type=sql/
!-- Missing link to get url from xml and make into sitemap parameter
--
map:redirect-to uri={take_me_here}/
/map:match
Actions can't seem to read or transform the pipeline xml, they can only
read and act on request parameters. XSLT transformers can't create
sitemap parameters. So I'm a bit stuck. Can anyone fill in the gap?
Thanks,
Neil.
On Saturday, November 9, 2002, at 03:23 AM, Artur Bialecki wrote:
Who should close the head/ element? The transformer can not send an
endElement() until everything inside is processed. Of course you have
to
Ofcourse, I don't know what I was thinking.
Does this make it a bit clearer? Everybody can of course improve my
This makes it very clear.
Thanks Joerg,
Artur...
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Resin (parser?) problem
Hi, I've got a problem getting Cocoon 2 (from the bin download) running on Resin (2.1 I think). A Tomcat install of the same download works (mostly) ok. I followed the appropriate instructions on a local install and got the error below when I pointed a browser at ../cocoon. I'm guessing this is related to the parser used, although I've done the swap to Xerces suggested in the instructions, maybe it's picking up something else from my classpath? Not long ago I managed to get some Batik-based material working by adding the following to the web-app section of web.xml : system-property javax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBu ilderFactoryImpl/ but I can't find a variation on this that helps with the current problem. Ideally I want to be able to specify the necessary properties on a per-app basis, as I don't have admin privilege on a live server I want to use - I can't change anything system-wide or even restart Resin. Incidentally, does anyone know offhand how the parser for Batik is worked out in Cocoon - is Xerces somehow used there too? Cheers, Danny. In browser: java.lang.NullPointerException: Null content handler at org.xml.sax.helpers.XMLFilterImpl.setContentHandler(XMLFilterImpl.java:307) at org.apache.cocoon.components.language.markup.LogicsheetCodeGenerator.addLogi csheet(LogicsheetCodeGenerator.java:98) at org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.addLogic sheetsToGenerator(AbstractMarkupLanguage.java:304) ... In console: com.caucho.xsl.XslParseException: jar:file:/C:/resin-2.1.4/webapps/cocoon/WEB-IN F/lib/cocoon-2.0.jar!/org/apache/cocoon/components/language/markup/sitemap/j ava/ sitemap.xsl:429: `hasSubstitutions' is not a static method in `org.apache.cocoon .sitemap.XSLTFactoryLoader' in XSLTFactoryLoader:hasSubstitutions(@pattern) at com.caucho.xsl.Generator.error(Generator.java:2143) at com.caucho.xsl.Generator.error(Generator.java:2120) at com.caucho.xsl.Generator.parseExpr(Generator.java:2113) ... --- Danny Ayers Semantic Web Log : http://www.citnames.com/blog - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cocoon XSL performance in Tomcat vs Weblogic
In our development environment with Cocoon in Tomcat XSL processing is fast, the same application deployed in Weblogic 6.1 SP3 takes about 5 times more time to do the XSL part. In Tomcat it takes about 1 second , in Weblogic 5 seconds on a much faster machine. Other operations runs faster, but the XSL processing is a lot slower. We use exactly the same Xalan version 2.4.0 in both cases. The Cocoon version is 2.02. Any ideas ? Regards Ulf
Re: XMLForm - xf:repeat tag on DOM Nodes?
You probably meant to use: xf:repeat nodeset=/productNode/product/description xf:textbox ref=@lang xf:captionLanguage (code):/xf:caption xf:violations class=error/ /xf:textbox xf:textbox ref=. xf:captionDescription:/xf:caption xf:violations class=error/ /xf:textbox /xf:repeat I would also recommend that you use the standard xml:lang attribute instead of a non-qualified one. Ivelin - Original Message - From: Josema Alonso [EMAIL PROTECTED] To: Cocoon-Users [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 12:40 PM Subject: XMLForm - xf:repeat tag on DOM Nodes? Dear all, I see in thw wizrd demo how the repeat tag is used like this: xf:repeat nodeset=favorite[position() lt;= 3] id=favorites xf:textbox ref=. class=info xf:captionURL: /xf:caption /xf:textbox /xf:repeat In the model bean the favorite is implemented as an array list, so you can iterate through it using the position function and specifying how many items to display. Well, now I got a part of my model implmented as a DOM Node. It seems it'w working right but I can't make the repeat tag to work with it. Let's say I have something like this: product description lang=ennice table/description description lang=esmesa bonita/description /product I want to display as many textboxes as descriptions, ok? I have tried this, but unfortunately it is not working. : xf:repeat nodeset=/productNode/product xf:textbox ref=description/@lang xf:captionLanguage (code):/xf:caption xf:violations class=error/ /xf:textbox xf:textbox ref=description xf:captionDescription:/xf:caption xf:violations class=error/ /xf:textbox /xf:repeat If I try to access just one description node outside the repeat tag, I get the info correctly. Any ideas? Thanks. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Testing for the *presence* of a particular request parameter
I need to test for the presence of a particular request parameter. In particular, I want to write my sitemap such that the following URLs will behave as described: /search - loads the search page /search?q=blah - displays search results /search?q= - empty results, or the search page itself (don't care) I know how to use the request-parameter selector (which tests for particular parameter *values*), but I don't know how to test for the *presence* of a particular parameter (or to test for a non-empty value). Can request-parameter do this, or do I need to use something else? Thanks, Evan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Umlauts in cocoon 2.0.2
I have the problem with german Umlauts in request parameters. When I transfer german Umlauts by request paramaters cocoon doesn't decode the Umlauts encoding when I use these Umlauts in my xml-documents or stylesheets. I set already all my encodings to ISO-8859-1. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
Antonio A. Gallardo Rivera wrote: Kjetil Kjernsmo dijo: On Thursday 07 November 2002 23:57, Tony Collen wrote: However, later I realize that using file extensions is bad. Read http://www.alistapart.com/stories/slashforward/ for more info on this idea. I know about that. The theory is fine, but in the real world... Are you tried to open a PDF file without the .pdf extension with MS IE 6.0 SP1? It does not work. MS IE relays mainly on the extension of the file to open a pdf file. How we can address this? I already know that Carsten and Mathew in his book dont recommend the use of extension and I agree. But how we can tell MS Internet Explorer about that? PDF isn't IE's normal method of receiving information (ease of use with Acrobat aside). If you specifically want the PDF representation, specify *.pdf. If what you want is the resource, then you aren't asking specifically for PDF. If all you have is PDF and PDF is the only representation, then having your URL specify that you are serving PDF hurts no one and corrupts no URLs. - Miles - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
On Saturday 09 November 2002 21:33, Miles Elam wrote: Antonio A. Gallardo Rivera wrote: Kjetil Kjernsmo dijo: On Thursday 07 November 2002 23:57, Tony Collen wrote: However, later I realize that using file extensions is bad. Read http://www.alistapart.com/stories/slashforward/ for more info on this idea. I know about that. The theory is fine, but in the real world... Are you tried to open a PDF file without the .pdf extension with MS IE 6.0 SP1? No, I have barely touched IE since 3.0. It does not work. MS IE relays mainly on the extension of the file to open a pdf file. What?!? What you're saying is that IE is ignoring the content-type? That's just incredibly silly... How we can address this? I already know that Carsten and Mathew in his book dont recommend the use of extension and I agree. But how we can tell MS Internet Explorer about that? PDF isn't IE's normal method of receiving information (ease of use with Acrobat aside). If you specifically want the PDF representation, specify *.pdf. If what you want is the resource, then you aren't asking specifically for PDF. If all you have is PDF and PDF is the only representation, then having your URL specify that you are serving PDF hurts no one and corrupts no URLs. Yes it does! What representation is chosen should only depend on the Accept header, and what the UA should do with a file it receives should have nothing to do with the filename whatsoever, it should be based on the Content-Type-header in the response, solely. It's been a while since I read the HTTP 1.1 spec, but IIRC, it is pretty clearly spelled out there. It should only depend on the MIME-type. On the server and client sides, separately, how it is done is of no concern of anybody, but that the client depends on what file extension the server uses has to be a violation of the spec, again IIRC. During content negotation, an extensionless URL should be responded to with 200 if the server has a representation which is acceptable according to the client's Accept*-headers, with a Location-header saying where to find the best file, and that file may well have a .pdf extension. If no appropriate representation is found, the server should respond with 406. /rant Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing the output of a modular db action in xsl
I tried that as well, and only row-count would come through, I was unable to get the selected parameters even though I used map:parameter name= value= so what would the correct map:parameter look like to get at the output of a mod-db select. Just to reiterate I appologize for being dense and greatly appreciate the help (in case I forgot to mention earlier) On Tuesday 05 November 2002 01:39 pm, Christian Haul wrote: On 04.Nov.2002 -- 07:43 PM, Phil Craven wrote: here is the sitemap segment that shows what I am trying to do. map:match pattern=group2.xsp map:act type=mod-db-sel action=sel-ci map:parameter name=table-set value=content_item/ map:generate type=serverpages src=group2.xsp/ map:transform src=xsl/dynamic-page2html.xsl/ map:transform src=xsl/stupid.xsl map:parameter name=use-request-parameters value=true/ use-session-infotrue/use-session-info /map:transform map:serialize/ /map:act map:read src=finished.html/ map:serialize type=html/ /map:match The kicker is that I can see the values in the logs, but I cannot see the values reflected in the xsl. On a related not, if I add row-count in as a parameter, then it will show up in the xsl, but no other values will. Phil, what do you mean with not in the xsl? Which xsl? Sitemap variables are never automatically propagated to any other component. This needs to be done explicitly e.g. using map:parameter/ Results from a database action are available as request attributes as well. Chris. --- - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing for the *presence* of a particular request parameter
Lenz, Evan dijo: I need to test for the presence of a particular request parameter. In particular, I want to write my sitemap such that the following URLs will behave as described: /search - loads the search page /search?q=blah - displays search results /search?q= - empty results, or the search page itself (don't care) I know how to use the request-parameter selector (which tests for particular parameter *values*), but I don't know how to test for the *presence* of a particular parameter (or to test for a non-empty value). Can request-parameter do this, or do I need to use something else? Look for the request matcher: matches a request parameters given as a pattern. If the parameter exists, its value is available for later substitution. Antonio Gallardo Thanks, Evan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serializer for d-o-e?
J.Pietschmann wrote:
Lenz, Evan wrote:
I understand why Cocoon disables the use of disable-output-escaping
in XSLT.
However, in my current project, which involves parsing XML results from
Google containing escaped (and non-well-formed) HTML, I need to find
a way
to disable output escaping for certain sections of text, perhaps
based on
the presence of a special attribute or PI that I can generate when
necessary. Does Cocoon provide a way of parameterizing an existing
serializer to do this? Has anyone implemented such a serializer? I would
think that such a customization of an existing XML serializer should be
pretty simple, but the Cocoon serialization framework is so abstract
that
I'm having trouble finding the right code to extend or modify.
The answer is quite simple: you can't. D-o-e only works if the
XSLT processor serializes the result itself, the information
which text nodes are supposed to be d-o-e'd on output is not
transported through the SAX pipelines Cocoon uses for plumbing
it's components.
JAXP provides two special PIs to handle the case when serialization
isn't performed by the XSLT engine :
- ?javax.xml.transform.disable-output-escaping? to start d-o-e and
- ?javax.xml.transform.enable-output-escaping? to stop it.
See also
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-commons/java/external/src/javax/xml/transform/Result.java?rev=1.2
Hope this helps, but use it wisely !
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
The true is that I wrote. If you dont believe me, I recommend you to check the archive of this mailing list. This was not my fault. Not only I found this error many other people had the same problem with IE 6.0 SP1. I fighted with generation of PDF the content for a day after I realize that the extension must be .pdf or it will not work! This is why I told you about the fine theory and the cruel reality. :-D Antonio Gallardo. Kjetil Kjernsmo dijo: On Saturday 09 November 2002 21:33, Miles Elam wrote: Antonio A. Gallardo Rivera wrote: Kjetil Kjernsmo dijo: On Thursday 07 November 2002 23:57, Tony Collen wrote: However, later I realize that using file extensions is bad. Read http://www.alistapart.com/stories/slashforward/ for more info on this idea. I know about that. The theory is fine, but in the real world... Are you tried to open a PDF file without the .pdf extension with MS IE 6.0 SP1? No, I have barely touched IE since 3.0. It does not work. MS IE relays mainly on the extension of the file to open a pdf file. What?!? What you're saying is that IE is ignoring the content-type? That's just incredibly silly... How we can address this? I already know that Carsten and Mathew in his book dont recommend the use of extension and I agree. But how we can tell MS Internet Explorer about that? PDF isn't IE's normal method of receiving information (ease of use with Acrobat aside). If you specifically want the PDF representation, specify *.pdf. If what you want is the resource, then you aren't asking specifically for PDF. If all you have is PDF and PDF is the only representation, then having your URL specify that you are serving PDF hurts no one and corrupts no URLs. Yes it does! What representation is chosen should only depend on the Accept header, and what the UA should do with a file it receives should have nothing to do with the filename whatsoever, it should be based on the Content-Type-header in the response, solely. It's been a while since I read the HTTP 1.1 spec, but IIRC, it is pretty clearly spelled out there. It should only depend on the MIME-type. On the server and client sides, separately, how it is done is of no concern of anybody, but that the client depends on what file extension the server uses has to be a violation of the spec, again IIRC. During content negotation, an extensionless URL should be responded to with 200 if the server has a representation which is acceptable according to the client's Accept*-headers, with a Location-header saying where to find the best file, and that file may well have a .pdf extension. If no appropriate representation is found, the server should respond with 406. /rant Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Umlauts in cocoon 2.0.2
I recommmend you to check the mail archives fo this list with the keyword Umlauts. There is a summary about this problem. Antonio Gallardo Braun dijo: I have the problem with german Umlauts in request parameters. When I transfer german Umlauts by request paramaters cocoon doesn't decode the Umlauts encoding when I use these Umlauts in my xml-documents or stylesheets. I set already all my encodings to ISO-8859-1. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
On Saturday 09 November 2002 23:41, Antonio A. Gallardo Rivera wrote: The true is that I wrote. If you dont believe me, I recommend you to check the archive of this mailing list. This was not my fault. Not only I found this error many other people had the same problem with IE 6.0 SP1. I fighted with generation of PDF the content for a day after I realize that the extension must be .pdf or it will not work! This is why I told you about the fine theory and the cruel reality. :-D Uh-oh I'm catching some bad vibs... Can someone do me a favour of going to http://www.kjernsmo.net/ with IE6 and see what happens? The mainpage isn't a big thing, it is pure XHTML, but per the XHTML 1.0 spec, it is served as text/html, but it is using simple Apache content negotation to set that. So, I've got this bad feeling that IE is going to ignore the content-type header and just list it as raw XML with no stylesheet, because that is what would be a logical consequence of what you write. But I can't for the life of me understand how it can be standards-compliant... Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
Uh-oh I'm catching some bad vibs... Can someone do me a favour of going to http://www.kjernsmo.net/ with IE6 and see what happens? I don't think IE ignores the content-type header. It may be more lax than NS when it sees a file extension, but the home page of your site does not have any. The page displays fine with IE 6. -Erik - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
Oh, I get 406 code, I didn't know this one !! I have IE6 SP1 on Windows 2000 Pro. Babs -- website : www.babsfrance.fr.st ICQ : 135868405 - Original Message - From: Kjetil Kjernsmo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 11:42 PM Subject: Re: URL Theory Best Practices Uh-oh I'm catching some bad vibs... Can someone do me a favour of going to http://www.kjernsmo.net/ with IE6 and see what happens? The mainpage isn't a big thing, it is pure XHTML, but per the XHTML 1.0 spec, it is served as text/html, but it is using simple Apache content negotation to set that. So, I've got this bad feeling that IE is going to ignore the content-type header and just list it as raw XML with no stylesheet, because that is what would be a logical consequence of what you write. But I can't for the life of me understand how it can be standards-compliant... Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w __ Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
On Saturday 09 November 2002 23:57, Barbara Post wrote: Oh, I get 406 code, I didn't know this one !! I have IE6 SP1 on Windows 2000 Pro. Hehe, oh well, that's another browser quirk, but a much less serious so. I use language negotation too, so what everybody _should_ do is go into their settings and make sure they enable all languages they know how to read... Check out http://www.debian.org/intro/cn for a howto... Lacking that, browser vendors should add an *;q=0.001 to their language strings to avoid this error, but that's a lot more IMHO than the other things I've written in this thread... :-) I'd tried to talk the Mozilla folks into that in Bug 55800, http://bugzilla.mozilla.org/show_bug.cgi?id=55800 and the fact that you're getting 406 is proof that they are wrong... :-) Anyway, I've been logging language settings for a long time on one of my sites, and it was in fact very few users who had browsers were it would break, and language negotation is quite cool, so I decided to use it. Besides, those users who have it wrong could be catered for with a good error handler, if I had bothered... :-) Thanks for checking! :-) Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
I dont know if MS IE 6.0 is standard compliant of not. I dont care. I think MS IE try to be compliant. I develop under Linux. But I know too that MS IE 6.0 is the most used browser in the world. Then? I also check the MS IE presentation. I dont want to continue this polemic about if this will work or not. Make a simple example and you will see that: The use of PDF filename without extension in the MS IE 6.0 SP1 currently does not work. This is a fact! Maybe in the future we can make use of the URI without extension. But I am developing for current browser. Every developer must take care of that. Again, I agree with the theory of not use the extension. But for now. It does not work for PDF case under MS Windows. I already make use of the FOP and PDF serialization. Why make some wrong afirmation to people (mainly newbies) about how to make it when it does not work? At the end, please dont take me wrong. I am just trying to help. :-D Regards, Antonio Gallardo. Kjetil Kjernsmo dijo: On Saturday 09 November 2002 23:41, Antonio A. Gallardo Rivera wrote: The true is that I wrote. If you dont believe me, I recommend you to check the archive of this mailing list. This was not my fault. Not only I found this error many other people had the same problem with IE 6.0 SP1. I fighted with generation of PDF the content for a day after I realize that the extension must be .pdf or it will not work! This is why I told you about the fine theory and the cruel reality. :-D Uh-oh I'm catching some bad vibs... Can someone do me a favour of going to http://www.kjernsmo.net/ with IE6 and see what happens? The mainpage isn't a big thing, it is pure XHTML, but per the XHTML 1.0 spec, it is served as text/html, but it is using simple Apache content negotation to set that. So, I've got this bad feeling that IE is going to ignore the content-type header and just list it as raw XML with no stylesheet, because that is what would be a logical consequence of what you write. But I can't for the life of me understand how it can be standards-compliant... Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
Erik Bruchez dijo: Uh-oh I'm catching some bad vibs... Can someone do me a favour of going to http://www.kjernsmo.net/ with IE6 and see what happens? I don't think IE ignores the content-type header. It may be more lax than NS when it sees a file extension, but the home page of your site does not have any. The page displays fine with IE 6. -Erik I talked about the case of PDF serialization! Antonio Gallardo - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
On Saturday, November 9, 2002, at 12:08 PM, Miles Elam wrote: Tony Collen wrote: Comments inline... Miles Elam wrote: But can't delivered types differ by the incoming client? Yes, but a problem then arises when someone is using IE and they want a PDF, when your user-agent rules will only serve a PDF for FooCo PDF Browser 1.0. IMO browsers should respect the mime-type header. I believe the mime-type headers is very useful when you want to use something like a PHP script to send an image or a .tar.gz file. In fact, it's essential for it to work, otherwise the browser interprets the data as garbage. No, that's wasn't my intention at all. If someone is using IE and they want a pdf (not a default expectation for that particular browser like html or xml), then the URL they would get directed to would be *.pdf. This is not the intrinsic resource. You are explicitly asking for the PDF representation of that resource. If the browser's default expectation is PDF (like in your FooCo PDF Browser 1.0 example), the trailing slash resource would give it PDF. However, it could still be pointed to *.pdf if you wanted to make it explicit. This is very well put Miles, and was my intention with the previous email I wrote. Content negotiation and file extensions can (and IMO should) exist side-by-side. There is no precedent for a browser changing its accept header on a per-request basis, as someone suggested, not is there a way to specify this behavior in a hyper-link. If you have a link on a site that says Click here for a PDF then I would expect that the URI would end in .pdf, at least that's what makes the most sense to me. In those cases where only PDF is available (common when it's not dynamically generated), I see no reason why the URI wouldn't be *.pdf. Exactly. This is where we differ slightly. In my mind /a/b/ is the intrinsic resource. /a/b/index.html is the explicit call for HTML represention of /a/b/. If you redirect a client to /a/b/index.html and the client bookmarks it, they are bookmarking the HTML representation, not the intrinsic resource. This is definitely where we differ. I don't see why an intrinsic resource should always end in a '/'. If /a/b.pdf is the PDF representation then why shouldn't /a/b be the intrinsic resource? The only reason I see why the trailing slash is recommended is because developers are used to having their URI space tied to their filesystem structure with a static server like Apache. The trailing slash, from our experience with filesystems, indicates that something is a directory, that it has children. But in a URI a resource can be both a viewable resource and a container node at the same time. There's certainly nothing stopping /a/b/, /a/b, /a/b.pdf and /a/b/c.pdf from all being valid URI's in the same space. To me the trailing slash simple indicates that there's more to come at lower levels, and the absence of it means the resource is a leaf. As for redirects, I don't see it being too much of a problem with more recent protocols. Also it should only happen when a visitor is being referred from an external page, since all the URL's in your site should be in the correct form. If you are linking to the intrinsic resource, I don't see the need for a redirect (as long as the browser correctly understands the mime-type header), so I don't see a problem with bookmarking. - Miles P.S. Thank god for the mailing lists. They actually encourages me to write down some of my thoughts. Even they are off the mark more often than not... Does this make email better than web or simply justify the need for more discussion on the web? Here here. I say both, linear discussion is good, so is collaboration. A discussion board combined with a wiki would be awesome. Discuss a topic and collaborate on a document summing up the ideas at the same time. Hmm... Cocoon could do that :) -Justin - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForm - xf:repeat tag on DOM Nodes?
Stupid me, I sent the code snippet before fix it. That's what I meant exactly, and it's working good. I just had some incorrect mappings in the model. You know? It took me a lot of time to understand this whole XMLForms thingie of you. Now that it seems I know what I'm doing I must say I really like this approach to forms. Thanks you very much for providing it :-) Btw, some people are missing a dynamic model, I mean, they say you must create it before hand. It would be pretty nice to see it in a next version, sometime, but I can say to those, that using DOM nodes and documents and manipulating them inside the action, can give a lot of power to make things dynamic :-) Thanks again. - Original Message - From: Ivelin Ivanov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 8:15 PM Subject: Re: XMLForm - xf:repeat tag on DOM Nodes? You probably meant to use: xf:repeat nodeset=/productNode/product/description xf:textbox ref=@lang xf:captionLanguage (code):/xf:caption xf:violations class=error/ /xf:textbox xf:textbox ref=. xf:captionDescription:/xf:caption xf:violations class=error/ /xf:textbox /xf:repeat I would also recommend that you use the standard xml:lang attribute instead of a non-qualified one. Ivelin - Original Message - From: Josema Alonso [EMAIL PROTECTED] To: Cocoon-Users [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 12:40 PM Subject: XMLForm - xf:repeat tag on DOM Nodes? Dear all, I see in thw wizrd demo how the repeat tag is used like this: xf:repeat nodeset=favorite[position() lt;= 3] id=favorites xf:textbox ref=. class=info xf:captionURL: /xf:caption /xf:textbox /xf:repeat In the model bean the favorite is implemented as an array list, so you can iterate through it using the position function and specifying how many items to display. Well, now I got a part of my model implmented as a DOM Node. It seems it'w working right but I can't make the repeat tag to work with it. Let's say I have something like this: product description lang=ennice table/description description lang=esmesa bonita/description /product I want to display as many textboxes as descriptions, ok? I have tried this, but unfortunately it is not working. : xf:repeat nodeset=/productNode/product xf:textbox ref=description/@lang xf:captionLanguage (code):/xf:caption xf:violations class=error/ /xf:textbox xf:textbox ref=description xf:captionDescription:/xf:caption xf:violations class=error/ /xf:textbox /xf:repeat If I try to access just one description node outside the repeat tag, I get the info correctly. Any ideas? Thanks. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)
I am not sure if I would do this like you did.
There are is a certain lifecycle contract between every Cocoon component
and
the container.
By invoking directly you may be violating this contract.
I would probably let the sitemap do the forwarding to actions.
In your case action sets might be good.
http://xml.apache.org/cocoon/userdocs/concepts/actions.html
I considered them and maybe I'll use them. I'm trying to make a good
decision.
Alternatively you can use one dispatcher action which inherits from
AbstractXMLFormAction and works directly with the backend based on the
requested command.
I see. Someone pointed this one, too, but I'm that Avalon savvy to implement
something like this currently.
Yet another alternative is for the extending action to return an
objectmodel
parameter which is matched later in the sitemap.
map:action type=myxmlformaction
...
map:call src=cocoon:{whichaction}
This one sounds new, interesting and easy to code. I'll give it a try :-)
Thank you very much.
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)
- Original Message -
From: Josema Alonso [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 09, 2002 5:35 PM
Subject: Re: how to manage several XMLForms in a sitemap? (it was:
dynamically choosing an action at runtime)
I am not sure if I would do this like you did.
There are is a certain lifecycle contract between every Cocoon component
and
the container.
By invoking directly you may be violating this contract.
I would probably let the sitemap do the forwarding to actions.
In your case action sets might be good.
http://xml.apache.org/cocoon/userdocs/concepts/actions.html
I considered them and maybe I'll use them. I'm trying to make a good
decision.
Alternatively you can use one dispatcher action which inherits from
AbstractXMLFormAction and works directly with the backend based on the
requested command.
I see. Someone pointed this one, too, but I'm that Avalon savvy to
implement
something like this currently.
Just open org.apache.cocoon.samples.xmlform.WizardAction.java
then look more carefully in webapp/samples/xmlform
Yet another alternative is for the extending action to return an
objectmodel
parameter which is matched later in the sitemap.
map:action type=myxmlformaction
...
map:call src=cocoon:{whichaction}
This one sounds new, interesting and easy to code. I'll give it a try :-)
Thank you very much.
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
Justin Fagnani-Bell wrote: This is where we differ slightly. In my mind /a/b/ is the intrinsic resource. /a/b/index.html is the explicit call for HTML represention of /a/b/. If you redirect a client to /a/b/index.html and the client bookmarks it, they are bookmarking the HTML representation, not the intrinsic resource. This is definitely where we differ. I don't see why an intrinsic resource should always end in a '/'. If /a/b.pdf is the PDF representation then why shouldn't /a/b be the intrinsic resource? The only reason I see why the trailing slash is recommended is because developers are used to having their URI space tied to their filesystem structure with a static server like Apache. The trailing slash, from our experience with filesystems, indicates that something is a directory, that it has children. But in a URI a resource can be both a viewable resource and a container node at the same time. There's certainly nothing stopping /a/b/, /a/b, /a/b.pdf and /a/b/c.pdf from all being valid URI's in the same space. To me the trailing slash simple indicates that there's more to come at lower levels, and the absence of it means the resource is a leaf. You're right in that it is what we are used to but not necessarily because of the filesystem. I misspoke in this case where /a/b could indeed be a resource in some cases. One major problem lies in clients like IE (for better or for worse the dominant viewer) which don't always behave correctly even when the correct MIME type is sent. The other is when the resource references other resources. Take a web article by Oreilly for example. These articles have images, multiple pages, talkbacks, etc. If /a/b is the intrinsic resource, how do we logically access the first figure in that article? How do we access the third page? Aren't multiple pages just another representation of the resource? PDFs can encompass multiple pages. A web page made for printout would encompass only one long page. Would it be /a/b/printable.html? Is one more correct than another? I don't think so -- it seems to come down to personal preference, all other things being equal. I think IE would have fewer problems with the slash. I personally don't view the trailing slash as a directory but as a resource collection. Perhaps a collection of representations? But that's just semantics and I'm grasping here. In the example of the Oreilly article, I think that there is more to come at the lower levels, there is no absence of lower levels when representations are considered lower levels, and that it's a node and not a leaf. I can only think that a resource would be a leaf if it and its siblings never have inline constituents like images, multiple pages, plugins, etc.. P.S. Thank god for the mailing lists. They actually encourages me to write down some of my thoughts. Even they are off the mark more often than not... Does this make email better than web or simply justify the need for more discussion on the web? But it apparently has a detrimental effect on my proper use of English grammar. *sigh* - Miles - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Theory Best Practices
Nevermind. I take it all back (well...some of it). I admit that the trailing slash is an artifact of my experience and not of utility. Damned mailing lists...you can't remove things you wish you hadn't said. Accountability's overrated. ;-) - Miles Miles Elam wrote: Justin Fagnani-Bell wrote: This is definitely where we differ. I don't see why an intrinsic resource should always end in a '/'. If /a/b.pdf is the PDF representation then why shouldn't /a/b be the intrinsic resource? The only reason I see why the trailing slash is recommended is because developers are used to having their URI space tied to their filesystem structure with a static server like Apache. The trailing slash, from our experience with filesystems, indicates that something is a directory, that it has children. But in a URI a resource can be both a viewable resource and a container node at the same time. There's certainly nothing stopping /a/b/, /a/b, /a/b.pdf and /a/b/c.pdf from all being valid URI's in the same space. To me the trailing slash simple indicates that there's more to come at lower levels, and the absence of it means the resource is a leaf. You're right in that it is what we are used to but not necessarily because of the filesystem. I misspoke in this case where /a/b could indeed be a resource in some cases. One major problem lies in clients like IE (for better or for worse the dominant viewer) which don't always behave correctly even when the correct MIME type is sent. The other is when the resource references other resources. Take a web article by Oreilly for example. These articles have images, multiple pages, talkbacks, etc. If /a/b is the intrinsic resource, how do we logically access the first figure in that article? How do we access the third page? Aren't multiple pages just another representation of the resource? PDFs can encompass multiple pages. A web page made for printout would encompass only one long page. Would it be /a/b/printable.html? Is one more correct than another? I don't think so -- it seems to come down to personal preference, all other things being equal. I think IE would have fewer problems with the slash. I personally don't view the trailing slash as a directory but as a resource collection. Perhaps a collection of representations? But that's just semantics and I'm grasping here. In the example of the Oreilly article, I think that there is more to come at the lower levels, there is no absence of lower levels when representations are considered lower levels, and that it's a node and not a leaf. I can only think that a resource would be a leaf if it and its siblings never have inline constituents like images, multiple pages, plugins, etc.. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OFF-TOPIC] WAP 2.0 and XHTMLMP vrs. WML
Hi, I am currently reading the book of Carsten and Matthew. I have interest in the support of the WAP technology and similars with Cocoon. Of course to use it we must to know this technologies too. Well, thanks to the book, I am now buying new books about SVG and XSL-FO. To learn about this technologies. Also I made a little research around to find a nice book that will help me in the Wireless world. I was searching for books in amazon.com. Then I saw that there is now a new WAP 2.0 (January 2002) that said: The WAP 2.0 Application Environment (WAE) has evolved to embrace developing standards for Internet browser markup language. This has led to the definition of the XHTML Mobile Profile (XHTMLMP). XHTMLMP is based on the modularity framework of the XHTML developed by W3C to replace and enhance the currently used HTML language common today In another paragraph: The basic markup language for the WAE in WAP 2.0, namely XHTMLMP, extends the Basic profile of XHTML as defined in W3C. This core was designed to be extensible and WAE takes advantage of this capability by defining additional markup features for enhanced functionality. By using the XHTML modularization approach, the XHTMLMP language is very extensible, permitting additional language elements to be added as needed. Additionally, documents written in the core XHTML Basic language will be completly operable on the XHTMLMP browser. Source: http://www.wapforum.org/ That means that we dont need to learn WML1 because XHTMLMP is the future? What you think? Please, comments are welcome. Antonio Gallardo - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForm - xf:repeat tag on DOM Nodes?
- Original Message - From: Josema Alonso [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 6:32 PM Subject: Re: XMLForm - xf:repeat tag on DOM Nodes? Stupid me, I sent the code snippet before fix it. That's what I meant exactly, and it's working good. I just had some incorrect mappings in the model. You know? It took me a lot of time to understand this whole XMLForms thingie of you. Now that it seems I know what I'm doing I must say I really like this approach to forms. Thanks you very much for providing it :-) Btw, some people are missing a dynamic model, I mean, they say you must create it before hand. It would be pretty nice to see it in a next version, sometime, but I can say to those, that using DOM nodes and documents and manipulating them inside the action, can give a lot of power to make things dynamic :-) Yes. This has been requested multiple times. Please open a feature request ticket in Bugzilla and describe with a few detailed use cases, what is it exactly that you would like to have. Others will add their thoughts to the ticket and someone (maybe I) will eventually implement it. Thanks, Ivelin Thanks again. - Original Message - From: Ivelin Ivanov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 8:15 PM Subject: Re: XMLForm - xf:repeat tag on DOM Nodes? You probably meant to use: xf:repeat nodeset=/productNode/product/description xf:textbox ref=@lang xf:captionLanguage (code):/xf:caption xf:violations class=error/ /xf:textbox xf:textbox ref=. xf:captionDescription:/xf:caption xf:violations class=error/ /xf:textbox /xf:repeat I would also recommend that you use the standard xml:lang attribute instead of a non-qualified one. Ivelin - Original Message - From: Josema Alonso [EMAIL PROTECTED] To: Cocoon-Users [EMAIL PROTECTED] Sent: Saturday, November 09, 2002 12:40 PM Subject: XMLForm - xf:repeat tag on DOM Nodes? Dear all, I see in thw wizrd demo how the repeat tag is used like this: xf:repeat nodeset=favorite[position() lt;= 3] id=favorites xf:textbox ref=. class=info xf:captionURL: /xf:caption /xf:textbox /xf:repeat In the model bean the favorite is implemented as an array list, so you can iterate through it using the position function and specifying how many items to display. Well, now I got a part of my model implmented as a DOM Node. It seems it'w working right but I can't make the repeat tag to work with it. Let's say I have something like this: product description lang=ennice table/description description lang=esmesa bonita/description /product I want to display as many textboxes as descriptions, ok? I have tried this, but unfortunately it is not working. : xf:repeat nodeset=/productNode/product xf:textbox ref=description/@lang xf:captionLanguage (code):/xf:caption xf:violations class=error/ /xf:textbox xf:textbox ref=description xf:captionDescription:/xf:caption xf:violations class=error/ /xf:textbox /xf:repeat If I try to access just one description node outside the repeat tag, I get the info correctly. Any ideas? Thanks. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
