>> 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
>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