We had a similar problem with getting a consistent name across the party
inheritence model. The approach we are in the process of taking is to
enhance the PartyNameView (or provide a new one) to support a complex-alias
that can be a coalesce of the various components in combination with using a
static method to consistently format the name.
The first part is important because (at least in our appliation) it is a
requirement to sort parties in a list properly by name (as well as filtering
on those values). As a result, it is nearly manditory to produce a field
for these operations at the database level. Typically you do not want to
have your database dictate formatting, so we leave that for the method that
can be configured.
The rub here is that for sorting / filtering we have to be fairly close to
the resulting format. If you format "Last, First" (for a person) then the
database field needs to combine in that order but not necessarily with
equivalent seperators.
.B
Malin Nicolas wrote:
>
> Hi Hans, Hi David,
>
> I understand that there is a potential redundant problem that this
> solution generate. In Neogia project, we have created a new field called
> partyType when we have a new party with functional particularity (as a
> Company). In OFBiz I looked that you added PartyType with the parentType
> INFORMAL_TYPE but I don't understand how you manage specific fields. The
> point is that when you are using a partyType, the specific fields to
> this type are not managed. For example, if I am adding a party, with its
> partyType to FARMER, how will I put the specific fields related to it
> (tractor number, sheep type, ..., it's an example ;) ) ?
> The partyName field is created to make easier the screen creation
> otherwise for all forms if we used PartyNameView, all forms that use
> this must be changed and the field is too long : ${firstName}
> ${lastName} ${groupName} ${corporateName} ${farmerGreateName}
> ${anOtherPartyTypeName} ...
>
> If we have a different PartyType managment, the partyName field have not
> consistence on OFBiz project. I have create the addons for interested
> person, it's available on http://addons.neogia.org/addons/party-name/.
> If you need more explanations on how using it, don't hesitate to ask on
> the mailing list.
>
> Thx
>
> Nicolas
>
> David E Jones wrote:
>>
>> I agree with where you're going here Hans. The main reason for
>> redundant/derived fields in the database is to make things perform
>> adequately at run time. I'm not sure saving a little bit of code here
>> and there is a good enough reason to have to deal with the inevitable
>> inconsistency that comes from redundancy.
>>
>> -David
>>
>>
>> On Aug 14, 2009, at 5:02 PM, Hans Bakker wrote:
>>
>>> Did you have a look at the PartyNameView entity? there you can list the
>>> name and it does not matter if come from partyGroup or person:
>>>
>>> ${firstName} ${lastName} ${groupname}
>>>
>>> Then the name will always show.....
>>>
>>> so it is really required to add a field which duplicates information?
>>>
>>> Regards,
>>> Hans
>>>
>>> On Fri, 2009-08-14 at 15:16 +0200, Nicolas wrote:
>>>> Hello,
>>>>
>>>> Actually, I work on Party component to import Neogia functionality on
>>>> OFBiz trunk. I create some addons use by the Neogia that apply on
>>>> OFBiz
>>>> trunk with addon-manager and I submit to you the functionality.
>>>>
>>>
>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>
>>
>>
>
>
>
--
View this message in context:
http://www.nabble.com/Add-field-partyName-on-entity-Party-tp24971575p25018355.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
