form widget question

[snowch]

I have a field that is returned in a form list:

<field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
   <display-entity entity-name="Party" key-field-name="partyId"/>
</field>

I would like to display "Party.lastName, Party.firstName" and not the
partyId.  

How can I do this?

Many thanks ...

[cjhowe]

In your row actions, run the service getPartyNameForDate, passing in
the partyId and optional Y/N for lastNameFirst variable and optional
compareDate
--- Christopher Snow <[hidden email]> wrote:

> I have a field that is returned in a form list:
>
> <field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
>    <display-entity entity-name="Party" key-field-name="partyId"/>
> </field>
>
> I would like to display "Party.lastName, Party.firstName" and not the
> partyId.  
>
> How can I do this?
>
> Many thanks ...
>

[snowch]

Thanks again Chris!

On Tue, 2007-02-06 at 08:50 -0800, Chris Howe wrote:

> In your row actions, run the service getPartyNameForDate, passing in
> the partyId and optional Y/N for lastNameFirst variable and optional
> compareDate
> --- Christopher Snow <[hidden email]> wrote:
>
> > I have a field that is returned in a form list:
> >
> > <field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
> >    <display-entity entity-name="Party" key-field-name="partyId"/>
> > </field>
> >
> > I would like to display "Party.lastName, Party.firstName" and not the
> > partyId.  
> >
> > How can I do this?
> >
> > Many thanks ...
> >
>
>

[jonwimp]

Christopher,

There's another way to do this, without using services. I usually try not to add new services if I
can avoid it, don't want my customization to contain 100s of custom services. See the below
example if you have other cases for which you cannot easily find a suitable service to do similar
pre-processing.

It might sometimes seem like an overkill to create a new service to do something as simple as
putting first name and last name together. Or you might want a different formatting like
"<firstName> - <lastName>" and you find getPartyNameForDate not flexible enough.

The following example will remove the need for a separate service altogether, so we don't pollute
the services namespace with zillions of services. Ok, here goes.

You can usually pull in entity rows using <entity-one> (or <entity-and>).

In your <actions> section, you'll usually have to trace from a key you get in request parameters
linking all the way somehow to entity Party via primary key partyId. That's the case for the
example below. Of course, you could be dealing with entity Party as a top-level entity, in which
case you can possibly omit the 1st 3 lines.

You might see something like this:

<set field="someOtherEntityId" from-field="parameters.someOtherEntityId"/>
<entity-one entity-name="SomeOtherEntity" value-name="someVariable"/>
<set field="partyId" from-field="someVariable.someSpecialPartyId"/>
<entity-one entity-name="Party" value-name="riskOwnerParty"/>

(The 1st 2 lines may reside in a screen-widget instead, but the effect is the same; both the
screen-widget and related form-widget will operate on the same context. Line 3 shows a foreign key
linkage from entity SomeOtherEntity to entity Party. Line 1 can actually be omitted in this
example, but I was afraid you'd wonder "where is the primary key for SomeOtherEntity!". Yeah, a
lot of "behind the scenes" issues in OFBiz framework.)

And outside (below, actually) your <actions> section, do:

<field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
     <display description="${riskOwnerParty.lastName}, ${riskOwnerParty.firstName}"/>
</field>

(The context variable ${riskOwnerPary} is a map, a list of values for the single row pulled in
from entity Party.)

That way, you won't have to hunt for hundreds of available services that precisely serves your
thousands of specific needs. And you just need a few lines (3-5) of XML codes.

That said, you should use all available services whenever possible.

Interesting note: You'll realize the above example is very similar to your typical programming
styles -- get entity1, link to entity2, use entity2 key to pull down list from entity3, etc. You
did ask about "flow of variables" (like in a typical programming construct), so the above should
look very familiar to you. Oh, before I forget, variables are stored in context, so store and find
them there, simple as that.

About the intricacies of the combination "<field><display-entity/></field>", let me know if you
want a detailed explanation of that.

