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