Hi
Adam,
So,
there are customer specific and cart specific limitations. I would definitely
make the cart responsible for the cart limitation. I'd probably also make the
cart responsible for the customer limitation, although it'd do it by calling a
User.getPSETotal() or something like that which would run the report via the
user gateway. I don't think the user should know how much PSE they can buy, but
it wouldn't be unreasonable for the cart to know the totals both per order and
per user. I'm not sure that is right, but it doesn't sound TOO wrong - I'd argue
the cart is responsible for not accepting too much PSE.
As for
the reusability, you have a number of options. As you said, you could subclass a
general cart with an ashleycart and a drugcart. That actually isn't too bad as
ashleycart and drubcart clearely both ARE carts, but we should "favor
composition over inheritance", so I'm trying to think of other approaches. You
could also decorate a general cart with a drugcart (which is actually how Chris
implemented AOP in ColdSpring) or as I just recently posted, you could try
mixins to self-decorate the cart (honestly - bad choice, just a cool
idea!).
I just
don't love AOP as a solution to this problem as it is tactically useful but
missed the intent - the PSE rules really are a part of the business model - not
just an aspect that we can throw in. If we went down that route, we'd use
aspects to encapsulate variability in shipping, tax and checkout calculations,
and I don't think it is the best way to go.
I
guess the more I think about it, with the reuability requirement, I'm split
between decorating and subclassing, and if you want to decorate, AOP is an easy
way to do it without having to worry about renaming the classes yourself. Bear
in mind the additional User and Product getters, though and the fact that your
DAO will be working with a db with additional fields that would have
to be taken into account in your inserts, updates and possibly your reads
as well - I'm not sure you're going to get pain free reusability, and if
you don't I'd just add the extra code to the cart.
The best way to go (in my extremely biased opinion) would
be to write a software product line where you used metadata to generate
variability - using a core set of templates with the ability to add additional
properties and algorithms at generation time for each specific application, but
I don't think I can cover that in a single email and it's going to take me weeks
to blog about enough basic concepts to show how to start writing software
product lines with reusable metadata and CF Template! Also, it would only be
worth the trouble if you planned on generating 3-4 or more similar
apps.
So,
would an "it depends" work for you as an answer?!!!
I
wonder whether someone else will chime in on this or whether they've got better
things to be doing on the 4th of July?!
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----This application sits outside of the POS terminal so this does not work with payments or anything of the sort. It is strictly PSE purchase tracking and reporting. Thankfully the business owners decided how to ID people; by State ID, drivers license, or Passport number.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Haskell
Sent: Tuesday, July 04, 2006 2:24 PM
To: [email protected]
Subject: Re: [CFCDev] Aspect or not?
Stores are not limited to sales, customers are limited by federal and state laws, and specific transaction are limited by federal and state laws. Sounds like my original idea (a limitations object of sorts) is ok but you disagree with it being an aspect b/c you think it is appropriate for the objects to be aware of the limitations, where as by putting it in an aspect the objects are unaware of the limitations that are being imposed on them (let me know if I am reading that wrong).
That's the exact type of response I was looking for, should my core objects be aware of the limitations? Sounds like you say yes they should be aware. I appreciate the response, I don't know I am entirely convince one way or the other still thinking about it, though the more I think about it I think I am leaning towards it not being an aspect.
What if I threw in this. We have a similar application that tracks sales of Ashley Furniture. Without getting into too much detail the same set of core components could be used if I had the limitations through and aspect, or I probably could extended the core components to work inside the PSE application does this make any sense?
Adam
On 7/4/06, Peter Bell <[EMAIL PROTECTED]> wrote:Hi Adam,I would add this to the core business model. For me, aspects are cross cutting concerns that decrease cohesion (a product shouldn't know about logging, security or workflow, so those are the classic examples of AOP). To me it is perfectly appropriate that a business object would know about these limitations - even if you sell outside the US and this is a US only limitation, I'd still put this into the model as a "US only rule".As to where it should go, it would depend on the business rule. The store might know the total you can sell to all customers, a user might know they'd bought too much within a day or a cart might know that it had too much in that given cart. (BTW, good luck with the actual logic - how do you uniquely define a customer when one person could have different email addresses, shipping addresses and credit cards?!) If you needed more than one of these rules implemented, you may make a call to a seperate object that would encapsulate all of the PSE rules. I'm guessing you're also going to have to extend the product business object to include a getPSE() method (the product knows how much PSE it contains, but not how much the store, user or cart contains, so a getter for that one piece of information is appropriate).Of course, you also need to make sure that your cart.add() method returns the status of the add (you could also use this for people buying too much stuff for their credit line or ordering more product than you have in inventory or some other cases where cart.add() will fail) and probably an error message so you can display the cart view with "Cart not updated successfully: #ErrorMessage#"."Just some thoughts.Best Wishes,
Peter-----Original Message-----As some may know the lovely US gov't has put new laws in place limiting the sale of Psuedoephedrine. Right now I am in the process of reworking the original application into Model Glue framework also using Coldspring. So here is my question:
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Adam Haskell
Sent: Monday, July 03, 2006 5:10 PM
To: [email protected]
Subject: [CFCDev] Aspect or not?
Right now the Application merrily has transaction and transaction detail objects (among others). Each detail is added through an AJAX call to the server. My thought right now is to put the code that determines if the current detail can be added to the transaction into an aspect. The idea being that the core objects do not change and the transaction object can continue to happily append details, telling to persist ect. The aspect would "sniff" the detail and if the detail can not be saved due to legal limitation (too many grams of PSE or too many packages per day) the aspect throws an error OverLimit and the application deals with it. My concern is that by through the error I will end of having to deal with that in the transaction object thus changing it anyway. Maybe that's an OK thing but I need someone else to tell me that, or maybe some different suggestions. I just need a reality check from people that have probably been doing this more than me.
Adam Haskell--------------------------------------------------------------------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
