Re: Generic Roles in Shopping Cart

[David E Jones]

-David


On Dec 14, 2007, at 10:11 PM, Chris Howe wrote:

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

For the approach

4) remove the string variables
5) clean up project code to use generic accessors


If this looks good, I'll submit a patch.

----- Original Message ----
From: Jacopo Cappellato <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
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.


Jacopo

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?? 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. But I'm not against this, especially if we end up with a good approach.

smime.p7s
Description: S/MIME cryptographic signature