[
Lists Home |
Date Index |
Thread Index
]
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.
|
