Details

    • Type: New Feature New Feature
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: SVN trunk
    • Fix Version/s: SVN trunk
    • Component/s: framework
    • Labels:
      None

      Description

      OfBiz allows the creation of views based on the database model. But the data selection is done only by join. It would be great to select the data also by value. And, in some cases, it avoids workarounds and a cleaner code.

      The proposal is to create a new tag inside view-entity tag from entitymodel.xml with the following syntax:

      <filter entity-alias="<table_alias>" field-name="<field_name>" operator="<operator:equals, not-equals, like...>" value="<value_to_select>"/>

      these tag could appear from 0 to N times. When N times, all filter criteria must match with the data to select it.

      I am attaching the xsd and the code I made...

      1. filter_views.patch
        10 kB
        Jacques Le Roux
      2. filter_views.patch
        10 kB
        Jacques Le Roux
      3. filter_views.diff
        10 kB
        Oscar Pablo

        Issue Links

          Activity

          Hide
          Oscar Pablo added a comment -

          Code to add the tag <filter> to a view definition.

          Affects:

          • DynamicViewEntity (it is possible to define filters in a DynamicEntity)
          • ModelViewEntity (xml parsing)
          • SqlJdbcUtil (sql query creation)
          • entitymodel.xsd (view definition)
          Show
          Oscar Pablo added a comment - Code to add the tag <filter> to a view definition. Affects: DynamicViewEntity (it is possible to define filters in a DynamicEntity) ModelViewEntity (xml parsing) SqlJdbcUtil (sql query creation) entitymodel.xsd (view definition)
          Hide
          Jonathon Wong added a comment -

          This works too. My own implementation puts it in the <view-link>, and the "filter condition" can only be applied to either (one or both) tables being joined by the <view-link>.

          That way, it makes for cleaner entitymodel.xml definitions, and we don't easily end up with redundant or duplicate "filter conditions" like when using <filter>.

          A good practice to ensure clean codes in entitymodel.xml, if you're using my approach, is to always add the "filter condition" only for the "2nd table being joined". That is, the "rel-entity-alias". That is assuming you also do the good practice of constructing your <view-entity> in a strict and clean top-down hierarchy!

          Show
          Jonathon Wong added a comment - This works too. My own implementation puts it in the <view-link>, and the "filter condition" can only be applied to either (one or both) tables being joined by the <view-link>. That way, it makes for cleaner entitymodel.xml definitions, and we don't easily end up with redundant or duplicate "filter conditions" like when using <filter>. A good practice to ensure clean codes in entitymodel.xml, if you're using my approach, is to always add the "filter condition" only for the "2nd table being joined". That is, the "rel-entity-alias". That is assuming you also do the good practice of constructing your <view-entity> in a strict and clean top-down hierarchy!
          Hide
          Oscar Pablo added a comment -

          By using the tag <filter> to enter filter conditions, we are not binding the filtering to the join. That is, we can apply a filter even on a single table view. Using the filter tag inside or bound to the <view-link> tag makes the user define a view link to be able to define a filter.

          Control over "filter conditions" to avoid redundant filters I think is not a critical thing, cause developer/designer can easily control that. And, by the way, if not controlled, it doesn't cause an error.

          Show
          Oscar Pablo added a comment - By using the tag <filter> to enter filter conditions, we are not binding the filtering to the join. That is, we can apply a filter even on a single table view. Using the filter tag inside or bound to the <view-link> tag makes the user define a view link to be able to define a filter. Control over "filter conditions" to avoid redundant filters I think is not a critical thing, cause developer/designer can easily control that. And, by the way, if not controlled, it doesn't cause an error.
          Hide
          Jonathon Wong added a comment -

          > By using the tag <filter> to enter filter conditions, we are not binding the
          > filtering to the join. That is, we can apply a filter even on a single table
          > view.

          Why would there be a single table view?

          > Using the filter tag inside or bound to the <view-link> tag makes the user
          > define a view link to be able to define a filter.

          The main motivation for my putting it in the <view-link> tag is this. I want cross-products that are semantically meaningful.

          For eg, you may have a view that consists of "Person, Person's Employer, and Person's Subordinates". Note that the table Person is joined 3 times. With conditions in the joins (<view-link>), it will be possible to have a cross-product like this:

          Person (partyId, firstName, lastName), Person's Employer (empPartyId, empFirstName, empLastName), Person's Subordinate (subPartyId, subFirstName, subLastName).

          Without conditions in the joins, the cross-product will be a massive and rather meaningless one.

          Any other conditions or filters can be done during the query, and may not be required to semantically define a view. At least that is the case for how I intended to use it.

          > Control over "filter conditions" to avoid redundant filters I think is not a
          > critical thing, cause developer/designer can easily control that. And, by the
          > way, if not controlled, it doesn't cause an error.

          True. Putting <filter> tags in a single location in the <entity> element will make it easy enough to avoid duplicates.

          New suggestion. Include the conditionals in the <alias> element, attribute "value".

          Also, include your <filter> tag as a sub-element in the <alias-all> element.

          Still, your top-level <filter> element is most flexible, and easiest to implement. We can roll with that. I vote for it.

          This change is additive, and shouldn't affect existing functionalities.

          Show
          Jonathon Wong added a comment - > By using the tag <filter> to enter filter conditions, we are not binding the > filtering to the join. That is, we can apply a filter even on a single table > view. Why would there be a single table view? > Using the filter tag inside or bound to the <view-link> tag makes the user > define a view link to be able to define a filter. The main motivation for my putting it in the <view-link> tag is this. I want cross-products that are semantically meaningful. For eg, you may have a view that consists of "Person, Person's Employer, and Person's Subordinates". Note that the table Person is joined 3 times. With conditions in the joins (<view-link>), it will be possible to have a cross-product like this: Person (partyId, firstName, lastName), Person's Employer (empPartyId, empFirstName, empLastName), Person's Subordinate (subPartyId, subFirstName, subLastName). Without conditions in the joins, the cross-product will be a massive and rather meaningless one. Any other conditions or filters can be done during the query, and may not be required to semantically define a view. At least that is the case for how I intended to use it. > Control over "filter conditions" to avoid redundant filters I think is not a > critical thing, cause developer/designer can easily control that. And, by the > way, if not controlled, it doesn't cause an error. True. Putting <filter> tags in a single location in the <entity> element will make it easy enough to avoid duplicates. New suggestion. Include the conditionals in the <alias> element, attribute "value". Also, include your <filter> tag as a sub-element in the <alias-all> element. Still, your top-level <filter> element is most flexible, and easiest to implement. We can roll with that. I vote for it. This change is additive, and shouldn't affect existing functionalities.
          Hide
          Oscar Pablo added a comment -

          >> By using the tag <filter> to enter filter conditions, we are not binding the
          >> filtering to the join. That is, we can apply a filter even on a single table
          >> view.

          >Why would there be a single table view?

          You're right. I misunderstood the behaviour of this. Forget my comment. The idea behind all this is: if an entity is involved in more than one join, it could be confusing to place the filter inside "view-link", as it can be inside one link or the other. Also, it can be information on both links. Do we parse both filters? yes, but this increases the difficulty parsing the XML and decreases the understandability of the XML

          >> Using the filter tag inside or bound to the <view-link> tag makes the user
          >> define a view link to be able to define a filter.

          >The main motivation for my putting it in the <view-link> tag is this. I want cross-products that are semantically meaningful.

          >For eg, you may have a view that consists of "Person, Person's Employer, and Person's Subordinates". Note that the table Person is >joined 3 times. With conditions in the joins (<view-link>), it will be possible to have a cross-product like this:

          >Person (partyId, firstName, lastName), Person's Employer (empPartyId, empFirstName, empLastName), Person's Subordinate >(subPartyId, subFirstName, subLastName).

          >Without conditions in the joins, the cross-product will be a massive and rather meaningless one.

          >Any other conditions or filters can be done during the query, and may not be required to semantically define a view. At least that is >the case for how I intended to use it.

          The filter tag uses the entity-alias to solve this situation. Both things have the same effect (using "filter" tag or putting it inside "view-link" tab). It's just a matter of sepparating "responsibilities": one tag for joining and another for filtering. Also, the parsing is easier.

          >> Control over "filter conditions" to avoid redundant filters I think is not a
          >> critical thing, cause developer/designer can easily control that. And, by the
          >> way, if not controlled, it doesn't cause an error.

          >True. Putting <filter> tags in a single location in the <entity> element will make it easy enough to avoid duplicates.

          >New suggestion. Include the conditionals in the <alias> element, attribute "value".

          >Also, include your <filter> tag as a sub-element in the <alias-all> element.

          >Still, your top-level <filter> element is most flexible, and easiest to implement. We can roll with that. I vote for it.

          >This change is additive, and shouldn't affect existing functionalities.

          It seems we both agree in this point

          Show
          Oscar Pablo added a comment - >> By using the tag <filter> to enter filter conditions, we are not binding the >> filtering to the join. That is, we can apply a filter even on a single table >> view. >Why would there be a single table view? You're right. I misunderstood the behaviour of this. Forget my comment. The idea behind all this is: if an entity is involved in more than one join, it could be confusing to place the filter inside "view-link", as it can be inside one link or the other. Also, it can be information on both links. Do we parse both filters? yes, but this increases the difficulty parsing the XML and decreases the understandability of the XML >> Using the filter tag inside or bound to the <view-link> tag makes the user >> define a view link to be able to define a filter. >The main motivation for my putting it in the <view-link> tag is this. I want cross-products that are semantically meaningful. >For eg, you may have a view that consists of "Person, Person's Employer, and Person's Subordinates". Note that the table Person is >joined 3 times. With conditions in the joins (<view-link>), it will be possible to have a cross-product like this: >Person (partyId, firstName, lastName), Person's Employer (empPartyId, empFirstName, empLastName), Person's Subordinate >(subPartyId, subFirstName, subLastName). >Without conditions in the joins, the cross-product will be a massive and rather meaningless one. >Any other conditions or filters can be done during the query, and may not be required to semantically define a view. At least that is >the case for how I intended to use it. The filter tag uses the entity-alias to solve this situation. Both things have the same effect (using "filter" tag or putting it inside "view-link" tab). It's just a matter of sepparating "responsibilities": one tag for joining and another for filtering. Also, the parsing is easier. >> Control over "filter conditions" to avoid redundant filters I think is not a >> critical thing, cause developer/designer can easily control that. And, by the >> way, if not controlled, it doesn't cause an error. >True. Putting <filter> tags in a single location in the <entity> element will make it easy enough to avoid duplicates. >New suggestion. Include the conditionals in the <alias> element, attribute "value". >Also, include your <filter> tag as a sub-element in the <alias-all> element. >Still, your top-level <filter> element is most flexible, and easiest to implement. We can roll with that. I vote for it. >This change is additive, and shouldn't affect existing functionalities. It seems we both agree in this point
          Hide
          Jacques Le Roux added a comment -

          I like this idea, I hope to do a review soon (with OFBIZ-1252 also)

          Show
          Jacques Le Roux added a comment - I like this idea, I hope to do a review soon (with OFBIZ-1252 also)
          Hide
          Jacques Le Roux added a comment -

          An updated patch (merged by hand with TortoiseMerge help)

          Show
          Jacques Le Roux added a comment - An updated patch (merged by hand with TortoiseMerge help)
          Hide
          Jacques Le Roux added a comment -

          Better version with generic and fix a bug I introduced. If nobofy see a problem with this patch I will commit it

          Show
          Jacques Le Roux added a comment - Better version with generic and fix a bug I introduced. If nobofy see a problem with this patch I will commit it
          Hide
          Jacques Le Roux added a comment -

          Thanks Oscar and Jonathon for test and comments,

          A merged and modified patch is committed in trunk revision: 707216

          Show
          Jacques Le Roux added a comment - Thanks Oscar and Jonathon for test and comments, A merged and modified patch is committed in trunk revision: 707216
          Hide
          Jacques Le Roux added a comment -

          Finally on Adam and David's advices I have reverted in revision: 707830.

          To understand why please read this thread

          Show
          Jacques Le Roux added a comment - Finally on Adam and David's advices I have reverted in revision: 707830. To understand why please read this thread
          Hide
          Jacques Le Roux added a comment -

          Any news Adam ?

          Show
          Jacques Le Roux added a comment - Any news Adam ?

            People

            • Assignee:
              Adam Heath
              Reporter:
              Oscar Pablo
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development