ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Howe <cjhowe76...@yahoo.com>
Subject Re: form widget question
Date Wed, 07 Feb 2007 00:01:42 GMT
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 ...
> >>
> > 
> > 
> 
> 


Mime
View raw message