OFBiz › OFBiz - User

EntityEngine: Conditional view-links in a view-entity

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

David Gay-2

EntityEngine: Conditional view-links in a view-entity

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

BJ Freeman

Re: EntityEngine: Conditional view-links in a view-entity

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

David Gay-2

Re: EntityEngine: Conditional view-links in a view-entity

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

BJ Freeman

Re: EntityEngine: Conditional view-links in a view-entity

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

David Gay-2

Re: EntityEngine: Conditional view-links in a view-entity

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:

Adrian Crum

Re: EntityEngine: Conditional view-links in a view-entity

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

BJ Freeman

Re: EntityEngine: Conditional view-links in a view-entity

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

BJ Freeman

Re: EntityEngine: Conditional view-links in a view-entity

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