Forrest
  1. Forrest
  2. FOR-588 Design new configuration system
  3. FOR-800

make forrest.properties.xml (as aggregation of all properties) aviable via cocoon://

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core operations
    • Labels:
      None
    • Urgency:
      Blocker

      Description

      That the new properties is usable to a wider range of use cases we need to be able to request all of them via on match.

      Either project specific like:
      cocoon://forrest.properties.xml

      or path specific like:
      cocoon://**.properties.xml

        Activity

        Hide
        Ross Gardler added a comment -
        The properties file is XML, just add a mather to the core sitemap, e.g.:

        <map:match pattern="*.properties.xml">
          <map:read src="{lm:properties.{1}}"/>
        </map:match>

        However, I've not done this, partly because I don't have the time to test right now and partly because I don't see the need. All properties are available to the sitemap and from there they can be passed to any resource in the pipeline.

        Can you give a use case where this is necessary (I know we have discussed this on the ML but there has been no use case for it yet).

        Show
        Ross Gardler added a comment - The properties file is XML, just add a mather to the core sitemap, e.g.: <map:match pattern="*.properties.xml">   <map:read src="{lm:properties.{1}}"/> </map:match> However, I've not done this, partly because I don't have the time to test right now and partly because I don't see the need. All properties are available to the sitemap and from there they can be passed to any resource in the pipeline. Can you give a use case where this is necessary (I know we have discussed this on the ML but there has been no use case for it yet).
        Hide
        Thorsten Scherler added a comment -
        Hmm, I do not understand.

        I am looking for all aviable properties. I read something about default.forrest.properties.xml, ... but which can I request ( I do not know with which I need to substitute the *)

        To pass all this props in the sitemap is not efficient, that is the biggest problem of input modules in general (you cannot use them directly in xsl).

        We can not decide which properties a contract will need and further it is not easy to extend because you need to touch the sitemap. A contract should be able to request any given prop from *.properties.xml.

        Please see the master.ft:
        ...
        <!-- If you need default variables: -->
              <!--<xsl:param name="defaultVariables" select="'test.html'"/>-->
              <!-- then extract the variable like: -->
              <!--<xsl:variable name="skin-img-dir" select="$defaultVariables/*/*[@name='skin-img-dir']/@value"/>-->
              <!-- more information which variables are aviable can be found at lm://transform.xml.variable.helper
                
                  FIXME: This property xsl is in early stage and aims to be connected to the new established input module based one.
                  We need to write a custom generator for this. The generator will contact the prop-input module to get all aviable key/values and
                  outputs them to xml (dtd like forrest.properties.xml). -->
                  
        Show
        Thorsten Scherler added a comment - Hmm, I do not understand. I am looking for all aviable properties. I read something about default.forrest.properties.xml, ... but which can I request ( I do not know with which I need to substitute the *) To pass all this props in the sitemap is not efficient, that is the biggest problem of input modules in general (you cannot use them directly in xsl). We can not decide which properties a contract will need and further it is not easy to extend because you need to touch the sitemap. A contract should be able to request any given prop from *.properties.xml. Please see the master.ft: ... <!-- If you need default variables: -->       <!--<xsl:param name="defaultVariables" select="'test.html'"/>-->       <!-- then extract the variable like: -->       <!--<xsl:variable name="skin-img-dir" select="$defaultVariables/*/*[@name='skin-img-dir']/@value"/>-->       <!-- more information which variables are aviable can be found at lm://transform.xml.variable.helper                    FIXME: This property xsl is in early stage and aims to be connected to the new established input module based one.           We need to write a custom generator for this. The generator will contact the prop-input module to get all aviable key/values and           outputs them to xml (dtd like forrest.properties.xml). -->           
        Hide
        Ross Gardler added a comment -
        Show
        Ross Gardler added a comment - Cocoons XMLFileInputModule may be the answer ( http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/modules/input/XMLFileModule.html )
        Hide
        Thorsten Scherler added a comment -
        The last remaining issue was implementing the Iterator getAttributeNames in the
        ForrestConfModule. To see all aviable properties add
        org.apache.forrest.plugin.output.inputModule and request
        cocoon://module.project.properties.
        Show
        Thorsten Scherler added a comment - The last remaining issue was implementing the Iterator getAttributeNames in the ForrestConfModule. To see all aviable properties add org.apache.forrest.plugin.output.inputModule and request cocoon://module.project.properties .

          People

          • Assignee:
            Unassigned
            Reporter:
            Thorsten Scherler
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development