forgot View Links View links are used to specify the links between the member-entities of the view. They link one entity-alias to another and use key-maps just like relations. Here the field-name specifies the name of the field on the aliased entity and the rel-field-name the field on the related aliased entity. As with many other things, the rel-field-name is optional if it is the same as the field-name.
To represent an outer join you can specify in a view-link element that the related entity is optional using the rel-optional attribute, which can be either "true" or "false", and of course defaults to "false". The Entity Engine will generate ANSI, Oracle Theta, or MS SQL Server Theta style join code depending on the setting in the entityengine.xml file. See the Entity Engine Configuration Guide for more information. BJ Freeman sent the following on 12/17/2008 11:41 AM: > short answer is it is not best practices. > it would not be accepted into the trunk. > there is a standard approach I outlined that is the best practices. > there is nothing to prevent you from implementing your approach and > maintain it locally. > > Our questions are: > - Have we missed some already-available functionality (at the > entitymodel.xml level)? > No > - Is there a best-practice for this situation, or is it more of a > "this is just what people are doing" thing? > http://ofbiz.apache.org/docs/entity.html > - Are there arguments _against_ either of the above extensions? > [entity consists of a set of fields and a set of relationships to other > entities.] > > > David Gay sent the following on 12/17/2008 11:27 AM: >> Thank you for the replies, BJ. :-) >> >> On Sun, Dec 14, 2008 at 3:54 PM, BJ Freeman <[email protected]> wrote: >>> BTW It helps to keep the orginal message. >> I've included it, below. >> >>> 1) create a view-entity >>> 2) query the view-entity just like any other. >>> there are a couple of ways you will find in the code. >>> 3) Use an Ftl to create the XML output the way you want. >>> look at the fedex template >> Yes, we've done these steps ... no problems there. >> >>> Now >>> the url you give to an external source to query for the xml >>> would go to a service thru the controller to process the request. >>> on the return through the controller your view would then present the >>> data thru the ftl(xml format). >>> you can wrap the ftl in a widget if you want to add more functionality. >>> There are examples in the code for all of this if you study it. >>> studing this helps >>> http://docs.ofbiz.org/display/OFBIZ/OFBiz+Beginner's+Development+Guide+Using+Practice+Application >> Thank you for the description. We've been studying that, the Data >> Model book, the Apache OFBiz Development book, the source code, and so >> on.... :-] >> >> The standard approach seems to be putting the conditional/constraint >> logic in each usage point (form/screen level). My programmer's >> understanding suggests that these constraints would be better located >> in the view-entity's declaration (since they never change and can be >> localized in one place). >> >> In any case, one of our team has created a good-enough-for-us solution >> by relaxing a constraint in the sources and using embedded SQL. This >> is not pretty, but allows us to do the following: >> >> [view-entity entity-name="ProductFindViewEntity" >> package-name="emforium.inventory" title="Product-Find View Entity"] >> [member-entity entity-alias="PR" entity-name="Product" /] >> [alias entity-alias="PR" name="productId" /] >> [alias entity-alias="PR" name="internalName" /] >> [alias entity-alias="PR" name="sku"] >> [complex-alias operator="=" ] >> [complex-alias-field entity-alias="PR" field="SELECT id_value >> FROM good_identification WHERE good_identification_type_id = 'SKU' AND >> product_id" /] >> [complex-alias-field entity-alias="PR" field="productId" /] >> [/complex-alias] >> [/alias] >> [alias entity-alias="PR" name="style"] >> [complex-alias operator="=" ] >> [complex-alias-field entity-alias="PR" field="SELECT id_value >> FROM good_identification WHERE good_identification_type_id = >> 'MANUFACTURER_ID_NO' AND product_id" /] >> [complex-alias-field entity-alias="PR" field="productId" /] >> [/complex-alias] >> [/alias] >> [view-entity] >> >> As stated earlier, however, we'd prefer to do something like this >> (note the two [where ...] lines): >> >> [view-entity entity-name="ProductFindViewEntity" >> package-name="emforium.inventory" title="Product-Find View Entity"] >> [member-entity entity-alias="PR" entity-name="Product" /] >> [member-entity entity-alias="SKU" entity-name="GoodIdentification" /] >> [member-entity entity-alias="MID" entity-name="GoodIdentification" /] >> [alias entity-alias="PR" name="productId" /] >> [alias entity-alias="PR" name="internalName" /] >> [alias entity-alias="SKU" name="sku" field="idValue" /] >> [view-link entity-alias="PR" rel-entity-alias="SKU" rel-optional="true"] >> [key-map field-name="productId" /] >> [where entity-alias="SKU" field="goodIdentificationTypeId" value="SKU" /] >> [/view-link] >> [view-link entity-alias="PR" rel-entity-alias="MID" rel-optional="true"] >> [key-map field-name="productId" /] >> [where entity-alias="MID" field="goodIdentificationTypeId" >> value="MANUFACTURER_ID_NO" /] >> [/view-link] >> [view-entity] >> >> Our questions are: >> - Have we missed some already-available functionality (at the >> entitymodel.xml level)? >> - Is there a best-practice for this situation, or is it more of a >> "this is just what people are doing" thing? >> - Are there arguments _against_ either of the above extensions? >> >> We really want to do the right thing with this. :-) >> >> Thanks for your patience! >> >> .Dave >> >> >> >>> David Gay sent the following on 12/14/2008 10:24 AM: >>>> On Sat, Dec 13, 2008 at 11:50 PM, BJ Freeman <[email protected]> wrote: >>>>> Clarification: >>>>> you understand this is a view only. >>>>> Not like the DB view where you can add data. >>>> Yes, that's fine: the use case is feeding (paginated) search results >>>> through an XML-based form. (An easy alternative to this approach is >>>> to use row-actions to gather the required fields, but I wanted to >>>> avoid hitting the database on a per-row basis.) >>>> >>>> .Dave >> >> David Gay sent the following on 12/12/2008 9:05 AM: >>> Hi, all! I've been looking into using view-entity entries to (in this >>> instance) collect product information, and have some questions about >>> "static conditionals". But first, some context for discussion >>> purposes. ;-) >>> >>> Let's say I'd like to have a Product view that includes the product's >>> SKU as a column. Here's a sample entitydef.xml (angle-brackets >>> converted to square-brackets): >>> >>> [view-entity entity-name="ProductFindViewEntity" >>> package-name="com.emforium.inventory" title="Product-Find View >>> Entity"] >>> [member-entity entity-alias="PR" entity-name="Product" /] >>> [member-entity entity-alias="SKU" entity-name="GoodIdentification" /] >>> [alias entity-alias="PR" name="productId" /] >>> [alias entity-alias="SKU" name="sku" field="idValue" /] >>> [alias entity-alias="SKU" name="skuTypeId" >>> field="goodIdentificationTypeId" /] >>> [view-link entity-alias="PR" rel-entity-alias="SKU" rel-optional="true"] >>> [key-map field-name="productId" /] >>> [/view-link] >>> [/view-entity] >>> >>> Let's say I've also added two GoodIdentification rows for a product: >>> >>> [GoodIdentification productId="ENCHILADAS" >>> goodIdentificationTypeId="SKU" idValue="ENCH-SKU" /] >>> [GoodIdentification productId="ENCHILADAS" >>> goodIdentificationTypeId="MANUFACTURER_ID_NO" idValue="123-ENCH-456" >>> /] >>> >>> Now, a query for productId="ENCHILADAS" on this entity will yield two rows: >>> >>> productId="ENCHILADAS", sku="ENCH-SKU", skuTypeId="SKU" >>> productId="ENCHILADAS", sku="123-ENCH-456", skuTypeId="MANUFACTURER_ID_NO" >>> >>> Obviously, I need a conditional (e.g. skuTypeId="SKU" OR >>> skuTypeId=NULL), which I can do easily enough each place I do the >>> query, but I'd prefer to add that to the entitydef.xml file, since >>> it's the same in all cases (and avoids messy null-logic, etcetera). >>> Perhaps something like this: >>> >>> ... >>> [view-link entity-alias="PR" rel-entity-alias="SKU" rel-optional="true"] >>> [key-map field-name="productId" /] >>> [where entity-alias="SKU" field="goodIdentificationTypeId" >>> value="SKU" /] >>> [/view-link] >>> ... >>> >>> So, my questions: Have I missed some already-available functionality? >>> Is there a best-practice for this situation? Has anyone else >>> encountered this issue, and if so, how did you solve it? Are there >>> arguments against this sort of extension? >>> >>> Thanks in advance, >>> .Dave >> >
