virtual hosting in the webapp/cocoon directory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Is it possible to have virtual hosts mapped to subdirectories within the single cocoon context? For example if I have http://www.bighost.com/cocoon/host1/ and http://www.bighost.com/cocoon/host2/ can I have the two virtual hosts http://www.host1.com/ and http://www.host2.com/ respectively hosting the same content? I would like to have just one cocoon running but provide virtual hosting with subdirectories in the webapp/cocoon directory. Help appreciated. Thanks in advance. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8y94enn5W2XX2wYoRArHZAJ98/AGCLJ7aoymvsBd1RhYPmDPb/gCgggsD BmbrpO4HUZA0sp5NLaxEkYM= =hZsZ -END PGP SIGNATURE- - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: Serving static XML files a la Cocoon-1
Sometimes you need to use unique XSL file for several XML files,
but this is also solved by the sitemap in a varios ways, e.g.:
map:match pattern=3D*.xml
map:generate src=3D{1}.xml/
map:transform src=3D{1}.xsl/
map:serialize /
/map:match
That 1:1 kind of match is very rare. Much more importantly, there
seems to be no provision in sitemap.xmap for binding a stylesheet to a
DTD. Let's suppose I have 3,000 DocBook article documents in many
many directories, but these directories also contain many other .xml
files (related to the articles in many different ways) which require
different stylesheets, according to their DTD.
I want all *.xml files which use DocBook article to be served into
HTML using foo.xsl; all *.xml which use (say) TEI-Lite to be served
using another stylesheet, etc etc. Can this be done?
///Peter
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Key distinction: DTDs are used to *VALIDATE*, not render. That's one reason. The other is to allow the document to be edited in a structured editor. Our documents are all created by humans, so we need to use a system which guides creation and editing. The Document Type Declaration is therefore present in the XML file so that the type of document can be detected by software (whether or not the DTD is used). The root element type name is insufficient for this (too many DTDs for articles use the root element type article already :-) True, but it is not uncomon to have a working stylsheet in applications, and before release the web monkeys are let loose to make it look nice. Of course both these developments can be happening simultaneously. THe doc writer should not care how the info is presented, that isn't their concern. This is a contentious point. Frequently the doc writer is the only one who knows how the information should be presented: document stylists are notoriously ignorant of technical matters, just as authors are notoriously ignorant of typographic matters. The sample sitemap bundled with Cocoon offers these 'defaults' already. If that is so, why does it not transform my sample XML document with its accompanying XSL stylesheet? Are you volunteering to write something that reacts to PIs? :-) Done too many of them already. It's not really a trivial task, and considering the amount of work involved in it, for something we really don't want to encourage, its not a likely thing to happen soon. No, I don't want to if I can avoid it. PIs should be kept for their real task: affecting processing *outside* the domain of the processor (think TeX/dvi \specials). Basically tweaks. Going back to your associated XSL document, and distributing the files w/o a server: you can still do that with your PIs. A browser that knows how to treat the PIs will do so correctly. However, for serving up to older browsers, you should use the preferred method. Your Sitemap won't change much. You stated something like every few years. When you change your site, you only need to update the sitemap to point to the new stylesheet--even if you have hundreds of documents by then. I still need to bind a stylesheet to the documents. The Document Type is the obvious key, but I can't see how to achieve this in sitemap.xmap ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
Key distinction: DTDs are used to *VALIDATE*, not render. This is a common fallacy, fast attaining status of an Urban Myth. DTDs may also be required at the rendering stage if they contain default or fixed attribute values, declarations of external entities, notations, or id/idref attributes. DTDs are also required by some editors, as mentioned earlier, not because they perform validation (which is useful) but because they are used to guide or prompt (and sometimes force :-) the author while writing (a form of validation, but not the act of validation). ///Peter - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serving static XML files a la Cocoon-1
=?ISO-8859-1?Q?C=E9dric_Damioli?= [EMAIL PROTECTED] writes:
Of course you don't have to put an entry for each new doc : you simply
need the most common C2 pipeline:
map:match pattern=**.xml
map:generate src={1}.xml/
map:generate src=stylesheet.xsl/
map:serialize/
/map:match
This pipeline will process all the .xml files on your server. Does it
match your needs?
This assumes that all documents are processable using the same
stylesheet, which is not the case:
1. Documents of different types often require different stylesheets
because that is their nature: they describe different things, and
styling is a convenient way of communicating this to a reader.
2. Documents of different types may reside in the same directory, and
their filenames cannot be used to identify the document type (nor
should they be, they're already abused to carry way too much
information :-).
3. The document type is identified in the Document Type Declaration
in each file. This is what it's for.
4. Different document types can have a root element type name which is
the same (cf. ISO 12083 book vs. DocBook's book).
Am I right in assuming that Cocoon-2 is based on the premise that
all distinction between document files can be done only on the basis
of directory/file names (and REs matching them)?
The DocType Declaration is the only authoritative statement of the
document type. That is why is exists. If the PI has (rightly) been
retired as Cocoon's flag mechanism, something needs to be introduced
to replace it.
I realise this borders on heresy for some people, because it smacks of
using DTDs, which are anathema to many. But I'm afraid it's the
reality of publishing: not all documents are the same, and directory
and file names are not always [ab]usable as discriminators.
In another project, the opposite is true: documents are submitted for
inclusion in a huge range of document types (read: DTDs) but they
are required to look the same when viewed. Hence one stylesheet per
DTD, implementing lots of ways of getting a consistent look.
Maybe Cocoon can't be used for this any more, in which case I
apologise for wasting your time.
///Peter
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with XSP
Torsten Curdt wrote: transform it once to add the line numbers. (it would be cool if the XSP logicsheet could already provide this. but I fear that's not possible with XSLT) ... xsp:logic /* line:4 */ int a = 5; Saxon has an extension function to retrieve the line number of the context node (saxon:lineNumber()). Maybe Xalan has an equivalent. J.Pietschmann - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Redirector and character encoding
Hello, I'm using Redirector.redirect with a url like message?msg=Confirmación test The action that process the http requests uses Request.setCharacterEncoding at the beginning, and it works fine when I receive form posts with special characters, but it doesn't when I receive a URL with parameters. Some encoding is going on as spaces are translated to %20, but not special characters áéíóú. There's a way to avoid encoding the url I pass to redirect( bsessionmode, sUrl ) or, if I have to encode it, some helper method to do it? I'm with cocoon-2.0.2 over tomcat 4.0.1 Thanks, Ivan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
(Stream)Generator
I try to write a generator who accepts multipart/related posts.
How do i get the content of the post-message?
I tried it with the following:
HttpServletRequest request = (HttpServletRequest)
objectModel.get(HttpEnvironment.HTTP_REQUEST_OBJECT);
InputStreamReader instream = new InputStreamReader ( request.getInputStream() );
BufferedReader reader = new BufferedReader( instream );
while ((line=reader.readLine()) != null){
System.out.println(line);
}
But i don't see any output on the console, so how can i access and
parse the request?
I hope you understand my problem and can help me.
--
Best regards,
Michael mailto:[EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: virtual hosting in the webapp/cocoon directory?
From: Ben Skelton [mailto:[EMAIL PROTECTED]] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Is it possible to have virtual hosts mapped to subdirectories within the single cocoon context? Yes. For example if I have http://www.bighost.com/cocoon/host1/ and http://www.bighost.com/cocoon/host2/ can I have the two virtual hosts http://www.host1.com/ and http://www.host2.com/ respectively hosting the same content? Yes. I would like to have just one cocoon running but provide virtual hosting with subdirectories in the webapp/cocoon directory. See RegexpHostMatcher, WildcardHostMatcher, HostSelector. Vadim Help appreciated. Thanks in advance. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8y94enn5W2XX2wYoRArHZAJ98/AGCLJ7aoymvsBd1RhYPmDPb/gCgggsD BmbrpO4HUZA0sp5NLaxEkYM= =hZsZ -END PGP SIGNATURE- - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.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/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HOWTO: Serving static XML files a la Cocoon-1
Hi Peter,
Here's one way to respect processing instructions in Cocoon2:
Create a pipeline which reads an xml doc, finds the PI element and returns
the contents of the xsl document which it specifies. I've called this
get-stylesheet.xsl, since it returns the stylesheet for a document. It
will return different stylesheets depending on the source document.
Create a separate pipeline which reads an xml doc and transforms it using
the stylesheet returned by the first pipeline.
I've done a little example, which I enclose. It is pretty basic - it assumes
all stylesheets are in the same folder, assumes they all produce html, and
it handles only 1 PI per source document, which it assumes refers to an XSL
stylesheet, but it's simple and you can easily modify it to suit a more
complicated setup if necessary.
The source documents (example/documents/*.xml) are assumed to contain a PI
like the one below:
?xml-stylesheet href=hello.xsl type=text/xsl?
The hello.xsl file is assumed to be in the example/stylesheets folder.
The sitemap snippet defines the 2 pipelines:
map:match pattern=get-stylesheet-for/*.xml
map:generate src=example/documents/{1}.xml/
map:transform src=example/stylesheets/get-stylesheet.xsl/
map:serialize type=xml/
/map:match
map:match pattern=test/*.html
map:generate src=example/documents/{1}.xml/
map:transform src=cocoon://get-stylesheet-for/{1}.xml/
map:serialize type=html/
/map:match
The stylesheet get-stylesheet.xsl:
-
?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
!-- copy contents of the PI's href --
xsl:template match=processing-instruction()
xsl:variable name=stylesheet
select=substring-before(substring-after(.,'href=quot;'),'quot;')
/
xsl:apply-templates mode=copy select=document($stylesheet)/
/xsl:template
!-- ignore the rest of the document --
xsl:template match=@*|*/
!-- for copying the stylesheet referred to by the PI --
xsl:template match=@*|node() mode=copy
xsl:copy
xsl:apply-templates select=@*|node() mode=copy/
/xsl:copy
/xsl:template
/xsl:stylesheet
-
The
-Original Message-
From: Peter Flynn [mailto:[EMAIL PROTECTED]]
Sent: Monday, 29 April 2002 01:45
To: [EMAIL PROTECTED]
Subject: Re: Serving static XML files a la Cocoon-1
Key distinction:
DTDs are used to *VALIDATE*, not render.
That's one reason. The other is to allow the document to be edited in
a structured editor. Our documents are all created by humans, so we
need to use a system which guides creation and editing. The Document
Type Declaration is therefore present in the XML file so that the
type of document can be detected by software (whether or not the DTD
is used). The root element type name is insufficient for this (too
many DTDs for articles use the root element type article already :-)
True, but it is not uncomon to have a working stylsheet in
applications, and before release the web monkeys are let loose to
make it look nice. Of course both these developments can be
happening simultaneously. THe doc writer should not care how the
info is presented, that isn't their concern.
This is a contentious point. Frequently the doc writer is the only one
who knows how the information should be presented: document stylists
are notoriously ignorant of technical matters, just as authors are
notoriously ignorant of typographic matters.
The sample sitemap bundled with Cocoon offers these
'defaults' already.
If that is so, why does it not transform my sample XML
document with
its accompanying XSL stylesheet?
Are you volunteering to write something that reacts to PIs?
:-) Done too many of them already.
It's not really a trivial task, and considering the amount of work
involved in it, for something we really don't want to encourage,
its not a likely thing to happen soon.
No, I don't want to if I can avoid it. PIs should be kept for their
real task: affecting processing *outside* the domain of the processor
(think TeX/dvi \specials). Basically tweaks.
Going back to your associated XSL document, and
distributing the files
w/o a server: you can still do that with your PIs. A
browser that knows
how to treat the PIs will do so correctly. However, for
serving up to
older browsers, you should use the preferred method. Your
Sitemap won't
change much. You stated something like every few years. When you
change your site, you only need to update the sitemap to
point to the
new stylesheet--even if you have hundreds of documents by then.
I still need to bind a stylesheet to the documents. The Document Type
is the obvious key, but I can't see how to achieve this in
sitemap.xmap
///Peter
-
Please check that your question has not already been
ContextSourceFactory problem
Hi there, Sorry, I am not sure if this is a bug, that's why I am posting this here: Using the latest code from cvs (2.1 dev) I tried out all samples. The following does not work for me: o search (Lucene) otutorial o protected area o poisamples Everytime I try to execute one of these I get a stacktrace. The interesting thing is the top of the stack looks always like: java.lang.NullPointerExceptionat org.apache.cocoon.components.source.impl.ContextSourceFactory.getSource(ContextSourceFactory.java:105)at org.apache.excalibur.source.impl.SourceResolverImpl.resolveURI(SourceResolverImpl.java:266)at org.apache.cocoon.components.CocoonComponentManager.resolveURI(CocoonComponentManager.java:279)at org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:430)at org.apache.cocoon.environment.AbstractEnvironment.resolveURI(AbstractEnvironment.java:420)at org.apache.cocoon.environment.AbstractEnvironment.resolve(AbstractEnvironment.java:361) Further analysis revealed Cocoonwas not able to resolve: (in the case of search:) 'context://stylesheets/dynamic-page2html.xsl' in context 'file:/C:/eclipseworkspace/test/webapp/search/' (in the case of protected area sample:) 'context://protected/descriptors/params.xml' in context 'file:/C:/eclipseworkspace/test/webapp/protected/'(in the case of poi samples:) 'context://stylesheets/simple-samples2html.xsl' in context 'file:/C:/eclipseworkspace/test/webapp/samples/poi/' when invoking the tutorial I getjava.io.FileNotFoundException: C:\eclipseworkspace\test\webapp\common\style\xsl\html\error2html.xsl (The system cannot find the path specified) which should be found in C:\eclipseworkspace\test\webapp\SAMPLES\common\style\xsl\html\error2html.xsl I am always crashing in ContextSourceFactory.getSource(String, Map) When executing the following: envContext = (Context)this.context.get(Constants.CONTEXT_ENVIRONMENT_CONTEXT); context is always null. Looks to me the "context://" defined components are not getting resolved correctly. I wonder what's going on here. Everything else including JDBC runs fine. thanks, Horst (XP, JDK1.4, Tomcat 4.0.4-b2, C2.1-dev) PS: Complete stacktraces are available on request.
