NYCPHP Meetup

[Michael B Allen]

On Wed, May 21, 2014 at 1:21 PM, Gary Mort <garyamort at gmail.com> wrote:
>
> 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.

I'm still not convinced. Imagine you're making a calendaring
application and use local storage like you describe to draft events.
Then imagine a scenario where a user tries to schedule an appointment
while they're on the train and the internet cuts out. The appointment
is not actually scheduled until they visit the site again which by
then the event time may have already passed. Or maybe they used
another device. A lot of people have multiple devices now.

I think there certainly are cases where it is ok to store data on the
client. But it should not be anything someone would get remotely upset
about losing. And if it has to do with money, it's probably something
someone would care about.

Putting something in a shopping cart is a sort of transaction. You're
saying I am willing to purchase this particular item at this price. At
any point after that moment the item and/or price could change. The
item could sell out. A sale could expire.

Have you ever tried to buy plane tickets and a price changed on you
while you're sitting at the computer fiddling with times trying to
satisfy everybody's schedule? I think the airlines actually change
prices depending on website activity for particular flights. Bastards!

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/