NYCPHP Meetup

[Gary Mort]

On 05/20/2014 04:24 AM, Michael B Allen wrote:
>
> I actually started out doing what you describe but I thought the
> server side code started to get a little messy so I thought I would
> break things up into add, remove, applyCode and so on.

Right, and you can still do that.  Ie you have an add function, an 
applyCode function, a remove function, etc.

Then your update function just chains all 3 functions together.

> As for other's suggestions about storing state on the client by what
> is ultimately manipulating the DOM with JavaScript, I can see how that
> could be used to create sophisticated UI elements. But I don't think I
> would ever put any state on the client that I couldn't accept losing
> at any moment (e.g. as I type this, gmail is periodically saving this
> message with async requests). Even storing stuff in a cookie seems
> dubious for a shopping cart.

Actually, I find the best mechanism is to use a localDB data storage for 
almost anything where you are storing data - but that means limiting 
your code to browsers supporting some minimal amount of HTML5.

By storing your "draft" data in a localDB, you then will have an easier 
time converting your code from an online app to an offline app.

For example, when I use the gmail interface, I enable it's offline mode 
so all the draft data is saved to my local db.  If I happen to be 
travelling on the train with internet cutting in and out, then I can 
still compose e-mail and it will be sent when I'm online again.

Shopping carts can find this especially useful in that then you can have 
offline mobile apps so your customers can still spend money even when 
offline. :-)  Or at least add to their cart.

It does mean some extra work on your part though - doing that means you 
have to verify that the price they have in their cart matches the 
current price when they go to pay - and if it doesn't give them a chance 
to modify things.