oops.. i meant authc too.
well thats actually what i was trying to avoid. here I'll have to write
separate logic to handle all that data in the session. might as well be a
separate order table with session id in place of user id. Or is it easier to
do the handling in session than I'm imagining?
Cheers
Animesh
On Tue, Sep 23, 2008 at 11:50 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> Hi Animesh,
>
> (just a quick clarification - we use the abbreviation 'authc' for
> AuthentiCation (identity verification and login) - and 'authz' for
> AuthoriZation (access control - roles, perm checks).
>
> Anyway - on to the question.
>
> In my commerce applications, a user has one or more Orders. You can
> think of an Order as a ShoppingCart if you like, but I call it an
> Order because it will actually be inserted into the database -
> ShoppingCarts are usually thought of as temporal by nature - i.e. they
> often 'expire' after the user logs out or their session expires.
>
> My Order objects have the following attributes (slightly simplified
> for this example):
>
> - User user - the user responsible for creating/initiating the order.
> - Date creationTimestamp - when the selects their very first item, an
> order is created.
> - Amount subtotal - the total of all the order line items. An Amount
> object holds 3 things: A currency indicator and a BigDecimal.
> BigDecimal is used to ensure accuracy is retained during currency
> conversion so money is not lost (i.e. a double wouldn't be a good
> choice to represent monetary values).
> - Amount total - the total amount the user owes (includes the subtotal
> plus any taxes and shipping and handling).
> - List<LineItem> - all the line items in the order. A LineItem
> contains 3 things: a Product reference (what they are buying), an
> Amount - what the price is of the product at the time their selection
> goes into the order (important!), and an int quantity - how many of
> those products at that price they're ordering in the current order.
> - OrderState state - an ENUM representing the current state the order
> can be in - open (i.e. new or continued), paid, shipped, received,
> etc. - whatever your domain needs.
> and a List<Payment> - all the payments associated with the order.
> Most orders will have a single payment equal to the Order total, but I
> model it this way to handle edge cases in my domain logic. Anyway,
> moving on...
>
> So, how do I handle the scenario of user vs. non user shopping?
>
> If they are a User, the order immediately gets placed in the database
> table as soon as it is created (i.e. they select their first item to
> put in the 'cart' - the Order). The Order table has a User reference
> that records who is 'building' the order. The User property is
> non-null for that table, ensuring that all orders are attributed to a
> User. The interesting thing about this is that a User can have one or
> more open orders - think of any Order that is not their latest
> (current) one as a 'wish list' order that they can resolve when they
> want.
>
> If they are *not* a User, that is, a guest, the Order object gets
> attached to their session. When they check out, they must first
> create a user account (which amounts to usually just an email address
> and password). After that is done, the Order attached to their
> session gets added to the Orders table since there is now a User to
> associate it with. Before they become a User, you can can also
> serialize their Order to a Cookie so if that person does not check out
> (meaning they won't become a User yet), then at least the order is
> there for reconstitution when they come back to the site and they can
> keep shopping with it.
>
> You can check to see if they are a 'User' in JSecurity by checking:
>
> if ( subject.getPrincipal() != null ) {
> // they are a User because a principal is an identifying attribute,
> // and you only have an identity if you have an account
> }
>
> Similarly, you can check if they are a 'guest':
> if ( subject.getPrincipal() == null ) {
> // guest user, attach to session
> }
>
> I hope that helps a little. Feel free to ask more questions ;)
>
> Cheers,
>
> Les
>
> On Tue, Sep 23, 2008 at 2:22 AM, Animesh Jain <[EMAIL PROTECTED]>
> wrote:
> > Hi
> >
> > This is more of a best practice question. I would like to know
> > recommendations on how to handle guest users in a webapp. Lets say I have
> an
> > ecommerce store, where a user is allowed to shop around and add items to
> > shopping cart without logging in (authz). Now how should I maintain the
> data
> > this user generates. In my one of my current apps I have a separate
> > temp_user table but it ofcourse makes things messy in the sense now my
> order
> > table has two types of users, one for orders with logged in users and one
> > for users who are not logged in.
> >
> > Should we instead have just one single user table and create an entry for
> a
> > guest user in it whenever required. For eg lets say when a user adds
> > something to the shopping cart then we just create a user entry for this
> > user in the background with a guest role and log him in and then proceed
> > with the action. How could this logic be possibly centralized. For eg
> there
> > may still be certain actions that require a higher role. For eg we may
> want
> > payments to be made only after signups. Any suggestions? Also wouldn't
> this
> > add a lot of temporary user rows to the user table ?
> >
> > Thanks in advance
> > Animesh
> >
> >
>
