Helma Isn't the problem though, that the htmlAtrea strings cannot be post-processed in another stylesheet - one that outputs XML and not HTML?
Derek >>> [EMAIL PROTECTED] 2004/11/23 04:09:08 PM >>> Derek, I'm currently working on updating the HTMLarea sample to 1. work in tables in IE6 2. use Bruno's HtmlCleanerConvertor 3. output html-ized data, rather than raw (i.e. as string) for 3. I currently use a simple XSL stylesheet that matches <htmlarea> tags and displays them with disable-output-escaping="yes". If anyone can come up with a better solution or modifies Ugo's HTMLparser, please do so. For now Reinhard is looking things over. Bye, Helma > -----Original Message----- > From: Derek Hohls [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 23 November, 2004 14:39 > To: [EMAIL PROTECTED] > Subject: Re: Using htmlArea 'output' with SVG > > > Ugo > > Well, all this may be clear to you... but not to me :{ > Where I am trying to get to is not to deal with single > "bits" of htmlArea text, but with an entire file created > using a Cform. Are you proposing that each field containing > htmlArea text must be "intercepted" and processed before > the form data is stored? Or is when you read it back? > I am not sure why you have created the "dom" variable > in your script below, or what you would do with it. > > There are likely to be a number of users, all creating and > drawing data from different files via CForms; is this likely > to be a problem? > > Derek > > >>> [EMAIL PROTECTED] 2004/11/23 03:10:59 PM >>> > Il giorno 23/nov/04, alle 13:11, Derek Hohls ha scritto: > > > OK - so what needs to be done to integrate this into a > > Cocoon application? I assume this is a page generator > > of some sort (or is a new transformer?), but I have not customized > > Cocoon in this way before. Pointers to next steps would be > > welcome...! > > This is just a plain, old Java object with a single public static > method. I don't know why you always manage to make things harder than > they are ;-) > > You can call it from flowscript like this: > > var dom = HTMLParser.parse(form.lookupWidget("/field").value; > > Of course, being a simple Java class, you can call it from > Java code as > > well. > > The only problem it has, AFAIK, is that it defines a single static > instance of an XML parser, which is not threadsafe, so the only method > > that uses it is synchronized. This is not going to scale, of course, > but it is not a problem unless you need to concurrently process a lot > of HTML strings. And it has an explicit dependency on Xerces > instead of > > using JAXP. As far as I can remember, I had some problems > with JAXP and > > Neko, so I made it like that, but I can't remember the details at the > moment. > > Ugo > > -- > Ugo Cei - http://beblogging.com/ > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > MailScanner thanks transtec Computers for their support. > > > --------------------------------------------------------------------- > 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] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
