Commons Digester
  1. Commons Digester
  2. DIGESTER-82

[digester] Make <set-nested-properties-rule> available

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: Nightly Builds
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: Windows 2000
      Platform: PC

      Description

      Please make <set-nested-properties-rule> available in digester-rules.dtd, for
      use with Digester when using xml-based rules. The SetNestedPropertiesRule class
      already exists, but there doesn't seem to be a way to use it from rules.xml.

        Activity

        Hide
        Simon Kitching added a comment -

        I've committed the patch to add Addresses to the basic example, so that
        SetNestedPropertiesRule can be demonstrated.

        I have tweaked things slightly to improve the layout of the address info when
        printed. And I've replaced tabs with spaces; if possible, please use spaces for
        indenting.

        And I've changed the api/addressbook example to match the xmlrules version.

        I think everything to do with this bug is now complete and committed, so I'm
        going to close this bugzilla entry.

        Thanks for the patches!

        Show
        Simon Kitching added a comment - I've committed the patch to add Addresses to the basic example, so that SetNestedPropertiesRule can be demonstrated. I have tweaked things slightly to improve the layout of the address info when printed. And I've replaced tabs with spaces; if possible, please use spaces for indenting. And I've changed the api/addressbook example to match the xmlrules version. I think everything to do with this bug is now complete and committed, so I'm going to close this bugzilla entry. Thanks for the patches!
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=14009)
        src/examples/xmlrules/addressbook/Address.java

        New file necessary if the patch to the xmlrules/addressbook/ example is
        accepted.

        src/examples/xmlrules/addressbook/Address.java

        Show
        Wendy Smoak added a comment - Created an attachment (id=14009) src/examples/xmlrules/addressbook/Address.java New file necessary if the patch to the xmlrules/addressbook/ example is accepted. src/examples/xmlrules/addressbook/Address.java
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=14008)
        Changes to the xmlrules/addressbook/ example

        This updates the xmlrules/addressbook/ example to show the use of
        <set-nested-properties-rule/> by populating an Address, a List of which is
        stored in a Person.

        Show
        Wendy Smoak added a comment - Created an attachment (id=14008) Changes to the xmlrules/addressbook/ example This updates the xmlrules/addressbook/ example to show the use of <set-nested-properties-rule/> by populating an Address, a List of which is stored in a Person.
        Hide
        Simon Kitching added a comment -

        Re patch for addressbook example: I'm not keen to apply this in its current
        form, as it removes the current demonstration of how to pass an element's body
        text to a target method (name element's body -> setName method).

        And in general I'm not sure it's good form to use set-nested-properties for
        classes where some of the child elements are not properties, even though the
        "allowUnknownChildElements" flag can be used to make this possible. It certainly
        wasn't what I expected this rule to be used for when I wrote it! Maybe for
        classes where there are lots of child elements mapping to properties it makes
        sense, but in this case there is only one property!

        It would be nice to have an example of set-nested-properties somewhere though;
        perhaps you could think of some way to extend the existing example, or come up
        with a separate example?

        BTW: I've added you to the list of contributors for digester. You'll appear here:
        http://jakarta.apache.org/commons/digester/team-list.html
        after the next website update.

        Show
        Simon Kitching added a comment - Re patch for addressbook example: I'm not keen to apply this in its current form, as it removes the current demonstration of how to pass an element's body text to a target method (name element's body -> setName method). And in general I'm not sure it's good form to use set-nested-properties for classes where some of the child elements are not properties, even though the "allowUnknownChildElements" flag can be used to make this possible. It certainly wasn't what I expected this rule to be used for when I wrote it! Maybe for classes where there are lots of child elements mapping to properties it makes sense, but in this case there is only one property! It would be nice to have an example of set-nested-properties somewhere though; perhaps you could think of some way to extend the existing example, or come up with a separate example? BTW: I've added you to the list of contributors for digester. You'll appear here: http://jakarta.apache.org/commons/digester/team-list.html after the next website update.
        Hide
        Simon Kitching added a comment -

        >> I don't actually like xmlrules very much (at least in its current form).

        >Any comments on the form you'd like it to take? What about it do you dislike?
        >(The whole concept, or how it was implemented?)

        Well, I'm not convinced it brings much benefit. When I first met digester, I
        started using the xmlrules module, because it seemed to be the "highest
        abstraction". But in fact I found that the xml being parsed and the java classes
        that are being created/populated are conceptually tightly coupled anyway. There
        just isn't much need to change the xml->class mapping unless the classes are
        being changed. And if the classes are being changed then it isn't really any
        more work to change a mapping defined as code than to change a mapping defined
        in an external rules file.

        And anyone writing an application using digester will already be fluent in Java,
        so moving the mapping from code to external xml file doesn't make life any
        easier that way. In fact, I think it makes things harder; I find the API easier
        to comprehend than the xmlrules format. And certainly if you have any "bugs" in
        your mapping, then you really need to know how the rule classes work. So in
        summary, the learning curve is worse for learning xmlrules than for learning
        the underlying API.

        And it's a nuisance to maintain, because after adding a new feature to the API,
        you need to add it to xmlrules as well. And writing unit-tests for xmlrules is a
        nuisance too.

        And xmlrules has significant overhead when processing small input files, because
        the xmlrules file needs to be parsed first to set up all the rules.

        And there are some features you just can't access via xmlrules. One example is
        passing references to arbitrary java objects via the ObjectParamRule.

        I can see xmlrules being useful in some situations. If you want to provide
        configuration files in multiple languages, then it may make sense to use
        xmlrules, as it is probably easier to "internationalise" than code using the
        API. And maybe if writing some code-generation tool (eg from a UML diagram) then
        it may be easier to generate xmlrules definitions than calls to the digester API.

        But in general, I think xmlrules is harder to learn, has runtime CPU and
        memory overhead, and brings no practical benefit.

        And one other thing: it is very easy to add custom Rule classes when using the
        API; it's somewhat more complex to do so when using xmlrules.

        I'm playing with some ideas for "digester 2.0" at the moment. One thing I would
        like to do is make it easier to keep xmlrules in synch with the API; all those
        rule factory classes seem unnecessary to me.

        Show
        Simon Kitching added a comment - >> I don't actually like xmlrules very much (at least in its current form). >Any comments on the form you'd like it to take? What about it do you dislike? >(The whole concept, or how it was implemented?) Well, I'm not convinced it brings much benefit. When I first met digester, I started using the xmlrules module, because it seemed to be the "highest abstraction". But in fact I found that the xml being parsed and the java classes that are being created/populated are conceptually tightly coupled anyway. There just isn't much need to change the xml->class mapping unless the classes are being changed. And if the classes are being changed then it isn't really any more work to change a mapping defined as code than to change a mapping defined in an external rules file. And anyone writing an application using digester will already be fluent in Java, so moving the mapping from code to external xml file doesn't make life any easier that way. In fact, I think it makes things harder; I find the API easier to comprehend than the xmlrules format. And certainly if you have any "bugs" in your mapping, then you really need to know how the rule classes work. So in summary, the learning curve is worse for learning xmlrules than for learning the underlying API. And it's a nuisance to maintain, because after adding a new feature to the API, you need to add it to xmlrules as well. And writing unit-tests for xmlrules is a nuisance too. And xmlrules has significant overhead when processing small input files, because the xmlrules file needs to be parsed first to set up all the rules. And there are some features you just can't access via xmlrules. One example is passing references to arbitrary java objects via the ObjectParamRule. I can see xmlrules being useful in some situations. If you want to provide configuration files in multiple languages, then it may make sense to use xmlrules, as it is probably easier to "internationalise" than code using the API. And maybe if writing some code-generation tool (eg from a UML diagram) then it may be easier to generate xmlrules definitions than calls to the digester API. But in general, I think xmlrules is harder to learn , has runtime CPU and memory overhead, and brings no practical benefit. And one other thing: it is very easy to add custom Rule classes when using the API; it's somewhat more complex to do so when using xmlrules. I'm playing with some ideas for "digester 2.0" at the moment. One thing I would like to do is make it easier to keep xmlrules in synch with the API; all those rule factory classes seem unnecessary to me.
        Hide
        Wendy Smoak added a comment -

        (In reply to comment #18)
        > By the way, would you like me to add your name to the "developers" list in file
        > project.xml?

        Yes, thanks.

        (In reply to comment #16)
        > I don't actually like xmlrules very much (at least in its current form).

        Any comments on the form you'd like it to take? What about it do you dislike?
        (The whole concept, or how it was implemented?)

        Show
        Wendy Smoak added a comment - (In reply to comment #18) > By the way, would you like me to add your name to the "developers" list in file > project.xml? Yes, thanks. (In reply to comment #16) > I don't actually like xmlrules very much (at least in its current form). Any comments on the form you'd like it to take? What about it do you dislike? (The whole concept, or how it was implemented?)
        Hide
        Simon Kitching added a comment -

        By the way, would you like me to add your name to the "developers" list in file
        project.xml?

        Show
        Simon Kitching added a comment - By the way, would you like me to add your name to the "developers" list in file project.xml?
        Hide
        Wendy Smoak added a comment -

        > If you can find a convenient place to put this information within the xmlrules
        > package, however, I would be happy to commit it there.

        Thanks, I wasn't sure where to put the usage example. I think (should I be so
        motivated) I'll either add more comments to the DTD itself (there is a usage
        example for pattern, but it is the only one) or expand the xmlrules/addressbook/
        example.

        > I'll commit changes to digester-rules.dtd to add set-nested-properties-rule
        > in a day or so if no-one (including yourself) objects to the version I
        > attached to the bugzilla entry.

        It looks fine to me. The name doesn't matter all that much at this point. (My
        argument is that someone using the current released version of Digester and
        validating against the publicly available copy of the DTD will see tags
        available that don't actually work.)

        Thank you for the info on entities! I learned a lot more about DTDs while I was
        researching, but could not find out what that percent sign was for.

        Show
        Wendy Smoak added a comment - > If you can find a convenient place to put this information within the xmlrules > package, however, I would be happy to commit it there. Thanks, I wasn't sure where to put the usage example. I think (should I be so motivated) I'll either add more comments to the DTD itself (there is a usage example for pattern, but it is the only one) or expand the xmlrules/addressbook/ example. > I'll commit changes to digester-rules.dtd to add set-nested-properties-rule > in a day or so if no-one (including yourself) objects to the version I > attached to the bugzilla entry. It looks fine to me. The name doesn't matter all that much at this point. (My argument is that someone using the current released version of Digester and validating against the publicly available copy of the DTD will see tags available that don't actually work.) Thank you for the info on entities! I learned a lot more about DTDs while I was researching, but could not find out what that percent sign was for.
        Hide
        Simon Kitching added a comment -

        Hi Wendy,

        ==
        I've committed your patch for DigesterRuleParser.java.

        ==
        I've also committed most of your patch for SetNestedPropertiesRule.java.

        I have left out the comments re xmlrules usage. Xmlrules is a layer "on top of"
        the basic Digester functionality, so I don't feel that xmlrules-specific
        comments belong in the core rule classes.

        And in addition, I don't actually like xmlrules very much (at least in its
        current form). I don't dislike it enough to agitate to remove it, and I don't
        mind helping with patches for it. However I definitely prefer to keep
        xmlrules-related functionality (and comments) well separated from the core. If
        you can find a convenient place to put this information within the xmlrules
        package, however, I would be happy to commit it there.

        ==
        I'll commit changes to digester-rules.dtd to add set-nested-properties-rule in a
        day or so if no-one (including yourself) objects to the version I attached to
        the bugzilla entry.

        Thanks for the patches...

        Show
        Simon Kitching added a comment - Hi Wendy, == I've committed your patch for DigesterRuleParser.java. == I've also committed most of your patch for SetNestedPropertiesRule.java. I have left out the comments re xmlrules usage. Xmlrules is a layer "on top of" the basic Digester functionality, so I don't feel that xmlrules-specific comments belong in the core rule classes. And in addition, I don't actually like xmlrules very much (at least in its current form). I don't dislike it enough to agitate to remove it, and I don't mind helping with patches for it. However I definitely prefer to keep xmlrules-related functionality (and comments) well separated from the core. If you can find a convenient place to put this information within the xmlrules package, however, I would be happy to commit it there. == I'll commit changes to digester-rules.dtd to add set-nested-properties-rule in a day or so if no-one (including yourself) objects to the version I attached to the bugzilla entry. Thanks for the patches...
        Hide
        Simon Kitching added a comment -

        Created an attachment (id=13978)
        updated dtd file using parameter entities

        Show
        Simon Kitching added a comment - Created an attachment (id=13978) updated dtd file using parameter entities
        Hide
        Simon Kitching added a comment -

        <!ENTITY ...> declares stuff that can be referenced from the XML.

        <!ENTITY % ...> declares stuff that can be referenced from the DTD. This is
        called a "Parameter Entity". It can then be referred to from within the DTD
        using "%name;" (aka a "Parameter Entity Reference" or PEReference).

        It should therefore be possible to define the list of available rule elements
        just once using <!ENTITY % rule-elements ...> then reference this entity instead
        of duplicating the list everywhere it is needed in the dtd. For some reason the
        original author of the dtd declared the appropriate Parameter Entity, but then
        used copy-and-paste rather than referencing the entity.

        Personally I would prefer to use this entity correctly rather than remove it -
        unless someone can suggest a reason to avoid using <!ENTITY % ...>.

        I have attached a modified DTD with this change and your (Wendy's) changes;
        Wendy, are you happy with this?

        BTW, thanks for the pointer to the jEdit ErrorList window.

        Re changing xmlrules to validate the rules file against the DTD: well, it
        certainly wouldn't be a good idea to validate against a remote version of the
        dtd, but it would be possible to define an EntityResolver so that it validates
        against a local version of the dtd found in the digester jar file. We would also
        need a way for people to disable this, eg if they add their own tags - I guess
        people could just leave out the PUBLIC/SYSTEM id in their xmlrules file? I have
        no real objection to this if you wish to provide a patch. Anyone else got a
        comment on this?

        Re the part of your patch to change the recommended doctype declaration in
        xmlrules config files from:
        <!DOCTYPE digester-rules PUBLIC
        "-//Jakarta Apache //DTD digester-rules XML V1.0//EN"
        "digester-rules.dtd">
        to:
        <!DOCTYPE digester-rules PUBLIC
        "-//Jakarta Apache //DTD digester-rules XML V1.0//EN"
        "http://jakarta.apache.org/commons/digester/dtds/digester-rules.dtd">
        I'm not really keen on this. I think people should be using a Catalog to map the
        public id to a local copy of the DTD.

        We should definitely update the file at
        "http://jakarta.apache.org/commons/digester/dtds/digester-rules.dtd" though. I
        will do this once we have finished with changes to the dtd (and add this task to
        the release procedure). As all the proposed changes are backwards-compatibile, I
        don't see any particular reason to change the dtd name to include a version
        number (though I'm open to arguments).

        Show
        Simon Kitching added a comment - <!ENTITY ...> declares stuff that can be referenced from the XML. <!ENTITY % ...> declares stuff that can be referenced from the DTD. This is called a "Parameter Entity". It can then be referred to from within the DTD using "%name;" (aka a "Parameter Entity Reference" or PEReference). It should therefore be possible to define the list of available rule elements just once using <!ENTITY % rule-elements ...> then reference this entity instead of duplicating the list everywhere it is needed in the dtd. For some reason the original author of the dtd declared the appropriate Parameter Entity, but then used copy-and-paste rather than referencing the entity. Personally I would prefer to use this entity correctly rather than remove it - unless someone can suggest a reason to avoid using <!ENTITY % ...>. I have attached a modified DTD with this change and your (Wendy's) changes; Wendy, are you happy with this? BTW, thanks for the pointer to the jEdit ErrorList window. Re changing xmlrules to validate the rules file against the DTD: well, it certainly wouldn't be a good idea to validate against a remote version of the dtd, but it would be possible to define an EntityResolver so that it validates against a local version of the dtd found in the digester jar file. We would also need a way for people to disable this, eg if they add their own tags - I guess people could just leave out the PUBLIC/SYSTEM id in their xmlrules file? I have no real objection to this if you wish to provide a patch. Anyone else got a comment on this? Re the part of your patch to change the recommended doctype declaration in xmlrules config files from: <!DOCTYPE digester-rules PUBLIC "-//Jakarta Apache //DTD digester-rules XML V1.0//EN" "digester-rules.dtd"> to: <!DOCTYPE digester-rules PUBLIC "-//Jakarta Apache //DTD digester-rules XML V1.0//EN" "http://jakarta.apache.org/commons/digester/dtds/digester-rules.dtd"> I'm not really keen on this. I think people should be using a Catalog to map the public id to a local copy of the DTD. We should definitely update the file at "http://jakarta.apache.org/commons/digester/dtds/digester-rules.dtd" though. I will do this once we have finished with changes to the dtd (and add this task to the release procedure). As all the proposed changes are backwards-compatibile, I don't see any particular reason to change the dtd name to include a version number (though I'm open to arguments).
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13977)
        Corrected patch to digester-rules.dtd

        Correction because the original patch didn't fix the pattern element.

        I removed the <!ENTITY because it looked like it was intended to be used
        within the DTD, as the list of allowed content for both the pattern and
        digester-rules. However, nothing I could find said that <!ENTITY could be used
        this way, only that you define entities in the DTD and then use them in the
        XML.

        digester-rules and pattern now have the same list of allowed contents,
        including every other tag in the DTD except for alias (well, and digester-rules
        itself.)

        Thanks for your patience. I think I'm done now [again].

        Show
        Wendy Smoak added a comment - Created an attachment (id=13977) Corrected patch to digester-rules.dtd Correction because the original patch didn't fix the pattern element. I removed the <!ENTITY because it looked like it was intended to be used within the DTD, as the list of allowed content for both the pattern and digester-rules. However, nothing I could find said that <!ENTITY could be used this way, only that you define entities in the DTD and then use them in the XML. digester-rules and pattern now have the same list of allowed contents, including every other tag in the DTD except for alias (well, and digester-rules itself.) Thanks for your patience. I think I'm done now [again] .
        Hide
        Wendy Smoak added a comment -

        (In reply to comment #11)
        > I'll have to look at Jedit's XMLPlugin again - that was what I was trying to
        > use, but I couldn't see where (if) validation errors were being displayed...

        Plugins -> ErrorList. You should also be seeing a thin red underline if it
        doesn't like something.

        Is there a reason that Digester does NOT validate rules.xml? I looked around in
        the source and saw some references to 'the dtd used to validate the rules' but
        it's not happening.

        Will it be possible to make the updated version of the DTD publicly available?

        I ask because the one that's available here:
        http://jakarta.apache.org/commons/digester/dtds/digester-rules.dtd is older than
        the one under /src/. It doesn't have the Apache license on it, if that's
        important. I assume it's the one in /digester/xdocs/dtds/ --they match, at least.

        What about having digester-rules_1_7.dtd so work on the new version can continue
        without disturbing people using the 'old' one?

        Show
        Wendy Smoak added a comment - (In reply to comment #11) > I'll have to look at Jedit's XMLPlugin again - that was what I was trying to > use, but I couldn't see where (if) validation errors were being displayed... Plugins -> ErrorList. You should also be seeing a thin red underline if it doesn't like something. Is there a reason that Digester does NOT validate rules.xml? I looked around in the source and saw some references to 'the dtd used to validate the rules' but it's not happening. Will it be possible to make the updated version of the DTD publicly available? I ask because the one that's available here: http://jakarta.apache.org/commons/digester/dtds/digester-rules.dtd is older than the one under /src/. It doesn't have the Apache license on it, if that's important. I assume it's the one in /digester/xdocs/dtds/ --they match, at least. What about having digester-rules_1_7.dtd so work on the new version can continue without disturbing people using the 'old' one?
        Hide
        Simon Kitching added a comment -

        > JEdit and the XML Plugin. It validates and auto-completes as you work.

        I'll have to look at Jedit's XMLPlugin again - that was what I was trying to
        use, but I couldn't see where (if) validation errors were being displayed...

        > Are digester-rules and pattern supposed to have the same list of allowed
        > content? They're both missing set-root-rule, and pattern doesn't have
        > object-param-rule.

        I expect this is a "bug". The authors of the xmlrules module have moved on, and
        neither of the regular Digester maintainers (Robert Donkin and myself) use
        xmlrules, so new functionality does sometimes get left out of xmlrules until
        someone explicitly asks for it (and preferably provides patches like you!).

        Of course the fact that the DTD isn't up-to-date doesn't affect the
        functionality at all; it just affects people who use dtd-aware xml editors to
        create the xmlrules definition files.

        Show
        Simon Kitching added a comment - > JEdit and the XML Plugin. It validates and auto-completes as you work. I'll have to look at Jedit's XMLPlugin again - that was what I was trying to use, but I couldn't see where (if) validation errors were being displayed... > Are digester-rules and pattern supposed to have the same list of allowed > content? They're both missing set-root-rule, and pattern doesn't have > object-param-rule. I expect this is a "bug". The authors of the xmlrules module have moved on, and neither of the regular Digester maintainers (Robert Donkin and myself) use xmlrules, so new functionality does sometimes get left out of xmlrules until someone explicitly asks for it (and preferably provides patches like you!). Of course the fact that the DTD isn't up-to-date doesn't affect the functionality at all; it just affects people who use dtd-aware xml editors to create the xmlrules definition files.
        Hide
        Wendy Smoak added a comment -

        > BTW, what tool are you using to validate xmlrules files against
        > the (modified) digester-rules.dtd?

        JEdit and the XML Plugin. It validates and auto-completes as you work.

        Are digester-rules and pattern supposed to have the same list of allowed
        content? They're both missing set-root-rule, and pattern doesn't have
        object-param-rule.

        Show
        Wendy Smoak added a comment - > BTW, what tool are you using to validate xmlrules files against > the (modified) digester-rules.dtd? JEdit and the XML Plugin. It validates and auto-completes as you work. Are digester-rules and pattern supposed to have the same list of allowed content? They're both missing set-root-rule, and pattern doesn't have object-param-rule.
        Hide
        Simon Kitching added a comment -

        Hi Wendy,

        Thanks for your patches. I'll try to have a look at these tomorrow (or the day
        after depending on the weather

        BTW, what tool are you using to validate xmlrules files against the (modified)
        digester-rules.dtd?

        Show
        Simon Kitching added a comment - Hi Wendy, Thanks for your patches. I'll try to have a look at these tomorrow (or the day after depending on the weather BTW, what tool are you using to validate xmlrules files against the (modified) digester-rules.dtd?
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13969)
        Patch to SetNestedPropertiesRule.java - javadoc and toString method

        SetNestedPropertiesRule: correction to the javadoc for
        'setAllowUnknownChildElements' plus examples of xml rules. Added details to
        the 'toString' method.

        Show
        Wendy Smoak added a comment - Created an attachment (id=13969) Patch to SetNestedPropertiesRule.java - javadoc and toString method SetNestedPropertiesRule: correction to the javadoc for 'setAllowUnknownChildElements' plus examples of xml rules. Added details to the 'toString' method.
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13968)
        Patch to DigesterRuleParser.java to add set-nested-properties-rule w/
        allow-unknown-child-elements attribute & nested <alias> tag

        I think it's finished. You can now map attributes to properties when they
        don't have the same name, as well as ignore certain attributes. Example:

        <set-nested-properties-rule allow-unknown-child-elements="true">
        <alias attr-name="something" prop-name="somethingElse" />
        <alias attr-name="attribToIgnore" />
        </set-nested-properties-rule>

        Show
        Wendy Smoak added a comment - Created an attachment (id=13968) Patch to DigesterRuleParser.java to add set-nested-properties-rule w/ allow-unknown-child-elements attribute & nested <alias> tag I think it's finished. You can now map attributes to properties when they don't have the same name, as well as ignore certain attributes. Example: <set-nested-properties-rule allow-unknown-child-elements="true"> <alias attr-name="something" prop-name="somethingElse" /> <alias attr-name="attribToIgnore" /> </set-nested-properties-rule>
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13957)
        An alternate set of xml rules for the addressbook example

        This belongs in ...digester/src/examples/xmlrules/addressbook and is an
        alternate set of rules that does the same thing as xmlrules.xml.

        It uses the <set-nested-properties-rule> rather than <call-method-rule> to set
        the 'name' (and would set any other nested properties, but there aren't any).

        It ignores the nested 'email' tag because there isn't a 'setEmail' method in
        the Person object.

        Show
        Wendy Smoak added a comment - Created an attachment (id=13957) An alternate set of xml rules for the addressbook example This belongs in ...digester/src/examples/xmlrules/addressbook and is an alternate set of rules that does the same thing as xmlrules.xml. It uses the <set-nested-properties-rule> rather than <call-method-rule> to set the 'name' (and would set any other nested properties, but there aren't any). It ignores the nested 'email' tag because there isn't a 'setEmail' method in the Person object.
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13956)
        Patch to digester-rules.dtd for set-nested-properties-rule tag

        Show
        Wendy Smoak added a comment - Created an attachment (id=13956) Patch to digester-rules.dtd for set-nested-properties-rule tag
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13955)
        Patch to DigesterRuleParser.java to add set-nested-properties-rule w/
        allow-unknown-child-elements attribute

        Once more to allow unknown child elements when using
        <set-nested-properties-rule> from xml rules.

        Usage:
        <set-nested-properties-rule allow-unknown-child-elements="true"/>

        I note that in every other case, there is a constructor for the Rule so that
        you don't have to construct the object and call a method on it before returning
        it. But I didn't want to go as far as adding a constructor to
        SetNestedPropertiesRule without guidance.

        Show
        Wendy Smoak added a comment - Created an attachment (id=13955) Patch to DigesterRuleParser.java to add set-nested-properties-rule w/ allow-unknown-child-elements attribute Once more to allow unknown child elements when using <set-nested-properties-rule> from xml rules. Usage: <set-nested-properties-rule allow-unknown-child-elements="true"/> I note that in every other case, there is a constructor for the Rule so that you don't have to construct the object and call a method on it before returning it. But I didn't want to go as far as adding a constructor to SetNestedPropertiesRule without guidance.
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13950)
        Corrected patch to DigesterRuleParser.java to add set-nested-properties-rule

        Oops. This file contains only one version of the patch.

        Show
        Wendy Smoak added a comment - Created an attachment (id=13950) Corrected patch to DigesterRuleParser.java to add set-nested-properties-rule Oops. This file contains only one version of the patch.
        Hide
        Wendy Smoak added a comment -

        I'm attaching what I've got so far (a patch to DigesterRulesParser.java).

        It works fine as long as you have matching properties for all your nested tags,
        but that won't always be the case-- the addressbook example.xml has a nested
        <email> tag that should be ignored by <set-nested-properties-rule/> since it
        gets handled by a <call-method-rule>.

        SetNestedPropertiesRule has an option to 'allowUnknownChildElements' and I don't
        know how to make that work from rules.xml, such as:
        <set-nested-properties-rule allowUnknownChildElements="true"/>

        First, is this the way it should be done in a rules xml file? If so, can
        someone give me a hint on how to get that attribute to set the
        allowUnknownChildElements property of the SetNestedPropertiesRule object?

        (And, since this is the first patch I've ever attempted, I would appreciate
        feedback on whether it was done correctly, whether or not it gets applied.)

        Show
        Wendy Smoak added a comment - I'm attaching what I've got so far (a patch to DigesterRulesParser.java). It works fine as long as you have matching properties for all your nested tags, but that won't always be the case-- the addressbook example.xml has a nested <email> tag that should be ignored by <set-nested-properties-rule/> since it gets handled by a <call-method-rule>. SetNestedPropertiesRule has an option to 'allowUnknownChildElements' and I don't know how to make that work from rules.xml, such as: <set-nested-properties-rule allowUnknownChildElements="true"/> First, is this the way it should be done in a rules xml file? If so, can someone give me a hint on how to get that attribute to set the allowUnknownChildElements property of the SetNestedPropertiesRule object? (And, since this is the first patch I've ever attempted, I would appreciate feedback on whether it was done correctly, whether or not it gets applied.)
        Hide
        Wendy Smoak added a comment -

        Created an attachment (id=13949)
        Patch to DigesterRuleParser.java to add set-nested-properties-rule

        Show
        Wendy Smoak added a comment - Created an attachment (id=13949) Patch to DigesterRuleParser.java to add set-nested-properties-rule

          People

          • Assignee:
            Unassigned
            Reporter:
            Wendy Smoak
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development