Re: how about adding a paymentMethodName to PaymentMethod?

Posted by cjhowe on Jun 29, 2006; 2:14am
URL: http://ofbiz.116.s1.nabble.com/how-about-adding-a-paymentMethodName-to-PaymentMethod-tp169026p169033.html

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
> >>>>>>
> >>>>
> >>>
> >>
>
>