Re: conditional cincludes?

[Michael Riedel]

> How do I check for the instance of a file before
> attempting to cinclude it?  Basically, I don't
> want the pipeline to die if the file isn't found.

If that's the only thing you need, maybe the following use of the cinclude
tag might help:


foo/bar.xml


I found it in the documentation
(http://cocoon.apache.org/2.1/userdocs/transformers/cinclude-transformer.htm
l), but have not tried it myself yet.

If there are other criteria for use cinclude or not, you might insert an
XSLT-transformer before the CInclude-Transformer. The XSLT might then add
the cinclude tags only under certrain conditions.

-- Michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problems with Cocoon 2.1 dev (CVS)

[Michael Riedel]

> today i wanted to build and install the newest
> Cocoon 2.1 dev from CVS. I did it like always (build war),
> but this time the compiled Cocoon didn't work.

I had the same problem, even though a few days already passed. The
Cocoon-Servlet works, but only deliveres the error-message you mentioned:

>  Request Processing Failed
>
> Message: Cocoon engine failed in process the request
>
> Description: The processing engine failed to process
> the request. This could be due to lack of matching or
> bugs in the pipeline engine.
>
> Sender: org.apache.cocoon.servlet.CocoonServlet
>
> Source: Cocoon Servlet
>
> Request URI
> request-uri
> /cocoon/
>
> Apache Cocoon 2.1-dev

It is displayed, whenever you request the welcome-page, or any other page
which should normally apear. If a resource which is not specified in the
sitemap is requested, another error-message apears. But since it states

Also when I build I get the following error at the end:

  validate-xdocs:
  Conducting validation of core XML documentation.
  Validating all **/book.xml instances using RELAX NG ...
  Fatal error: exception "java.net.MalformedURLException" thrown: no
protocol: dtd/book-cocoon-v10.dtd

  BUILD FAILED

file:///G:/Dokumente%20und%20Einstellungen/Michael/Eigene%20Dateien/WebSites
/cocoon-2.1/build.xml:835: Validation failed, messages should have been
provided.

... but anything else seams to be built correctly. Also when I set
validate.xdocs=false in local.build.properties, the error does not occur,
and the build is successfull. So I don't think, the problem lies here.

However, I have no clue what could still be wrong. None of the hints from
the mail-list worked for me so far. And I've also tried several CVS updates
by now, so it's not a temporar problem.

-- Michael Riedel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: A Gzipped XML Serializer component for Cocoon

[Michael Riedel]

Hi Bruce!

> I'm pretty sure this is something that eventually should be rolled into
> Cocoon itself, but as I note in the page, my code is a hack on the
> XMLSerializer, and shouldn't be ci'd as-is.

Though I don't need it at this time, I agree, that gzip compression is a
quite usefull. It should be included in the cocoon distribution.

But I'm not sure, if compression should be handled by a serializer. What, if
someone wants to compress something else than XML data. Then he'd have to
rewrite another serializer to support gzip. (I have to admit, I don't have
good application examples right now, since most of the other serializers
produce some kind of compressed data anyway.) What I'm trying to say is,
that compression is orthogonal to the actual data-format.

Wouldn't it be more usefull, if compression was a seperate feature? I'd
suggest a reader handling the gzip-compression.
It could be used to compress any kind of data, both static and dynamic. To
generate a compressed version of a dynamic resource, the reader could access
the uncompressed version through the cocoon-protocol.
(I have to admit, that I have never tried, if using the cocoon-protocol with
a reader really works. But in my oppinion such an approach might be usefull,
whenever non-xml data needs further processing.)

Here is some sitemap fragment, to demonstrate my thoughts. It's only a
scetch, so it might contain some bugs:

  
...

  
  ...
  

  ...
  


  

  

I'd like to hear other people's oppinion on this topic. If anyone is
interested, I could try to refactor to gzipped-xml-serializer to a reader.
I'd like to see if the above sitemap fragment really works.

A possible problem, when seriallization and compression are seperated might
be the caching-behavior. Can the output of a reader be cached at all? If
yes, both an uncompressed and a compressed version would be cached. And
then, does the cocoon-protocoll check if the requested resource has changed?
If no, caching of the compressed resource would be useless.

Greets, Michael Riedel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Accessing SVG's in Cocoon via SVG Serializer

[Michael Riedel]

> I've a question regarding href's in the image tag of SVG's. Is there a way
to
> access the actual sitemap context from an svg?
I also have Problems including external Images during SVG serialization. In
my case it's about JPEGs, but that shouldn't do a difference.

> Example Sitemap:
> 
> 
>  />
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> Example resizer.xsl:
>   
>   
> 
>   
> 
> 

My Sitemap and XSLT look quite similar to yours, but the only way I can
include external images into the SVG is through a http:// URL. This might be
a solution for your Problem with including dynamically generated images. But
for me it is not a that good solution, since the http:// URL on my
develpment system is different from the one on the production system.

> The example above doesn't work.
Being able to use the cocoon: protocol would be great, but it does not seem
to work in my webapp either. Do you have any idea why? I've already tried it
with cocoon 2.0.1, 2.0.2 and 2.0.3. I think this should be fixed if
possible...

> Using file:// is no problem, but I want to use
> it with dynamically created content, so I can't access the filesystem
> directly.
I suppose this only works with absolute paths, which is again no good
solution for me. Have you ever had it running with relative paths? I wasn't
able to...

-- Michael Riedel


-
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]>

entity catalog

[Michael Riedel]

I was just wondering, if it wouldn't be usefull to add some more entries to
the default entity catalog that comes with cocoon2. Recently I started to
use XHTML source files, instead of HTML4, and the file-generator always
wanted to get the DTD from the net. Since I prefer to work offline, I wasn't
able to to generate from those files at all.

Two simple lines in the "catalog" file fixed this problem, and now I can
work offline with my own version of the DTD. But I think it is quite messy
having to add such things to a configuration-file which influences the whole
cocoon system. It would be nice, if the default "catalog" file contained
some entries for DTD of files which are frequently used together with
cocoon, and if those DTDs were part of the distribution. (I'd suggest to
include at least the DTDs for XHTML, SVG, XSL. But I'm sure there are many
more...)

Since I like the concept of SubSiteMaps very much, it would be even better,
if the catalog would support a bit more modularity, too. I know, that this
is not possible by setting up some special pipelines or transformations to
handle Entities, because they cannot influence the parsing process. But
maybe there is some other possibility, e.g. by specifying an own catalog for
each pipeline. Or it could be achieved by redefining the file-generator
telling it which entity-resolver the underlying parser should use.

Is there already another posibility to handle catalogs a cleaner way? (I
know, I often oversee such important things.) If not It would be great to
include some more stuff in the default "catalog" file, or to think about how
to improve the handling of catalogs.

Hope someone is interested in discussing this topic,
Michael


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>