Re: AW: Custom Transformers
Round II:
Here's my transformer code, (I know there's extra imports I don't need just yet):
-
package com.openweather.cocoon.transformation;
import org.apache.cocoon.transformation.AbstractSAXTransformer;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.cocoon.ProcessingException;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.framework.logger.Logger;
import org.xml.sax.SAXException;
import org.xml.sax.Attributes;
import java.util.Map;
import java.io.IOException;
public class CAPDescriptionTransformer
extends AbstractSAXTransformer {
protected String NAMESPACE = "http://www.incident.com/cap/1.0";;
protected String DESCRIPTION = "description";
private String text = null;
public void startElement(String uri, String name, String raw, Attributes attr)
throws SAXException {
super.startElement(uri, name, raw, attr);
if ( NAMESPACE.equals(uri) && DESCRIPTION.equals(name) ) {
this.text = null;
startTextRecording();
}
}
public void endElement(String uri, String name, String raw, Attributes attr)
throws SAXException {
if ( NAMESPACE.equals(uri) && DESCRIPTION.equals(name) ) {
// we found the element
// get the text and process
this.text = endTextRecording();
// send the processed characters to the next pipeline component
characters( process(this.text).toCharArray(), 0, text.length() );
}
// end the element
super.endElement(uri, name, raw);
}
private String process(String text) {
System.out.println("inside process()");
// @TODO: finish me
// arbitrarily process the text
System.out.println("leaving process before return():");
return text.toLowerCase();
}
}
--
package com.openweather.cocoon.transformation;
import org.apache.cocoon.transformation.AbstractSAXTransformer;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.cocoon.ProcessingException;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.avalon.framework.logger.Logger;
import org.xml.sax.SAXException;
import org.xml.sax.Attributes;
import java.util.Map;
import java.io.IOException;
public class CAPDescriptionTransformer
extends AbstractSAXTransformer {
protected String NAMESPACE = "http://www.incident.com/cap/1.0";;
protected String DESCRIPTION = "description";
private String text = null;
public void startElement(String uri, String name, String raw, Attributes attr)
throws SAXException {
super.startElement(uri, name, raw, attr);
if ( NAMESPACE.equals(uri) && DESCRIPTION.equals(name) ) {
this.text = null;
startTextRecording();
}
}
public void endElement(String uri, String name, String raw, Attributes attr)
throws SAXException {
if ( NAMESPACE.equals(uri) && DESCRIPTION.equals(name) ) {
// we found the element
// get the text and process
this.text = endTextRecording();
// send the processed characters to the next pipeline component
characters( process(this.text).toCharArray(), 0, text.length() );
}
// end the element
super.endElement(uri, name, raw);
}
private String process(String text) {
System.out.println("inside process()");
// @TODO: finish me
// arbitrarily process the text
System.out.println("leaving process before return():");
return text.toLowerCase();
}
}
By using the LogTransformer before and after my transformer, it seems that once
startRecording() is called, no events are sent to my tranformer. I would assume
that calling endRecording() would turn that off, but that doesn't seem to be the
case. Can anyone tell me where I'm going wrong? I notices the
SourceWritingTransformer keeps a stack... am I going to have to keep track of
the elements I see once I've started recording?
Regards,
Tony
[VOTE] Deprecate JISP support
Hi: JCS is a reality in Cocoon thanks to Carsten and the JCS team that was quick responsive and very helpful. Before we used JISP. Now we can deprecate JISP support and if someone need it too much there is always a path to use it through JCS. The proposal is: Deprecated JISP support in 2.1.5 and remove it in the next version? [ ] Best Regards, Antonio Gallardo
Re: Wiki conversion status
Sorry not be more explicit first time, and, yes I can: http://wiki.apache.org/cocoon/MIDI see: ==Sample Xmidi== http://wiki.apache.org/cocoon/Action see: === Built-in Actions === Cheers, Mark On 20 May 2004, at 20:08, Upayavira wrote: Mark Leicester wrote: Hi Upayavira, Keep up the great work! I had a little look around and noticed that 2nd and 3rd level headings don't appear to convert correctly. Can you give an example? Regards, Upayavira
Re: Wiki conversion status
Mark Leicester wrote: Hi Upayavira, Keep up the great work! I had a little look around and noticed that 2nd and 3rd level headings don't appear to convert correctly. Can you give an example? Regards, Upayavira
Re: Wiki conversion status
Hi Upayavira, Keep up the great work! I had a little look around and noticed that 2nd and 3rd level headings don't appear to convert correctly. Mark On 20 May 2004, at 17:17, David Crossley wrote: Upayavira wrote: Well, I must be a regexp whizz, because I got this working within five minutes. I was distracted by the fact that it didn't work on my local Moin, but it works on Apache's so it is fine. Nice. Thanks for persisting. --David
Re: Wiki conversion status
Upayavira wrote: > > > Well, I must be a regexp whizz, because I got this working within five > minutes. I was distracted by the fact that it didn't work on my local > Moin, but it works on Apache's so it is fine. Nice. Thanks for persisting. --David
Re: Wiki conversion status
David Crossley wrote: But it is odd how it works. JXTemplateGenerator will only see TemplateGenerator as the link without the JX. It is going to be tough just using this, as even when we've done the conversion people are going to be inadvertently adding CamelCase to their new Wiki pages. I guess I can give my regexp skills another test to see if I can come up with a CamelCase detector, but I'm a little reluctant. Is it really important? Yes, i think so, for the reasons described above. Upayavira, who's trying to avoid a bit more work! Thanks, and we do not want to hold you up in any way. Is this something that can be switched off by default and we switch it on if we decide that we want it? Well, I must be a regexp whizz, because I got this working within five minutes. I was distracted by the fact that it didn't work on my local Moin, but it works on Apache's so it is fine. I have uploaded a current conversion. I coded it so as to exclude Lenya content, which can be put onto a separate wiki (about which they are currently voting). Please review. If no comments, I'll start a conversion vote in a couple of days. Upayavira
RE: [VOTE] Release on monday
Antonio Gallardo wrote: > > I hope we soon will get rid of jisp. What about to deprecate > current JISP support? If someone want to use JISP there is > still a posibility using JCS. > +1 Carsten
Re: [VOTE] Release on monday
Upayavira wrote: It is there somewhat more akin to an anteater test. Therefore, given these facts, I propose to leave the CocoonBeanTestCase disabled, and simply remove the test suite (as it isn't needed anyway.). I will continue to use the test case locally on my own testing, and will reflect on a better place for it (or some equivalent) within the build process, perhaps alongside the anteater tests. +1. I am also worried about the time it takes to run the CocoonBeanTestCase. We already run the unit tests all too seldom, and if they take a long time, nobody will ever want to run them more often. Ugo
Re: [VOTE] Release on monday
Ugo Cei wrote: Upayavira wrote: I need to remove the test-suite and use samples/test, and confirm that Ugo's fixes have made the CocoonBeanTestCase work, and then re-enable it. A word of caution. My fixes add the blocks directory and block-provided jars to the classpath for tests and make the "junit-tests" target depend upon the "blocks" target. This is necessary because the CocoonBeanTestCase loads "build/webapp/WEB-INF/cocoon.xconf", which contains references to components provided by blocks. This strikes me as a typical anti-pattern. What are we testing here? The CocoonBean or the components that it relies upon? If it's the latter, fine, but it's not a unit test anymore, it's an integration test and does not belong under the "junit-tests" target. If it's the former, it should be testable in isolation. In any case, it would be probably advisable to load the CocoonBean under test with a cocoon.xconf derived from a "no-blocks-included" configuration. This is all fair comment. Whilst I have a 'unit test' for the bean, in fact, the bean really depends upon the entirety of Cocoon, and is thus really more of a functional test. Given that some blocks have been known to break the bean, it is important that the test is run across the entire Cocoon. It is there somewhat more akin to an anteater test. Therefore, given these facts, I propose to leave the CocoonBeanTestCase disabled, and simply remove the test suite (as it isn't needed anyway.). I will continue to use the test case locally on my own testing, and will reflect on a better place for it (or some equivalent) within the build process, perhaps alongside the anteater tests. Upayavira