If you're thinking it's easy to have bad/sub-optimal coding practices in OFBiz, you'd be right.
Even the above example may not be the best way to go about things. When in doubt, ask David E.
Jones (back to the source), that's what I'd do.

Can you help to write down what you learned in some comprehensive technical reference somewhere?
Thanks. :) I still need to train my boss' staff at some point, and you could really help me a lot
here.

Jonathon

Chris Howe wrote:

> In your row actions, run the service getPartyNameForDate, passing in
> the partyId and optional Y/N for lastNameFirst variable and optional
> compareDate
> --- Christopher Snow <[hidden email]> wrote:
>
>> I have a field that is returned in a form list:
>>
>> <field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
>>    <display-entity entity-name="Party" key-field-name="partyId"/>
>> </field>
>>
>> I would like to display "Party.lastName, Party.firstName" and not the
>> partyId.  
>>
>> How can I do this?
>>
>> Many thanks ...
>>
>
>

[cjhowe]

While, I'd certainly agree that there are more ways of killing a cat
than simply choking it with cream in OFBiz, I would suggest using OFBiz
services when they accomplish your goal because they generally account
for more use cases than you could do easily when using multiple
<entity-and> calls. The more use cases your data gathering considers,
generally, the more reusable your form is.

Granted, you need to know that the services exists first.  The service
reference in webtools is a particularly good place to find out about
them.

For this one in particular, getPartyNameForDate will return a name in
the same key of the map regardless of whether it's a person or a party
group; a use case that's rather tedious to accomplish using entity*
calls.


--- Jonathon -- Improov <[hidden email]> wrote:

> Christopher,
>
> There's another way to do this, without using services. I usually try
> not to add new services if I
> can avoid it, don't want my customization to contain 100s of custom
> services. See the below
> example if you have other cases for which you cannot easily find a
> suitable service to do similar
> pre-processing.
>
> It might sometimes seem like an overkill to create a new service to
> do something as simple as
> putting first name and last name together. Or you might want a
> different formatting like
> "<firstName> - <lastName>" and you find getPartyNameForDate not
> flexible enough.
>
> The following example will remove the need for a separate service
> altogether, so we don't pollute
> the services namespace with zillions of services. Ok, here goes.
>
> You can usually pull in entity rows using <entity-one> (or
> <entity-and>).
>
> In your <actions> section, you'll usually have to trace from a key
> you get in request parameters
> linking all the way somehow to entity Party via primary key partyId.
> That's the case for the
> example below. Of course, you could be dealing with entity Party as a
> top-level entity, in which
> case you can possibly omit the 1st 3 lines.
>
> You might see something like this:
>
> <set field="someOtherEntityId"
> from-field="parameters.someOtherEntityId"/>
> <entity-one entity-name="SomeOtherEntity" value-name="someVariable"/>
> <set field="partyId" from-field="someVariable.someSpecialPartyId"/>
> <entity-one entity-name="Party" value-name="riskOwnerParty"/>
>
> (The 1st 2 lines may reside in a screen-widget instead, but the
> effect is the same; both the
> screen-widget and related form-widget will operate on the same
> context. Line 3 shows a foreign key
> linkage from entity SomeOtherEntity to entity Party. Line 1 can
> actually be omitted in this
> example, but I was afraid you'd wonder "where is the primary key for
> SomeOtherEntity!". Yeah, a
> lot of "behind the scenes" issues in OFBiz framework.)
>
> And outside (below, actually) your <actions> section, do:
>
> <field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
>      <display description="${riskOwnerParty.lastName},
> ${riskOwnerParty.firstName}"/>
> </field>
>
> (The context variable ${riskOwnerPary} is a map, a list of values for
> the single row pulled in
> from entity Party.)
>
> That way, you won't have to hunt for hundreds of available services
> that precisely serves your
> thousands of specific needs. And you just need a few lines (3-5) of
> XML codes.
>
> That said, you should use all available services whenever possible.
>
> Interesting note: You'll realize the above example is very similar to
> your typical programming
> styles -- get entity1, link to entity2, use entity2 key to pull down
> list from entity3, etc. You
> did ask about "flow of variables" (like in a typical programming
> construct), so the above should
> look very familiar to you. Oh, before I forget, variables are stored
> in context, so store and find
> them there, simple as that.
>
> About the intricacies of the combination
> "<field><display-entity/></field>", let me know if you
> want a detailed explanation of that.
>
> If you're thinking it's easy to have bad/sub-optimal coding practices
> in OFBiz, you'd be right.
> Even the above example may not be the best way to go about things.
> When in doubt, ask David E.
> Jones (back to the source), that's what I'd do.
>
> Can you help to write down what you learned in some comprehensive
> technical reference somewhere?
> Thanks. :) I still need to train my boss' staff at some point, and
> you could really help me a lot
> here.
>
> Jonathon
>
> Chris Howe wrote:
> > In your row actions, run the service getPartyNameForDate, passing
> in
> > the partyId and optional Y/N for lastNameFirst variable and
> optional
> > compareDate
> > --- Christopher Snow <[hidden email]> wrote:
> >
> >> I have a field that is returned in a form list:
> >>
> >> <field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
> >>    <display-entity entity-name="Party" key-field-name="partyId"/>
> >> </field>
> >>
> >> I would like to display "Party.lastName, Party.firstName" and not
> the
> >> partyId.  
> >>
> >> How can I do this?
> >>
> >> Many thanks ...
> >>
> >
> >
>
>

