There are a few thing in place to do conditions and sort order and such on view-entities, but nothing to do unions.
-David On Mar 23, 2010, at 5:58 AM, Harmeet Bedi wrote: > I believe David jones had looked at various view enhancements we had done > mid-last year and had a way of extending entity model to handle all kinds of > extensions we did. Not sure what the extensions were, but maybe David > remembers. > > Harmeet > > On 20/03/10 2:39 AM, Adam Heath wrote: >> Bob Morley wrote: >>> Do you have a bug in our office? I happen to be working on this very thing >>> today. A number of months ago a developer here had added this support to >>> the entity model. In affect, you could union two entities together -- the >>> issues we had today were around proper typing in the model (it needed to >>> derive its type based on its union members). Here is a snippet from one of >>> ours ... >>> >>> <union-view-entity entity-name="PhoneAddressContactView" >>> package-name="com.emforium.ofbiz" title="all contacts"> >>> <member-entity entity-alias="phone" entity-name="PartyPhoneView" /> >>> <member-entity entity-alias="address" entity-name="PartyAddressView" >>> /> >>> >>> <union-field name="partyId"> >>> <union-member-field entity-alias="phone" name="partyId"/> >>> <union-member-field entity-alias="address" name="partyId"/> >>> </union-field> >>> <union-field name="contactMechId"> >>> <union-member-field entity-alias="phone" name="contactMechId"/> >>> <union-member-field entity-alias="address" >>> name="contactMechId"/> >>> </union-field> >>> <union-field name="contactMechPurposeTypeId"> >>> <union-member-field entity-alias="phone" >>> name="contactMechPurposeTypeId"/> >>> <union-member-field entity-alias="address" >>> name="contactMechPurposeTypeId"/> >>> </union-field> >>> </union-view-entity> >>> >>> We do not have an equivalent to "alias-all" here, we have to be explicit >>> about the fields we want to expose by our union entity. What happens at >>> load and basic populate time, a ModelViewEntity is constructed (there is a >>> union flag on it) with the appropriate set of aliases. >>> >>> What you do not see here is that we have added support to be able to create >>> view-entities based on other view-entities and we support a >>> complex-alias-constant that can be used as "filler columns" when your two >>> unioned entities do not match up exactly. >>> >>> If there is interest we fit our support into Ofbiz trunk and provide a >>> patch. >> >> File jira, I could then put this in a branch, and we might need do >> some tweaking before it hits trunk. >> >> You may want to reuse the<field-map> stuff. >> >> The<member-entity> here should have a feature to add new conditions. >
