RE: problem with WebServiceProxyGenerator
I have been periodically scanning the list for almost a year, hoping that someone would take this bull by the horns, i.e. wsproxy in general. At SU Law, we are currently supporting legacy ASP pages through use of the HTMLGenerator and hard-coded GET params in sitemap.xmap. I have really been looking forward to a better approach, especially since it would be nice to just allow our Web developer to use her ASP skills to develop forms, surveys, etc. (provided that they generate well-formed output) and know we can integrate them into our Cocoon-based Web site in a solid and maintenance-friendly way. Other features needed to make WebServiceProxyGenerator feature-complete, at least for us, include: * Remote HTTP authentication support * Reverse redirects, a la Apache's ProxyPassReverse directive [1] Good luck to whomever tries to fix the issues with WebServiceProxyGenerator! You can count me as another user eagerly awaiting to see progress in this area. Thanks, Evan Lenz Content Management Architect Seattle University School of Law [1] http://httpd.apache.org/docs/mod/mod_proxy.html#proxypassreverse -Original Message- From: Tony Collen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 12:08 PM To: [EMAIL PROTECTED] Subject: Re: problem with WebServiceProxyGenerator Joerg Heinicke wrote: There seems to be a real problem with WebServiceProxyGenerator: http://www.mail-archive.com/[EMAIL PROTECTED]/msg27925.html Yeah, It's looking that way :( I've noticed posts from other people asking about this, too -- no replies. I'm a little short on time this afternoon, I'll try to dig into it tonight after class... Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem with WebServiceProxyGenerator
A year?! Yoink. I had some mods to the WSPG a while ago and I know it was working correctly. I don't think they were that long ago, though. Sorry, I didn't mean to imply that it had been completely broken for a year, but just that for whatever reason it has never been up to snuff for what we wanted to use it for. Other features needed to make WebServiceProxyGenerator feature-complete, at least for us, include: * Remote HTTP authentication support * Reverse redirects, a la Apache's ProxyPassReverse directive [1] I do know the HttpProxyGenerator was intended as a replacement for the WSPG, but as previous posts have mentioned, the newer proxygenerator doesn't contain all of the functionality of the WSPG yet. It would be nice to get all of the functionality merged into one nice component (which has the added bonus of working correctly ;) ) Yes, that sounds good to me! Evan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cocoon/tomcat memory usage
I'm trying to further utilize the memory resources of our Linux server for Cocoon by increasing the StoreJanitor heapsize and Java -Xmx parameters. My current settings are as follows: In tomcat4.conf: JAVACMD=$JAVA_HOME/bin/java -Xmx360m In cocoon.xconf (inside the store-janitor element): parameter name=freememory value=2000/ parameter name=heapsize value=33600/ Performance has visibly improved as a result. However, actual memory usage (per top output) seems to peak at 111-112M, no matter what I throw at the server. How do I make the JVM and Tomcat/Cocoon utilize more of my machine's memory (thereby further improving performance hopefully)? Thanks, Evan Lenz - 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: Separation of concerns?
I've taken this approach in the past. I've found that it involves heavy (or
at least essential) use of the document() function. This approach has been
documented in a couple articles on XML.com.
http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html
http://www.xml.com/pub/a/2002/03/27/templatexslt.html
But I learned there are apparently problems with use of the document()
function in Cocoon, given current limitations with respect to caching.
http://xml.apache.org/cocoon/faq/faq-xslt.html#faq-6
I was pleased to find Leigh Dodds' note on the Cocoon Wiki for
metastylesheets.
http://outerthought.net/wiki/Wiki.jsp?page=MetaStylesheets
I'm now successfully using this approach in my current project to implement
custom tag libraries in Cocoon without needing to use the document()
function.
However, I am wondering how much this approach really scales. I guess I will
find out.
I believe that putting XSLT into the hands of graphic designers and average
Web developers does *not* achieve separation of concerns. Custom tag
libraries is the way to go. XSP addresses that. But Cocoon appears yet to
directly address the problem of implementing tag libraries *in XSLT*.
Perhaps metastylesheets is the way to go. Or perhaps the document()
function is the way to go, and the caching problems just need to get
addressed. Or perhaps there is another approach that I haven't considered.
In any case, this needs to be addressed, IMHO. It's also quite possible that
this has been fully addressed and I just haven't seen it. In that case, I
would appreciate a link to that discussion :-)
Evan
-Original Message-
From: Luca Morandini [mailto:spectrum.morandini;ipzs.it]
Sent: Tuesday, November 12, 2002 5:35 AM
To: [EMAIL PROTECTED]
Subject: R: Separation of concerns?
Lorenzo,
to ease the burden on your graphic designers, you could even build a sort
of
taglib with XML elements to be expanded by an appropriate XSL.
I've done a lib which allows me to specify smart HTML without the need
of
XSL (well, it works behind the scenes)... here's an example:
img src={insert-request-parameter:images-home}/blank.gif border=0
width=4/
I hope you got the idea :)
Best regards,
Luca Morandini
[EMAIL PROTECTED]
-Messaggio originale-
Da: Lorenzo De Sio [mailto:l.desio;w4b.it]
Inviato: martedì 12 novembre 2002 12.35
A: '[EMAIL PROTECTED]'
Oggetto: R: Separation of concerns?
I think you pointed out quite a big issue, though from my point
of view this
is not such a problematic one.
I currently work in a co-founded small company. We are 1 programmer, 1
HTML/graphic designer, 1 HTML/Flash developer, 1 junior developer
which has
no actual programming skills, but quickly learned HTML and XSL.
You could ask: why Cocoon in such a small team? The answer is XSL
itself.
Currently, our application development work in the past few years (we
are
focused on small-medium businesses) has been mainly on e-commerce,
data-driven, customer-updatable sites and, later, content management for
small-to-medium publishing needs.
We ended up in producing many, many times the same mini-applications,
branding them differently each time. This led us (even on the ASP
platform
we were, and still mainly are, working on) to XSL. ASP already
(no .NET) has
a few underlooked features (XML serialization of a Recordset object to a
Stream object, for example, which is quite fast and can support XSL
transformation) which allowed us to separate the presentation
layer from the
content/logic one. This actually allowed me to totally drop the
production
of such applications to the junior programmer. He also benefits from the
separation, by actually reusing 99% of the code (we embedded
database write
logic in a single library .asp file, the only required code changes
are
for changing SELECT queries), and by being able to personalize the look
by
only changing one XSL template file.
This simple implementation of a XML/XSL separation, much simpler
but similar
to Cocoon's approach, already gave us these benefits.
The next step, which we are experiencing in the development of
quite a large
e-learning site (with Cocoon), is to directly let the designers access
the
XSLs, by giving them the basic XSL skills required to do the job.
I find that The XSL skills required are not really heavy. Heavy XSL
skills
are, in my opinion, required in working on complex structure
transformations
that come *before* the final, presentation-aimed XSL transformation. Our
experience is that, instead, the final transformation deals 99%
of the time
with: a) a container with many rows of data (a master, which can be
easily
handled even with a simple xsl:for-each/; b) an item of data with many
fiels (a detail). Such XSL-drive HTML renderings are done mostly using
xsl:value-of/ inserted into traditional HTML markup and I found
that even
the HTML designer and
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]
Serializer for d-o-e?
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. Any related information or help would be appreciated. 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]
RE: Serializer for d-o-e?
J.Pietschmann wrote: The answer is quite simple: you can't. D-o-e only works if the XSLT processor serializes the result itself, Please re-read my message a little more carefully. It's easy to dismiss it as a top-10 XSLT FAQ, but it isn't. 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. Actually it can be if I just pass that information on as a special attribute (or element or processing instruction). Note that I'm not interested in using xsl:disable-output-escaping. I already understand that I can't and that there are very good reasons why I can't. An example is in order. Here is what I would like to do: xsl:template match=html-blob html-blob my:disable-output-escaping=yes xsl:value-of select=./ /html-blob /xsl:template Then I would like a custom serializer to simply check every element (or perhaps only certain elements) for the presence of the attribute in my namespace called my:disable-output-escaping. When its value is yes, then output the content of that element without escaping markup characters. This is a general problem that comes up often enough in the real world that I thought someone might have already implemented such a feature. I recall that the Xalan serializer had some kind of PI-based hack for attaining the same. As it happens, I've already solved my problem at hand by using the Google Appliance's internal XSLT processor (which supports xsl:disable-output-escaping) to generate custom HTML, and then using the HTMLGenerator to load the Google results into Cocoon. Not exactly Web services, but it's at least nice to isolate the hack on the Google side. It may break in rare cases, but at least my site will still only be serving well-formed XHTML :-) Evan -Original Message- From: J.Pietschmann [mailto:j3322ptm;yahoo.de] Sent: Friday, November 08, 2002 10:58 AM To: [EMAIL PROTECTED] Subject: Re: Serializer for d-o-e? 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. One work around would be to do the opposite: emulate serializing in XSLT and use a text serializer, with some magic so that the client gets a content-type=text/html. J.Pietschmann - 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?
Hi Geoff, I had user edited real world html coming out of a database that would definitely have been invalid xml. My first pipeline serialized that result to xml and specified those elements as CDATA sections (configuration param in sitemap). From then on, the bad html was unparsed down the pipeline, but was successfully output at the end by the html serializer as is. This sounds like a bug in the HTML serializer rather than a feature... But I'm confused: Are CDATA sections among the types of SAX events that Cocoon passes through its pipelines? They aren't preserved in the XSLT/XPath data model; where are they preserved? Are you saying that the HTMLSerializer looks at a CDATA section event and serializes the value thereof unescaped? If that's the case, then it's broken. Otherwise, I think I must be missing a step in what you did. If your aim was to actually clean up the output, could you use jTidy to clean up the results? I ended up using the HTMLGenerator (which I assume uses JTidy), but only after using xsl:disable-output-escaping with the Google server's internal XSLT processor. So I think my problem is solved. My original plan had been to take Google's raw XML results and pass them through Cocoon's pipelines, but that was unfeasible because of the isolated bits of escaped, non-well-formed HTML that appear in different elements in the Google XML results. In that case, I could have tried to apply JTidy (to each isolated bit of HTML?), but I'm not sure how I could manage that in the sitemap (multiple extractions from the same source and then aggregating all the results again?), and in any case would be horribly inefficient even if I were to figure out a way to do it. Anyway, as I said, my current problem is solved. But I am still interested in the possibility of a custom HTML serializer that will recognize a special flag to disable output escaping. I just don't need it right away :-) Thanks for the input. Evan Geoff --- Lenz, Evan [EMAIL PROTECTED] wrote: J.Pietschmann wrote: The answer is quite simple: you can't. D-o-e only works if the XSLT processor serializes the result itself, Please re-read my message a little more carefully. It's easy to dismiss it as a top-10 XSLT FAQ, but it isn't. 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. Actually it can be if I just pass that information on as a special attribute (or element or processing instruction). Note that I'm not interested in using xsl:disable-output-escaping. I already understand that I can't and that there are very good reasons why I can't. An example is in order. Here is what I would like to do: xsl:template match=html-blob html-blob my:disable-output-escaping=yes xsl:value-of select=./ /html-blob /xsl:template Then I would like a custom serializer to simply check every element (or perhaps only certain elements) for the presence of the attribute in my namespace called my:disable-output-escaping. When its value is yes, then output the content of that element without escaping markup characters. This is a general problem that comes up often enough in the real world that I thought someone might have already implemented such a feature. I recall that the Xalan serializer had some kind of PI-based hack for attaining the same. As it happens, I've already solved my problem at hand by using the Google Appliance's internal XSLT processor (which supports xsl:disable-output-escaping) to generate custom HTML, and then using the HTMLGenerator to load the Google results into Cocoon. Not exactly Web services, but it's at least nice to isolate the hack on the Google side. It may break in rare cases, but at least my site will still only be serving well-formed XHTML :-) Evan -Original Message- From: J.Pietschmann [mailto:j3322ptm;yahoo.de] Sent: Friday, November 08, 2002 10:58 AM To: [EMAIL PROTECTED] Subject: Re: Serializer for d-o-e? 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
Serializing JavaScript
I have an XSLT transformation that outputs a JavaScript file that I need to serialize as text to send to the client. I am using map:serialize type=text/, but the serialized result includes an XML declaration with markup characters escaped (as if serializing an external parsed general entity). How do I force Cocoon to serialize JavaScript the way it should be serialized, not to mention with the right media type? Any help would be much appreciated, Evan Lenz Seattle University School of Law Technology Department - 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]
ProxyPass vs. mod_jk
I intend to use Apache in conjunction with Cocoon. What are the advantages of using mod_jk as opposed to just ProxyPass? I'm probably missing some obvious things. What are they? 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]
General questions about caching in Cocoon
Does Cocoon provide a mechanism by which all pages on the site can be cached (perhaps via a crawler)? I'm aware of the command-line interface (and had trouble getting the crawler to get past the first page, but that's another story). Ultimately, I would like to use Cocoon as a servlet but have as many pages cached as possible at the click of a button, as opposed to waiting for each page to be requested. I suppose this could be done externally (with my own crawler) but I was wondering if Cocoon had some built-in mechanism for doing this. Also, I am building a site that has three versions per page (Flash, non-Flash, etc.) and that uses cookies to set a user's preference. All of my cookie logic is specified in sitemap.xmap, so I am already committed to using Cocoon as a servlet. Are there caching issues with such an approach? If performance ultimately becomes a problem, I suppose I could statically generate most of the pages and just use readers for each version of each page, but that wouldn't be ideal, as certain portions of the site are indeed dynamic. Finally, if anyone has any words of wisdom with respect to using Cocoon for serving multiple versions of a page (from the same URL), I'd be happy to hear them. 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]
HTMLGenerator not working with Command-line interface
I'm trying to use the Cocoon CLI along with the HTMLGenerator to convert existing HTML content into well-formed XML en mass. (I have a fairly recent checkout from CVS.) I've begun with the docs target in build.xml as a starting point, creating a new target with incremental modifications. When I use the default (File) generator, everything works fine (as long as the source is well-formed XML to begin with). But when I use the HTMLGenerator, Ant returns successfully but reports my starting URL as a broken link and creates a Resource Not Found HTML page in the destination directory. This appears to be a CLI-specific problem (at least from my perspective), because when I drop the application into a servlet container, the HTMLGenerator works just fine, serving up the page as I expect. Does anyone have any idea why this wouldn't work? Any help would be greatly appreciated. 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]
