[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Cookies at XML Europe 2004 -- Call for Particip ation
On Tue, Jan 06, 2004 at 06:41:52PM +0100, Nicolas Toper wrote: >Eyes rolling for the Javascript solution :=) > >You could also but some variables in post to describe the cart... It's a pain >but could be done Not really. I have a particular website in mind. That site uses well-formed HTML (not declared as xhtml, but as close as I can get without the customer going ballistic) and CSS. CSS means that I don't have the pain of frames, but can have omnipresent navigation and relatively sophisticated layout without tables. Goal of all this is to make it maintainable, *and* to make it very, very easy for a customer to browse. In order to make it easy, I *also* need to use GET as often as possible, so that the customer can freely hit the Back button without getting the irritating "oh, you wanna buy another one, do you?" dialog box. The few places where I've got POST (because the action isn't idempotent), I also provide a special button (php constructed) that performs an action equivalent to back (go back to the middle of the list that you were just looking at). Amazon, btw, seems to add to the cart without using POST, which always struck me rather oddly. The ability to return to the middle of a recent search after adding an item to a cart, btw, is prolly implemented in a fairly RESTafarian way: the "continue shopping" button reloads list.php (which does a database search), passing in the same parameters that were used for the original search, plus the offset. All visible in the URL (well, mostly, anyway, but let's not get picky). Bookmarkable, sharable (of course, if inventory changes between bookmark store and bookmark retrieve, you may get a different page. Sela). But abusing POST in order to pass information around is not, in my opinion, a reasonable solution. Elliotte said much the same, so I'm anxiuosly awaiting his followup (I hope I haven't sounded confrontational; I really don't understand how it would be possible to design something that meets the stated requirements without a session). >Le Mardi 06 Janvier 2004 18:35, Strolia-Davis Christopher Contr MSG/MAT a >écrit : >> Amelia A Lewis wrote: >> >I want to have an e-commerce website. I do not want to require users to >> >"log in" or have to create some sort of fatuous "account" (so that they >> > can lose the password, presumably) in order to add items to the cart. >> > >> >So, there's no username. How do I do this without a session? I don't >> > care whether the session is cookies or url-rewritten, but you're making >> > an assertion that it's possible to do something that I don't understand >> > how to do, and have never seen described. >> >> There are actually quite a few alternatives to this, although, I'm sure I >> will get quite a few guffaws from my suggestion. >> >> One way to maintain state on a web site could be done through the use of >> frames and JavaScript (I can already see the eyes rolling). State info Okay. I'm strongly opposed to frames, for several reasons. Lossage is one; if you do this, and I use my browser to expand one frame to the top-level, doesn't this break? But in general, I think frames were not the correct solution to the problem; CSS float does most of what frames were originally intended to do. Using frames also reduces maintainability. As for javascript ... I suppose that this would be mostly possible, but can it be done without frames? >> could be kept in a topmost frame while the user navigates around other >> frames. Each of those can be programmed to take info from the top frame >> and send it along with any other form data that is passed between pages. You're not proposing POSTing this stuff, are you? Abuse of POST is going to make navigation painful. >> The top frame could also keep info about what the user has seen, ordered, >> etc. Without requiring any commitment to the server. I think that it would mostly work, if there were a relatively ubiquitous client-side language that could maintain state while attached to a particular site (without the frames hack) to instruct it to keep track of activity on the site, in the same way that I'm currently using a cookie to store a session id, and product id + quantity. That is, it would prolly work for any user willing to let such a thing run on their machine. It would be rather hard for me to design, since I generally turn *off* all the "we want to use your CPU to perform Stupid Graphics Tricks" options in my browsers, and in any event, I don't believe that there is a language capable of maintaining site-specific (as opposed to frame/page-specific) state at present. >> I'm sure there are other ways of accomplishing this as well. It all >> depends on what you need to do, what your limitations are, and who your >> main audience is. There is no single solution that will work for >> everybody. Err. I've heard that before (and this is the reason that I challenged Elliotte in the first place). But I haven't been able to find a description that addressed the particular issues in a way that I could actually implement. Amy! -- Amelia A. Lewis amyzing {at} talsever.com Igne natura renovatur integra.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|