This gives us one (and only one) cart per session -- which meets our business requirements.  And we rather like the idea of not having to pass it from here to there as the user navigates about.  Anyone who needs the cart knows where to look for it -- to my way of thinking this also eliminates potential bugs in that one component isn't dependent on another component having passed the cart along properly.

Thanks again for your time.

Regards,
Scott

On 10/9/06, Nino Wael <[EMAIL PROTECTED] > wrote:
Why?

Keeping the cart within constructors are kinda more POJO i think.

What I am working on now, we have a reportmodel and almost all our pages has a  constructor that requires our reportmodel, so we dont need to be aware of session.

I feel that the application becomes more simple that way, however we do not have a LOT of panels, we have some which uses abstractmodels that grabs their data from the reportmodel, when switching pages we pass the reportmodel through.

This might be a different approach from what you need when building a store site, but it feels pretty a lot simpler than have something stored in session context.

regards Nino


-----Original Message-----
From:   [EMAIL PROTECTED] on behalf of Eelco Hillenius
Sent:   Mon 09-10-2006 20:14
To:     [email protected]
Cc:
Subject:        Re: [Wicket-user] proof of concept app

If you're main domain is a store, and a cart is information you want
to keep throughout, it does make sense to put it in a session, so that
you don't have to pass it around your pages and panels all the time.

Eelco

On 10/9/06, Nino Wael <[EMAIL PROTECTED]> wrote:
> Looks nice(just skimping the code through without running it though), however I can see that you have extended the session, do you really have a need to store the cart in session context?
>
> Why not just create it on PosPage?
>
>
> -regards Nino
>
>
> -----Original Message-----
> From:   [EMAIL PROTECTED] on behalf of Scott Swank
> Sent:   Mon 09-10-2006 18:30
> To:     [email protected]
> Cc:
> Subject:        [Wicket-user] proof of concept app
>
> I've been pushing to use Wicket as our new web UI framework.  We currently
> have a custom template that resembles Velocity.  The broad concensus is to
> go with JSF.  While I'm convinced that JSF will work for us it always seems
> so cumbersome.
>
> I've convinced by boss to give Wicket a 2nd look, and so this weekend I
> threw together the attached.  If anyone is inclined to give it a quick
> glance for "best practices" type considerations I'd certainly be
> appreciative.
>
> The only relevant files are the jetty config, web.xml & the java/html.
> There are two apps that both sub-class an abstract app.  The "Concierge"
> version is for retail sales while the C3 version is for our call center.
> The urls are below.
>
> Thank you,
> Scott
>
>
> ---------- Forwarded message ----------
> From: Scott Swank <[EMAIL PROTECTED] >
> Date: Oct 8, 2006 10:41 PM
> Subject: concierge/c3 in wicket
> To: Scott Swank <[EMAIL PROTECTED]>, Scott Swank < [EMAIL PROTECTED]>
>
> http://localhost:8081/concierge/app
> http://localhost:8081/concierge/c3
>
> --
> Scott Swank
> reformed mathematician
>
> Power is not a means, it is an end. One does not establish a dictatorship in
> order to safeguard a revolution; one makes the revolution in order to
> establish the dictatorship. The object of persecution is persecution. The
> object of torture is torture. The object of power is power.  -- George
> Orwell, 1984
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to