[
https://issues.apache.org/jira/browse/OFBIZ-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527002
]
Oscar Pablo commented on OFBIZ-1232:
------------------------------------
>> 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 :)
> Data filtering in entity views
> ------------------------------
>
> Key: OFBIZ-1232
> URL: https://issues.apache.org/jira/browse/OFBIZ-1232
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Oscar Pablo
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: filter_views.diff
>
>
> 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...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
