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 |
Clarification:
you understand this is a view only. Not like the DB view where you can add data. 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 > > |
On Sat, Dec 13, 2008 at 11:50 PM, BJ Freeman <[hidden email]> 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 |
BTW It helps to keep the orginal message.
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 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 David Gay sent the following on 12/14/2008 10:24 AM: > On Sat, Dec 13, 2008 at 11:50 PM, BJ Freeman <[hidden email]> 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 > > |
Thank you for the replies, BJ. :-)
On Sun, Dec 14, 2008 at 3:54 PM, BJ Freeman <[hidden email]> 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 <[hidden email]> 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 |
David Gay wrote:
> 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). No, they wouldn't be better placed there. Keeping conditional logic out of the entity definition allows the entity to be used in other places - with other conditions. > 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. :-) The main argument against embedded SQL is that you lose platform independence. -Adrian |
In reply to this post by David Gay-2
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 <[hidden email]> 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 <[hidden email]> 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 > > |
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 <[hidden email]> 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 <[hidden email]> 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 >> > |
Free forum by Nabble | Edit this page |