Cocoon
  1. Cocoon
  2. COCOON-1928

Add the ability to pass the doctype in parameter for Serializer

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: * Cocoon Core
    • Labels:
      None
    • Other Info:
      Patch available

      Description

      I need - with forrest - to get the doctype-system and doctype-public in a parameter like following :
      <map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html" name="xhtml" pool-grow="2" pool-max="64" pool-min="2"
              src="org.apache.cocoon.serialization.XMLSerializer">
              <parameter name="doctype-public" value="-//W3C//DTD XHTML 1.0 Transitional//EN" />
              <parameter name="doctype-system" value="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" />
              <encoding>UTF-8</encoding>
              <indent>yes</indent>
      <omit-xml-declaration>no</omit-xml-declaration>
      </map:serializer>

      here is a patch which apply to the AbstractTextSerializer.
      in case the doctype is also found in the childs, child have priority.

      Regards,

        Activity

        Hide
        David Crossley added a comment -
        Please see FOR-1071 where we enabled such configuration using xml entities in the main forrest sitemap.
        Show
        David Crossley added a comment - Please see FOR-1071 where we enabled such configuration using xml entities in the main forrest sitemap.
        Hide
        Jörg Heinicke added a comment -
        > Cyriaque, have you tried declaring the serializer in your project's sitemap.xmap file? I am not sure which one takes precedence.

        > Sitemap precedence would probably be better, if possible.

        I don't know how a Forrest plugin works, but in standard Cocoon sitemaps work as sub-containers and redeclared components are only usable in this sitemap and its childs (if not redeclared again).

        So if the plugin's sitemap is actually a super-sitemap (or part of it) of the project's sitemap and if it also contains the pipeline where this component is used, it will use the original component, not the redeclared one.

        > Probably should create a FOR Jira issue and leave this one for your original suggestion.

        I don't think that this proposal will make it into Cocoon. You can ask on the developers list, but I guess this one will get a WONTFIX (to speak in bugzilla resolvings).
        Show
        Jörg Heinicke added a comment - > Cyriaque, have you tried declaring the serializer in your project's sitemap.xmap file? I am not sure which one takes precedence. > Sitemap precedence would probably be better, if possible. I don't know how a Forrest plugin works, but in standard Cocoon sitemaps work as sub-containers and redeclared components are only usable in this sitemap and its childs (if not redeclared again). So if the plugin's sitemap is actually a super-sitemap (or part of it) of the project's sitemap and if it also contains the pipeline where this component is used, it will use the original component, not the redeclared one. > Probably should create a FOR Jira issue and leave this one for your original suggestion. I don't think that this proposal will make it into Cocoon. You can ask on the developers list, but I guess this one will get a WONTFIX (to speak in bugzilla resolvings).
        Hide
        David Crossley added a comment -
        Sitemap precedence would probably be better, if possible.

        Another technique that i wonder about: Let the project or plugin declare a separate map:serializer with different "name" attribute. Then make the name be configurable for deciding which serializer to use later in the map:pipelines. I gather that the Cocoon properties system will enable such configuration (FOR-917).

        The entities technique should work (being an xml framework). The biggest trouble that i have found is getting the entity resolver to work in all three situations: local jetty, command-line CLI, and webapp war. Forrest entity resolver is able to be used at core, plugin, and project levels. Here is one technique that might help you: http://forrest.apache.org/docs/dev/faq.html#xml-entities

        Probably should create a FOR Jira issue and leave this one for your original suggestion.
        Show
        David Crossley added a comment - Sitemap precedence would probably be better, if possible. Another technique that i wonder about: Let the project or plugin declare a separate map:serializer with different "name" attribute. Then make the name be configurable for deciding which serializer to use later in the map:pipelines. I gather that the Cocoon properties system will enable such configuration ( FOR-917 ). The entities technique should work (being an xml framework). The biggest trouble that i have found is getting the entity resolver to work in all three situations: local jetty, command-line CLI, and webapp war. Forrest entity resolver is able to be used at core, plugin, and project levels. Here is one technique that might help you: http://forrest.apache.org/docs/dev/faq.html#xml-entities Probably should create a FOR Jira issue and leave this one for your original suggestion.
        Hide
        Cyriaque Dupoirieux added a comment -
        David, I am going to try the solution of Jörg with entities. I think it can be the solution and it's really pretty nice.
        When my test is good, I will close the problem.
        Show
        Cyriaque Dupoirieux added a comment - David, I am going to try the solution of Jörg with entities. I think it can be the solution and it's really pretty nice. When my test is good, I will close the problem.
        Hide
        David Crossley added a comment -
        Cyriaque, have you tried declaring the serializer in your project's sitemap.xmap file? I am not sure which one takes precedence.
        Show
        David Crossley added a comment - Cyriaque, have you tried declaring the serializer in your project's sitemap.xmap file? I am not sure which one takes precedence.
        Hide
        Jörg Heinicke added a comment -
        > Doctype is configurable right now, see Cocoon samples

        Of course it is. But I wondered why he wants to make even the configuration configurable with the parameter substitution. That's why I called it FS.

        > Because the core of forrest - an internal plugin exactly... - defines the serializer with ...

        I don't know how Forrest works internally, but does Forrest provide other extension mechanisms? Have you asked on the Forrest list for possibilities?

        > Another mistake is to confuse properties substitution in cocoon 2.2 (using ${} syntax) with sitemap variable substitution (using {} syntax).

        That probably results from Forrest already being based on Cocoon 2.2?

        > What do you mean by include XML entities?

        <!DOCTYPE root [
                <!ENTITY dtPublic SYSTEM "file://doctype-public.xml">
                <!ENTITY dtSystem SYSTEM "file://doctype-system.xml">
        ]

        <map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html" name="xhtml" pool-grow="2" pool-max="64" pool-min="2"
                src="org.apache.cocoon.serialization.XMLSerializer">
                &dtPublic;
                &dtSystem;
                <encoding>UTF-8</encoding>
                <indent>yes</indent>
                <omit-xml-declaration>no</omit-xml-declaration>
        </map:serializer>

        with doctype-public.xml:

        <doctype-public> -//W3C//DTD XHTML 1.0 Strict//EN </doctype-public>

        and doctype-system.xml:

        <doctype-system> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd </doctype-system>

        And so both files could be used as configuration.

        Jörg
        Show
        Jörg Heinicke added a comment - > Doctype is configurable right now, see Cocoon samples Of course it is. But I wondered why he wants to make even the configuration configurable with the parameter substitution. That's why I called it FS. > Because the core of forrest - an internal plugin exactly... - defines the serializer with ... I don't know how Forrest works internally, but does Forrest provide other extension mechanisms? Have you asked on the Forrest list for possibilities? > Another mistake is to confuse properties substitution in cocoon 2.2 (using ${} syntax) with sitemap variable substitution (using {} syntax). That probably results from Forrest already being based on Cocoon 2.2? > What do you mean by include XML entities? <!DOCTYPE root [         <!ENTITY dtPublic SYSTEM " file://doctype-public.xml ">         <!ENTITY dtSystem SYSTEM " file://doctype-system.xml "> ] <map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html" name="xhtml" pool-grow="2" pool-max="64" pool-min="2"         src="org.apache.cocoon.serialization.XMLSerializer">         &dtPublic;         &dtSystem;         <encoding>UTF-8</encoding>         <indent>yes</indent>         <omit-xml-declaration>no</omit-xml-declaration> </map:serializer> with doctype-public.xml: <doctype-public> -//W3C//DTD XHTML 1.0 Strict//EN </doctype-public> and doctype-system.xml: <doctype-system> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd </doctype-system> And so both files could be used as configuration. Jörg
        Hide
        Vadim Gritsenko added a comment -
        To Joerg:
        Doctype is configurable right now, see Cocoon samples:
            <map:serializer logger="sitemap.serializer.html" mime-type="text/html" name="html" pool-max="${html-serializer.pool-max}" src="org.apache.cocoon.serialization.HTMLSerializer">
              <doctype-public>-//W3C//DTD HTML 4.01 Transitional//EN</doctype-public>
              <doctype-system>http://www.w3.org/TR/html4/loose.dtd&lt;/doctype-system>
            </map:serializer>

        What Cyriaque is suggesting is syntax change, which I am against since it does not give anything, and introduces inconsistent syntax.


        To Cyriaque:
        You are mistaken, syntax change will not help you. Variable substitution in component configuration has to happen manually. Sitemap variable susbstitution in parameter values is happening only within <map:pipeline> section, not within <map:components> section.

        Another mistake is to confuse properties substitution in cocoon 2.2 (using ${} syntax) with sitemap variable substitution (using {} syntax).

        Vadim
        Show
        Vadim Gritsenko added a comment - To Joerg: Doctype is configurable right now, see Cocoon samples:     <map:serializer logger="sitemap.serializer.html" mime-type="text/html" name="html" pool-max="${html-serializer.pool-max}" src="org.apache.cocoon.serialization.HTMLSerializer">       <doctype-public>-//W3C//DTD HTML 4.01 Transitional//EN</doctype-public>       <doctype-system> http://www.w3.org/TR/html4/loose.dtd&lt;/doctype-system >     </map:serializer> What Cyriaque is suggesting is syntax change, which I am against since it does not give anything, and introduces inconsistent syntax. To Cyriaque: You are mistaken, syntax change will not help you. Variable substitution in component configuration has to happen manually. Sitemap variable susbstitution in parameter values is happening only within <map:pipeline> section, not within <map:components> section. Another mistake is to confuse properties substitution in cocoon 2.2 (using ${} syntax) with sitemap variable substitution (using {} syntax). Vadim
        Hide
        Cyriaque Dupoirieux added a comment -
        Because the core of forrest - an internal plugin exactly... - defines the serializer with :

           <doctype-public> -//W3C//DTD XHTML 1.0 Strict//EN </doctype-public>
           <doctype-system> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd </doctype-system>

        It may be complex for webmasters using Forrest to be XHTM Strict compliant - I don't know if you have tried...

        And it is not possible at the moment to configure it through a forrest configuration file.

        That's all.

        I am not sure it is featuritis - I didn't know the word, but I like it - since I need it and have no other solution than to have a local change a file of the core of Forrest to do what I want... - The next step can be to have a local change a class of the core of Cocoon ?

        What do you mean by include XML entities ? It may be the solution ?
        Show
        Cyriaque Dupoirieux added a comment - Because the core of forrest - an internal plugin exactly... - defines the serializer with :    <doctype-public> -//W3C//DTD XHTML 1.0 Strict//EN </doctype-public>    <doctype-system> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd </doctype-system> It may be complex for webmasters using Forrest to be XHTM Strict compliant - I don't know if you have tried... And it is not possible at the moment to configure it through a forrest configuration file. That's all. I am not sure it is featuritis - I didn't know the word, but I like it - since I need it and have no other solution than to have a local change a file of the core of Forrest to do what I want... - The next step can be to have a local change a class of the core of Cocoon ? What do you mean by include XML entities ? It may be the solution ?
        Hide
        Jörg Heinicke added a comment -
        Sorry, but this really looks like FS (Flexibility Syndrome aka featuritis). Why do you need this dynamic? Where do those values come from? Aren't there other include mechanisms possible like XML entities?

        Jörg
        Show
        Jörg Heinicke added a comment - Sorry, but this really looks like FS (Flexibility Syndrome aka featuritis). Why do you need this dynamic? Where do those values come from? Aren't there other include mechanisms possible like XML entities? Jörg
        Hide
        Cyriaque Dupoirieux added a comment -
        Here is my problem,
        I want to use two variables to be able to define the doctype-public and the doctype-system.
        At the moment if I try this :
        <map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html" name="xhtml" pool-grow="2" pool-max="64" pool-min="2"
                src="org.apache.cocoon.serialization.XMLSerializer">
                <doctype-public>${doctype-public}</doctype-public>
                <doctype-system>${doctype-system}</doctype-system>
                <encoding>UTF-8</encoding>
                <indent>yes</indent>
        <omit-xml-declaration>no</omit-xml-declaration>
        </map:serializer>

        I get this :

        <!DOCTYPE html PUBLIC "${doctype-public}" "${doctype-system}">

        And I have seen example where variable are used in a tag attribute value :
            <map:parameter name="dispatcher.caching" value="{forrest:dispatcher.caching}" />

        So I think my problem should be solve if I could write the example exposed in my first comment...
        Show
        Cyriaque Dupoirieux added a comment - Here is my problem, I want to use two variables to be able to define the doctype-public and the doctype-system. At the moment if I try this : <map:serializer logger="sitemap.serializer.xhtml" mime-type="text/html" name="xhtml" pool-grow="2" pool-max="64" pool-min="2"         src="org.apache.cocoon.serialization.XMLSerializer">         <doctype-public>${doctype-public}</doctype-public>         <doctype-system>${doctype-system}</doctype-system>         <encoding>UTF-8</encoding>         <indent>yes</indent> <omit-xml-declaration>no</omit-xml-declaration> </map:serializer> I get this : <!DOCTYPE html PUBLIC "${doctype-public}" "${doctype-system}"> And I have seen example where variable are used in a tag attribute value :     <map:parameter name="dispatcher.caching" value="{forrest:dispatcher.caching}" /> So I think my problem should be solve if I could write the example exposed in my first comment...
        Hide
        Antonio Gallardo added a comment -
        Would you provide an use case? I am asking because I wonder why this is needed.
        Show
        Antonio Gallardo added a comment - Would you provide an use case? I am asking because I wonder why this is needed.

          People

          • Assignee:
            Unassigned
            Reporter:
            Cyriaque Dupoirieux
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development