[jonwimp]

Christopher,

Chris is right (see his response below).

You can still do very trivial formatting with the example I described, but you should abstract
repeated processes into integral use cases.

Personally, being lazy and too used to the "quick and dirty, get it up and running" approach, I
would do the form/screen widget method first, spot repeated processes as I go along, then abstract
those into use cases (aka services). I can't stand sitting back for hours trying to foresee what
services or use cases I might need. :P

Just don't do services for really trivial stuff that you won't repeat elsewhere in the
application, or you'll end up with zillions of services. Esp don't do services for trivial
lookups; updates will need services more since they're not as varied/variable as lookups and views.

Jonathon

Chris Howe wrote:

> While, I'd certainly agree that there are more ways of killing a cat
> than simply choking it with cream in OFBiz, I would suggest using OFBiz
> services when they accomplish your goal because they generally account
> for more use cases than you could do easily when using multiple
> <entity-and> calls. The more use cases your data gathering considers,
> generally, the more reusable your form is.
>
> Granted, you need to know that the services exists first.  The service
> reference in webtools is a particularly good place to find out about
> them.
>
> For this one in particular, getPartyNameForDate will return a name in
> the same key of the map regardless of whether it's a person or a party
> group; a use case that's rather tedious to accomplish using entity*
> calls.
>
>
> --- Jonathon -- Improov <[hidden email]> wrote:
>
>> Christopher,
>>
>> There's another way to do this, without using services. I usually try
>> not to add new services if I
>> can avoid it, don't want my customization to contain 100s of custom
>> services. See the below
>> example if you have other cases for which you cannot easily find a
>> suitable service to do similar
>> pre-processing.
>>
>> It might sometimes seem like an overkill to create a new service to
>> do something as simple as
>> putting first name and last name together. Or you might want a
>> different formatting like
>> "<firstName> - <lastName>" and you find getPartyNameForDate not
>> flexible enough.
>>
>> The following example will remove the need for a separate service
>> altogether, so we don't pollute
>> the services namespace with zillions of services. Ok, here goes.
>>
>> You can usually pull in entity rows using <entity-one> (or
>> <entity-and>).
>>
>> In your <actions> section, you'll usually have to trace from a key
>> you get in request parameters
>> linking all the way somehow to entity Party via primary key partyId.
>> That's the case for the
>> example below. Of course, you could be dealing with entity Party as a
>> top-level entity, in which
>> case you can possibly omit the 1st 3 lines.
>>
>> You might see something like this:
>>
>> <set field="someOtherEntityId"
>> from-field="parameters.someOtherEntityId"/>
>> <entity-one entity-name="SomeOtherEntity" value-name="someVariable"/>
>> <set field="partyId" from-field="someVariable.someSpecialPartyId"/>
>> <entity-one entity-name="Party" value-name="riskOwnerParty"/>
>>
>> (The 1st 2 lines may reside in a screen-widget instead, but the
>> effect is the same; both the
>> screen-widget and related form-widget will operate on the same
>> context. Line 3 shows a foreign key
>> linkage from entity SomeOtherEntity to entity Party. Line 1 can
>> actually be omitted in this
>> example, but I was afraid you'd wonder "where is the primary key for
>> SomeOtherEntity!". Yeah, a
>> lot of "behind the scenes" issues in OFBiz framework.)
>>
>> And outside (below, actually) your <actions> section, do:
>>
>> <field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
>>      <display description="${riskOwnerParty.lastName},
>> ${riskOwnerParty.firstName}"/>
>> </field>
>>
>> (The context variable ${riskOwnerPary} is a map, a list of values for
>> the single row pulled in
>> from entity Party.)
>>
>> That way, you won't have to hunt for hundreds of available services
>> that precisely serves your
>> thousands of specific needs. And you just need a few lines (3-5) of
>> XML codes.
>>
>> That said, you should use all available services whenever possible.
>>
>> Interesting note: You'll realize the above example is very similar to
>> your typical programming
>> styles -- get entity1, link to entity2, use entity2 key to pull down
>> list from entity3, etc. You
>> did ask about "flow of variables" (like in a typical programming
>> construct), so the above should
>> look very familiar to you. Oh, before I forget, variables are stored
>> in context, so store and find
>> them there, simple as that.
>>
>> About the intricacies of the combination
>> "<field><display-entity/></field>", let me know if you
>> want a detailed explanation of that.
>>
>> If you're thinking it's easy to have bad/sub-optimal coding practices
>> in OFBiz, you'd be right.
>> Even the above example may not be the best way to go about things.
>> When in doubt, ask David E.
>> Jones (back to the source), that's what I'd do.
>>
>> Can you help to write down what you learned in some comprehensive
>> technical reference somewhere?
>> Thanks. :) I still need to train my boss' staff at some point, and
>> you could really help me a lot
>> here.
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> In your row actions, run the service getPartyNameForDate, passing
>> in
>>> the partyId and optional Y/N for lastNameFirst variable and
>> optional
>>> compareDate
>>> --- Christopher Snow <[hidden email]> wrote:
>>>
>>>> I have a field that is returned in a form list:
>>>>
>>>> <field name="riskOwnerPartyId" title="${uiLabelMap.Owner}">
>>>>    <display-entity entity-name="Party" key-field-name="partyId"/>
>>>> </field>
>>>>
>>>> I would like to display "Party.lastName, Party.firstName" and not
>> the
>>>> partyId.  
>>>>
>>>> How can I do this?
>>>>
>>>> Many thanks ...
>>>>
>>>
>>
>
>

[David E Jones]

On Feb 6, 2007, at 5:29 PM, Jonathon -- Improov wrote:

> Personally, being lazy and too used to the "quick and dirty, get it  
> up and running" approach, I would do the form/screen widget method  
> first, spot repeated processes as I go along, then abstract those  
> into use cases (aka services). I can't stand sitting back for hours  
> trying to foresee what services or use cases I might need. :P

This is a powerful and important concept... very in-line with agile  
processes that consistently lead to good results.

> Just don't do services for really trivial stuff that you won't  
> repeat elsewhere in the application, or you'll end up with zillions  
> of services. Esp don't do services for trivial lookups; updates  
> will need services more since they're not as varied/variable as  
> lookups and views.

This is a good point to. Using services, especially for complex or  
commonly used stuff that can be parameterized effectively, is a good  
idea but what you describe here Jonathon is exactly why the entity-*  
and other such operations exist in screen widget actions.

-David