http://ofbiz.116.s1.nabble.com/how-about-adding-a-paymentMethodName-to-PaymentMethod-tp169026p169034.html
If each type of PaymentMethod might have a description on it (ie CreditCard, EftAccount, etc), then why not put if on the PaymentMethod entity? In fact, I think it's somewhat silly not to...
> Re first comment:
>
> If a paymentMethod requires no additional entity what
> is the name doing for you that the type isn't?
>
> Re second comment (but there is no description on...):
>
> I'm saying that there should be a
> CreditCard.description, et al but not a
> PaymentMethod.description.
>
> Re third comment (if i have to .getRelated it's a
> mess):
>
> And if i'm only working with credit cards, I have to
> .getRelated back to the PaymentMethod. Isn't that the
> same mess? There's no benefit except for this
> specific application. You're sacrificing
> normalization in the data model for coding ease that
> doesn't run both ways.
>
> Placing the description in the PaymentMethod for what
> you're wanting to accomplish creates an inconsistant
> dependency.
>
>
> --- Si Chen <
[hidden email]> wrote:
>
>> On Jun 28, 2006, at 4:21 PM, Chris Howe wrote:
>>
>>> Let me explain it differently. The PaymentMethod
>>> entity is an entity of convenience, not an entity
>> that
>>> describes anything.
>> No, it's an entity that describes a payment method.
>> There are some
>> payment methods which have additional information
>> specific to them,
>> but then again there may be some other payment
>> methods which don't
>> require additional entities.
>>> So now we add description. But, there's already a
>>> description (firstName, lastName) for Person and a
>>> description (groupName) for Corporation. This is
>>> information that is likely to change and we will
>> need
>>> to keep track of it in multiple locations when it
>> is
>>> unneccesary.
>>>
>> But there is no description on CreditCard,
>> EftAccount, nor is there
>> an equivalent field. So this is not the case right?
>>> So, there's no benefit of adding the description,
>> but
>>> you've added the possibility of the nonnormalized
>> data
>>> to be inconsistant. Does that make a good data
>> model?
>>
>> Actually there's a real benefit. If I just want to
>> get the
>> description of a PaymentMethod and it's on the
>> PaymentMethod, it's
>> very easy. If I have to .getRelated based on the
>> type of the
>> PaymentMethod to another entity, it's a mess.
>>
>>>
>>>
>>> --- David E Jones <
[hidden email]> wrote:
>>>
>>>> Huh?
>>>>
>>>> Chris Howe wrote:
>>>>> It may apply to all payment methods (I'm not
>>>> really
>>>>> sure that it applies to all current payment
>>>> methods,
>>>>> much less ALL that may exist), but it does not
>>>>> describe the payment method. It describes the
>>>> payment
>>>>> method's child so it should go in the entity
>> that
>>>> it
>>>>> is describing.
>>>>>
>>>>> Following through with the approach of putting
>> the
>>>>> field in PaymentMethod entity puts you in the
>>>> position
>>>>> of modifying the data to fit the data model
>>>> instead of
>>>>> keeping the data model flexible enough to fit
>> the
>>>>> data.
>>>>>
>>>>> --- Si Chen <
[hidden email]>
>>>> wrote:
>>>>>> I disagree. This is a descriptive note that
>>>> applies
>>>>>> to all
>>>>>> PaymentMethods so why put it in the child
>>>> entities.
>>>>>> If you had a
>>>>>> parent class which had a field that all
>> inherited
>>>>>> classes should
>>>>>> have, shouldn't be in the parent class?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jun 28, 2006, at 1:35 PM, Chris Howe wrote:
>>>>>>
>>>>>>> "Bank A general account" does not describe the
>>>>>>> PaymentMethod, it describes the credit card,
>> the
>>>>>>> company account, the gift card, etc so that
>>>> field
>>>>>>> should go on the CreditCard, etc entity. Now
>> if
>>>>>>> you're using it as an alias for the Payment
>>>>>> Method,
>>>>>>> then you should create a
>> PaymentMethodAttribute
>>>>>> entity
>>>>>>> and make a relationship between the two.
>>>>>>>
>>>>>>>
>>>>>>> On a side note. I've noticed a couple of
>> fields
>>>>>>> getting added onto entities in svn that are
>>>> quick
>>>>>>> fixes to gain functionality but cause a loss
>> of
>>>>>> the
>>>>>>> entity's meaning. PaymentMethod.partyId is
>> one
>>>>>> that
>>>>>>> quickly comes to mind.
>>>>>>>
>>>>>>> --- Si Chen <
[hidden email]>
>>>>>> wrote:
>>>>>>>> Hi everybody.
>>>>>>>>
>>>>>>>> What do you think of adding a field
>>>>>>>> "paymentMethodName" to
>>>>>>>> PaymentMethod, so a company can identify that
>>>>>> method
>>>>>>>> A is "Bank A
>>>>>>>> general account", etc. etc.
>>>>>>>>
>>>>>>>> Si
>>>>>>>>
>>
>