Generic Roles in Shopping Cart
Locked
Generic Roles in Shopping Cart
 
|
Re: Generic Roles in Shopping Cart
|
|
Re: Generic Roles in Shopping Cart
|
|
Re: Generic Roles in Shopping Cart
|
|
Sounds like it's a custom requirement (not really a general/generic requirement), so custom code would be the way to go. You should be able to write a custom event that enacts this constraint and not modify any of the main OFBiz code. -David On Dec 14, 2007, at 11:09 AM, Chris Howe wrote: > I'm needing to add an OrderRole to an order, but the role is > determined while the individual is shopping before an orderId is > known. Very similar to the ten other roles that are added the same > way (supplierAgentPartyId, shipFromVendorPartyId, > billFromVendorPartyId, etc). There's no need to add another > variable and 3 additional methods to access that variable, when a > generic HashMap(String, String) will handle an unlimited number of > roles. > > ----- Original Message ---- > From: Jim Barrows <[hidden email]> > To: [hidden email] > Sent: Friday, December 14, 2007 11:57:38 AM > Subject: Re: Generic Roles in Shopping Cart > > > I'm wondering why you want to do that? Are you trying to tie a > shopping cart to an individual user? > > On Dec 14, 2007 10:41 AM, Chris Howe <[hidden email]> wrote: >> I'm needing to restrict a custom roleTypeId to 1 per shopping cart, > currently the only way to add a custom roleTypeId is through the > addAdditionalRole, which will accept many parties per roleTypeId. I > can > accomplish limiting the roleTypeId to one party only by removing all > parties from the addAdditionalRole.roleTypeId before adding the > limiting > role, but it's not fail safe. >> >> ----- Original Message ---- >> From: Jim Barrows <[hidden email]> >> To: [hidden email] >> Sent: Friday, December 14, 2007 11:35:31 AM >> Subject: Re: Generic Roles in Shopping Cart >> >> >> What problem are you trying to solve? >> >> On Dec 14, 2007 10:19 AM, Chris Howe <[hidden email]> wrote: >>> I'm needing to restrict a custom roleTypeId to 1 per shopping cart >> and I'm not finding a way to do that. Would there be any objection > to >> changing the way the roles are handled in the shopping cart? I > would like >> to change all of the roles that should be restricted to 1 per > shopping >> cart from specified variables to a HashMap(String roletypeId, String >> partyId) in contrast to the additionalPartyRole of HashMap(String >> roleTypeId, List(String partyId)). >>> >>> >>> >> >> >> >> -- >> James A Barrows >> >> >> >> > > > > -- > James A Barrows > > > |
smime.p7s (3K)
Re: Generic Roles in Shopping Cart
|
|
Re: Generic Roles in Shopping Cart
|
|
You mean to go into the OFBiz trunk? In the main code base we want things to be flexibe, and it happens that people want more than one party associated with the order in the same role. It's that simple... -David On Dec 14, 2007, at 3:02 PM, Chris Howe wrote: > Is there a reason to maintain the ten other specialized roles in a > non generic manner or some other reason that makes a HashMap(String, > String) approach undesirable? > > ----- Original Message ---- > From: David E Jones <[hidden email]> > To: [hidden email] > Sent: Friday, December 14, 2007 3:56:01 PM > Subject: Re: Generic Roles in Shopping Cart > > > > Sounds like it's a custom requirement (not really a general/generic > requirement), so custom code would be the way to go. > > You should be able to write a custom event that enacts this constraint > > and not modify any of the main OFBiz code. > > -David > > > On Dec 14, 2007, at 11:09 AM, Chris Howe wrote: > >> I'm needing to add an OrderRole to an order, but the role is >> determined while the individual is shopping before an orderId is >> known. Very similar to the ten other roles that are added the same >> way (supplierAgentPartyId, shipFromVendorPartyId, >> billFromVendorPartyId, etc). There's no need to add another >> variable and 3 additional methods to access that variable, when a >> generic HashMap(String, String) will handle an unlimited number of >> roles. >> >> ----- Original Message ---- >> From: Jim Barrows <[hidden email]> >> To: [hidden email] >> Sent: Friday, December 14, 2007 11:57:38 AM >> Subject: Re: Generic Roles in Shopping Cart >> >> >> I'm wondering why you want to do that? Are you trying to tie a >> shopping cart to an individual user? >> >> On Dec 14, 2007 10:41 AM, Chris Howe <[hidden email]> wrote: >>> I'm needing to restrict a custom roleTypeId to 1 per shopping cart, >> currently the only way to add a custom roleTypeId is through the >> addAdditionalRole, which will accept many parties per roleTypeId. I > >> can >> accomplish limiting the roleTypeId to one party only by removing all >> parties from the addAdditionalRole.roleTypeId before adding the >> limiting >> role, but it's not fail safe. >>> >>> ----- Original Message ---- >>> From: Jim Barrows <[hidden email]> >>> To: [hidden email] >>> Sent: Friday, December 14, 2007 11:35:31 AM >>> Subject: Re: Generic Roles in Shopping Cart >>> >>> >>> What problem are you trying to solve? >>> >>> On Dec 14, 2007 10:19 AM, Chris Howe <[hidden email]> wrote: >>>> I'm needing to restrict a custom roleTypeId to 1 per shopping cart >>> and I'm not finding a way to do that. Would there be any objection >> to >>> changing the way the roles are handled in the shopping cart? I >> would like >>> to change all of the roles that should be restricted to 1 per >> shopping >>> cart from specified variables to a HashMap(String roletypeId, String >>> partyId) in contrast to the additionalPartyRole of HashMap(String >>> roleTypeId, List(String partyId)). >>>> >>>> >>>> >>> >>> >>> >>> -- >>> James A Barrows >>> >>> >>> >>> >> >> >> >> -- >> James A Barrows >> >> >> > > > > |
Re: Generic Roles in Shopping Cart
|
|
Re: Generic Roles in Shopping Cart
|
|
Re: Generic Roles in Shopping Cart
|
|
Re: Generic Roles in Shopping Cart
|
|
It seems like the upside to this is less code in the shopping cart object. The downside to it more code that uses the shopping cart. These variables and methods have "built-in" or "implied" knowledge of the underlying roleTypeIds, and that wouldn't be the case any more. The only way I really see an upside is for the custom scenario you are talking about Chris, but I'm not sure if this is actually helpful for any other reason... -David On Dec 14, 2007, at 10:11 PM, Chris Howe wrote: > For the approach > 1) Create the accessor methods for the generic HashMap(roleTypeId, > partyId) > 2) Mark all of the specific accessor methods as deprecated or soon > to be deprecated or whatever the customary approach is > 3) Change those accessor methods to use the generic HashMap instead > of the string variables > 3a) Add log message about deprecation in the specific accessor > methods?? > 4) remove the string variables > 5) clean up project code to use generic accessors > 6) Not that this in itself warrants the maintaining of a separate > document somewhere, but eventually we're going to need to maintain > an upgrading pitfall document (be it an xml document in the project > or simply a page on the docs site, if one doesn't already exist), > especially if we're going to want to really take advantage of > generics in java at some point. > > If this looks good, I'll submit a patch. > > ----- Original Message ---- > From: Jacopo Cappellato <[hidden email]> > To: [hidden email] > Sent: Friday, December 14, 2007 10:39:45 PM > Subject: Re: Generic Roles in Shopping Cart > > Now it is clearer to me too: I actually misunderstood too, like David > (or you didn't explain it very well). > I'd say that is doable, but it seems like a lot of work, especially if > you want to remove the 20+ accessor methods... and I can see backward > compatibility issues. > But I'm not against this, especially if we end up with a good > approach. > > Jacopo > > > > |
| Free forum by Nabble | Edit this page |