ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathon -- Improov <j...@improov.com>
Subject Re: form widget question
Date Wed, 07 Feb 2007 00:29:44 GMT

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,
would do the form/screen widget method first, spot repeated processes as I go along, then
those into use cases (aka services). I can't stand sitting back for hours trying to foresee
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


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 <jonw@improov.com> 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 <snowch@coralms.com> 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 ...

View raw message