Re: Handling configuration files during cocoon update
Sorry if I misunderstood - the previous post suggested that it was good practice to integrate your changes as part of the build process, rather than making them manually - and directly - to the files after building Cocoon. I was not talking about the use case for a *single* project, but the case for multiple projects, all as part of one Cocoon deployment, that now needed to be upgraded - not as a result of project changes but because of wanting to a use a newer version of Cocoon. [EMAIL PROTECTED] 2005/11/28 08:53:47 AM You only need to rebuild Cocoon if you have integrated your product into its build. If you use the process described at http://wiki.apache.org/cocoon/HowToBuildAndDeployCocoonWithMaven?highlight=%28maven%29 then you only need to rebuild Cocoon when you want to upgrade it. To integrate changes to your project you must rebuild and redploy your project. Ralph Derek Hohls wrote: Does this imply that if you have incremental changes to these files (more projects being added to an *existing* Cocoon installations) over time, that you should be rebuilding and redeploying Cocoon each time? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [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]
Re: Handling configuration files during cocoon update
Derek Hohls wrote: Sorry if I misunderstood - the previous post suggested that it was good practice to integrate your changes as part of the build process, rather than making them manually - and directly - to the files after building Cocoon. There are two schools of thought. Some folks like to create their project as a block and then get cocoon's build process to build it. I find that tedious when migrating from one Cocoon release to the next. However, even the process I suggested does not have any manual changes. I was not talking about the use case for a *single* project, but the case for multiple projects, all as part of one Cocoon deployment, that now needed to be upgraded - not as a result of project changes but because of wanting to a use a newer version of Cocoon. We handle that by doing that only as part of a product upgrade. Then it is just a matter of changing the Cocoon dependency and making any adjustments required due to release changes. If you integrate your build into Cocoon's then IMO upgrading Cocoon becomes a lot more painful. However, I want to emphasize that this does not necessarily apply to the upcoming 2.2 releases. As I understand things, in 2.2 your project will become one or more blocks (maven projects) which will include Cocoon blocks and/or the core as dependencies. In that case, you would have to create a new release of your project with changes to the Cocoon dependencies. You would then rebuild your project and redeploy. Ralph Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Initialize Session Context Info
I used flowscript to create sessions and it is very easy to add some initialization code to it as well.. OK, but does this mean that every request is going through your flowscript? Yes. I haven't analyzed the impact on performance, but seemed more than sufficient for not too heavy use.. Regards, Geert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[2.1.8] JBoss 4.0.3 SP1 Xalan/Xerces
Hi, cocoon 2.1.8 aggregation samples (flexible content, parallel content, cinclude content, xinclude content) end with an 500 status running them on JBoss 4.0.3 SP1. It seems to be a conflict between the xalan/xerces version of cocoon and jboss. JBoss is running in isolation mode. Cocoon was installed by simly copying the build directory and renaming it to cocoon.war. Any suggestions how to get the problem solved (copying jars ...)? Thanks Reinhard exception from cocoon: *** type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) root cause java.lang.IncompatibleClassChangeError org.apache.xalan.xsltc.compiler.UnionPathExpr.setParser(UnionPathExpr.java:75) org.apache.xalan.xsltc.compiler.Parser.parseTopLevel(Parser.java:1095) org.apache.xalan.xsltc.compiler.Parser.parseExpression(Parser.java:1053) org.apache.xalan.xsltc.compiler.ApplyTemplates.parseContents(ApplyTemplates.java:71) org.apache.xalan.xsltc.compiler.SyntaxTreeNode.parseChildren(SyntaxTreeNode.java:423) org.apache.xalan.xsltc.compiler.Copy.parseContents(Copy.java:58) org.apache.xalan.xsltc.compiler.SyntaxTreeNode.parseChildren(SyntaxTreeNode.java:423) org.apache.xalan.xsltc.compiler.Template.parseContents(Template.java:247) org.apache.xalan.xsltc.compiler.Stylesheet.parseOwnChildren(Stylesheet.java:585) org.apache.xalan.xsltc.compiler.Stylesheet.parseContents(Stylesheet.java:557) org.apache.xalan.xsltc.compiler.Parser.createAST(Parser.java:381) org.apache.xalan.xsltc.trax.TemplatesHandlerImpl.endDocument(TemplatesHandlerImpl.java:220) org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source) org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source) org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source) org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source) org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown Source) org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) org.apache.xerces.parsers.XMLParser.parse(Unknown Source) org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315) org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:128) org.apache.cocoon.components.xslt.TraxProcessor.sourceToSAX(TraxProcessor.java:300) org.apache.cocoon.components.xslt.TraxProcessor.getTransformerHandlerAndValidity(TraxProcessor.java:238) org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:330) org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:397) org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:619) org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:500) org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:452) org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120) org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248)
not closing empty tags with xhtml serializer
Hi Some Browsers don't like closed tags, like for instance iframe/ but they don't mind iframe /iframe The problem is that the xhtml serializer is closing empty tags. (I am aware that the html serializer would be a workaround, but I want to serialize the page as xhtml and not as html.) Is it possible to configure the xhtml serializer to leave them open? Somehow I have the feeling that this questions was asked before, but cannot find it anymore and if there is a solution or not. Any hint is appreciated Thanks Michi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: not closing empty tags with xhtml serializer
Michael Wechner wrote: Hi Some Browsers don't like closed tags, like for instance iframe/ but they don't mind iframe /iframe The problem is that the xhtml serializer is closing empty tags. (I am aware that the html serializer would be a workaround, but I want to serialize the page as xhtml and not as html.) Is it possible to configure the xhtml serializer to leave them open? Somehow I have the feeling that this questions was asked before, but cannot find it anymore and if there is a solution or not. Any hint is appreciated Have you tried the serializer in the serializer block? If that doesn't work, it might be easier to fix than the core cocoon one. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: not closing empty tags with xhtml serializer
On 11/28/05, Michael Wechner [EMAIL PROTECTED] wrote: Hi Some Browsers don't like closed tags, like for instance iframe/ but they don't mind iframe /iframe The problem is that the xhtml serializer is closing empty tags. (I am aware that the html serializer would be a workaround, but I want to serialize the page as xhtml and not as html.) Is it possible to configure the xhtml serializer to leave them open? Somehow I have the feeling that this questions was asked before, but cannot find it anymore and if there is a solution or not. Any hint is appreciated Thanks Michi http://marc.theaimsgroup.com/?t=10800175083r=1w=2 Not sure if it helps or not... --tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: not closing empty tags with xhtml serializer
Upayavira wrote:
Michael Wechner wrote:
Hi
Some Browsers don't like closed tags, like for instance
iframe/
but they don't mind
iframe /iframe
The problem is that the xhtml serializer is closing empty tags.
(I am aware that the html serializer would be a workaround, but I want
to serialize
the page as xhtml and not as html.)
Is it possible to configure the xhtml serializer to leave them open?
Somehow I have the feeling that this questions was asked before, but
cannot find it
anymore and if there is a solution or not.
Any hint is appreciated
Have you tried the serializer in the serializer block?
I guess that's the one which I am using:
src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
If that doesn't
work, it might be easier to fix than the core cocoon one.
you mean adding iframe to
if ((local.equalsIgnoreCase(textarea)) ||
(local.equalsIgnoreCase(script)) ||
(local.equalsIgnoreCase(style))) {
?
Thanks
Michi
Regards, Upayavira
-
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: not closing empty tags with xhtml serializer
Michael Wechner wrote:
Upayavira wrote:
Michael Wechner wrote:
Hi
Some Browsers don't like closed tags, like for instance
iframe/
but they don't mind
iframe /iframe
The problem is that the xhtml serializer is closing empty tags.
(I am aware that the html serializer would be a workaround, but I want
to serialize
the page as xhtml and not as html.)
Is it possible to configure the xhtml serializer to leave them open?
Somehow I have the feeling that this questions was asked before, but
cannot find it
anymore and if there is a solution or not.
Any hint is appreciated
Have you tried the serializer in the serializer block?
I guess that's the one which I am using:
src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
If that doesn't
work, it might be easier to fix than the core cocoon one.
you mean adding iframe to
if ((local.equalsIgnoreCase(textarea)) ||
(local.equalsIgnoreCase(script)) ||
(local.equalsIgnoreCase(style))) {
?
Yeah, that kinda thing!
If iframe is another one of those cases, then it makes sense to add it
to that list and commit it.
Regards, Upayavira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: not closing empty tags with xhtml serializer
Upayavira wrote:
Michael Wechner wrote:
Upayavira wrote:
Michael Wechner wrote:
Hi
Some Browsers don't like closed tags, like for instance
iframe/
but they don't mind
iframe /iframe
The problem is that the xhtml serializer is closing empty tags.
(I am aware that the html serializer would be a workaround, but I want
to serialize
the page as xhtml and not as html.)
Is it possible to configure the xhtml serializer to leave them open?
Somehow I have the feeling that this questions was asked before, but
cannot find it
anymore and if there is a solution or not.
Any hint is appreciated
Have you tried the serializer in the serializer block?
I guess that's the one which I am using:
src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
If that doesn't
work, it might be easier to fix than the core cocoon one.
you mean adding iframe to
if ((local.equalsIgnoreCase(textarea)) ||
(local.equalsIgnoreCase(script)) ||
(local.equalsIgnoreCase(style))) {
?
Yeah, that kinda thing!
If iframe is another one of those cases, then it makes sense to add it
to that list and commit it.
ok, will do so. Whereas I think it would make sense to make this list
configurable within
the map:components declaration. On the other hand the list is not
endless ;-) WDYT?
Thanks
Michi
Regards, Upayavira
-
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: not closing empty tags with xhtml serializer
Tim Williams wrote: On 11/28/05, Michael Wechner [EMAIL PROTECTED] wrote: Hi Some Browsers don't like closed tags, like for instance iframe/ but they don't mind iframe /iframe The problem is that the xhtml serializer is closing empty tags. (I am aware that the html serializer would be a workaround, but I want to serialize the page as xhtml and not as html.) Is it possible to configure the xhtml serializer to leave them open? Somehow I have the feeling that this questions was asked before, but cannot find it anymore and if there is a solution or not. Any hint is appreciated Thanks Michi http://marc.theaimsgroup.com/?t=10800175083r=1w=2 Not sure if it helps or not... thanks for the hint Michi --tim - 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: not closing empty tags with xhtml serializer
Michael Wechner wrote:
Upayavira wrote:
Michael Wechner wrote:
Upayavira wrote:
Michael Wechner wrote:
Hi
Some Browsers don't like closed tags, like for instance
iframe/
but they don't mind
iframe /iframe
The problem is that the xhtml serializer is closing empty tags.
(I am aware that the html serializer would be a workaround, but I
want
to serialize
the page as xhtml and not as html.)
Is it possible to configure the xhtml serializer to leave them open?
Somehow I have the feeling that this questions was asked before, but
cannot find it
anymore and if there is a solution or not.
Any hint is appreciated
Have you tried the serializer in the serializer block?
I guess that's the one which I am using:
src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
If that doesn't
work, it might be easier to fix than the core cocoon one.
you mean adding iframe to
if ((local.equalsIgnoreCase(textarea)) ||
(local.equalsIgnoreCase(script)) ||
(local.equalsIgnoreCase(style))) {
?
Yeah, that kinda thing!
If iframe is another one of those cases, then it makes sense to add it
to that list and commit it.
ok, will do so. Whereas I think it would make sense to make this list
configurable within
the map:components declaration. On the other hand the list is not
endless ;-) WDYT?
Since the list is not endless, then does not make sense to make it
configurable. Better, please do a small research of all the tags that
have the same behavior. WDYT?
BTW, This is a old good know bug. It had been around for more than a
year. I wonder why this is not just switch the default serializer.
Best Regards,
Antonio Gallardo.
-
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: Generating XSD documentation in Cocoon
XSLT from http://titanium.dstc.edu.au/xml/xs3p/ looks like it should do the trick. Thanks to the Vancouver XML users group for this link. From: Combinational Logic [mailto:[EMAIL PROTECTED] Sent: Sunday, November 27, 2005 3:17 PM To: users@cocoon.apache.org Subject: Generating XSD documentation in Cocoon Given a set of XSD files, is there any Cocoon source available (likely XSLT) that enables navigation of the XSD using a high-level hyperlinked view. Im looking for something similar to the schema documentation generated by XML-Spy. Thanks, CL
Maintain the state of visited links
Hi all, I have got the following problem: I have two sets of links the first one is a table of contents links and the second one is a personalisation links which leads to a form to change the font size, background colours etc. When I click one of the table of contents links, the colour of this visited link is turned from blue into red which is what I want. The problem now is when I click one of the personalisation links to change, for example, the font size, the table of contents' links will not maintain their state and their colour will be as if they have not been visited yet. I am transferring the parameters through the urls to be sent to the server for processing and then returning the results to the screen. Is there an easy way to main the state of the visited links even when there is a change occurred in the parameters transferred within the url to the server? Many thanks, Fadi __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CForms] Calendar i18n translation
Hello,
I did it (for cocoon 2.1.5).
I had to change forms-calendar-styling.xsl to call the i18n methods of
the calendar. Here's how it looks:
xsl:template match=head mode=forms-calendar
script src={$resources-uri}/mattkruse-lib/CalendarPopup.js
type=text/javascript/
script src={$resources-uri}/mattkruse-lib/date.js
type=text/javascript/
script type=text/javascript
// Setup calendar
var forms_calendar = CalendarPopup('forms_calendarDiv');
// forms_calendar.setWeekStartDay(1);
// forms_calendar.showYearNavigation();
// forms_calendar.showYearNavigationInput();
forms_calendar.setCssPrefix(forms_);
forms_calendar.setMonthNames('i18n:text
catalogue=caljanuary/i18n:text','i18n:text
catalogue=calfebruary/i18n:text','i18n:text
catalogue=calmarch/i18n:text','i18n:text
catalogue=calapril/i18n:text','i18n:text
catalogue=calmay/i18n:text','i18n:text
catalogue=caljune/i18n:text','i18n:text
catalogue=caljuly/i18n:text','i18n:text
catalogue=calaugust/i18n:text','i18n:text
catalogue=calseptember/i18n:text','i18n:text
catalogue=caloctober/i18n:text','i18n:text
catalogue=calnovember/i18n:text','i18n:text
catalogue=caldecember/i18n:text');
forms_calendar.setDayHeaders(i18n:text
catalogue=caldayHeaders/i18n:text);
forms_calendar.setWeekStartDay(i18n:text
catalogue=calweekStartDay/i18n:text);
forms_calendar.setTodayText(i18n:text
catalogue=caltoday/i18n:text);
forms_calendar.showNavigationDropdowns();
/script
link rel=stylesheet type=text/css
href={$resources-uri}/forms-calendar.css/
/xsl:template
The english dictionary looks like this:
?xml version=1.0 encoding=ISO-8859-1?
catalogue xml:lang=en
message key=januaryjanuary/message
message key=februaryfebruary/message
message key=marchmarch/message
message key=aprilapril/message
message key=maymay/message
message key=junejune/message
message key=julyjuly/message
message key=augustaugust/message
message key=septemberseptember/message
message key=octoberoctober/message
message key=novembernovember/message
message key=decemberdecember/message
message key=todaytoday/message
message key=dayHeaders'S','M','T','W','T','F','S'/message
message key=weekStartDay0/message
/catalogue
2005/11/23, Josep A. Frau [EMAIL PROTECTED]:
How can I translate the text in the popup calendar rended by
forms-calendar-styling.xsl?
I want to translate with the i18n transformer the text of today,
weekdays and month names.
Someone have make this translations?
--
Josep A. Frau [EMAIL PROTECTED]
Centre de Tecnologies de la Informació
Universitat de les Illes Balears
-
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: Maintain the state of visited links
Fadi Qutaishat wrote: Hi all, I have got the following problem: I have two sets of links the first one is a table of contents links and the second one is a personalisation links which leads to a form to change the font size, background colours etc. When I click one of the table of contents links, the colour of this visited link is turned from blue into red which is what I want. The problem now is when I click one of the personalisation links to change, for example, the font size, the table of contents' links will not maintain their state and their colour will be as if they have not been visited yet. I am transferring the parameters through the urls to be sent to the server for processing and then returning the results to the screen. Is there an easy way to main the state of the visited links even when there is a change occurred in the parameters transferred within the url to the server? That is the behaviour of your browser. And your browser will compare the full URL to see if it has been visited before. I guess you could work around this by having forms the page and using POST to pass the data to the pages, thus you keep the same URL even with different data. That's how I'd look into getting it to work. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Portal : Disabling the fullscreen-buttons on portlets
Hi How and where do I specify that some of my coplets don't want that fullscreen buttons ? I have tried putting this on copletdata and copletinstancedata xml-files, but it didn't help. aspect namefull-screen/name value xsi:type=java:java.lang.Boolean xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;false/value /aspect Any examples, any documentations Anything is appreciated. Regards, Armaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portal : Disabling the fullscreen-buttons on portlets
First, if you don't include the full-screen aspect then none of your portlets will have fullscreen events. Second, you can add parameters to the layout for the specific portlets. You can then modify the appropriate xslt's to generate or not generate the full-screen buttons based upon the absence, presence or value of the parameters. Ralph Armaz Mellati wrote: Hi How and where do I specify that some of my coplets don't want that fullscreen buttons ? I have tried putting this on copletdata and copletinstancedata xml-files, but it didn't help. aspect namefull-screen/name value xsi:type=java:java.lang.Boolean xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;false/value /aspect Any examples, any documentations Anything is appreciated. Regards, Armaz - 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: not closing empty tags with xhtml serializer
Antonio Gallardo wrote: BTW, This is a old good know bug. It had been around for more than a year. I wonder why this is not just switch the default serializer. what do you mean? btw, I have added the iframe tag to the list of the XHTML serializer of 2.1.X. I guess this also needs to be done for the trunk, right? Thanks Michi Best Regards, Antonio Gallardo. - 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] -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: not closing empty tags with xhtml serializer
Michael Wechner wrote: Antonio Gallardo wrote: BTW, This is a old good know bug. It had been around for more than a year. I wonder why this is not just switch the default serializer. what do you mean? btw, I have added the iframe tag to the list of the XHTML serializer of 2.1.X. I guess this also needs to be done for the trunk, right? yes, please do. Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: not closing empty tags with xhtml serializer
Michael Wechner wrote: Antonio Gallardo wrote: BTW, This is a old good know bug. It had been around for more than a year. I wonder why this is not just switch the default serializer. what do you mean? I mean: let's make the newer serializer the default serializer. The current default serializer seems to be broken for long time. If this assertion is not true, then this thread was unnecesary, right? ;-). btw, I have added the iframe tag to the list of the XHTML serializer of 2.1.X. I guess this also needs to be done for the trunk, right? Yep. Please commit to the trunk too. Thanks to you. Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
