[Opa] where to store client-side state

[Rudy Sicard]

Hi,

Yes, you can do something like that:

// client cache storage
@client
myclientcache:option(user_data) = Reference.create(none)


// client storage init
@client
initmyclientcache(initval) =
   up(o) =  match o
                 {none}      -> some(initval)
                 {some=_} -> error("multiple initialisation")

   Reference.update(initval, up)

// client getter with server fallback
@client
client_get_user_data() =
   match Reference.get(myclientcache)
   {some=v} -> v
   // fall back in case nobody has called initmyclientcache
   {none} ->  v = server_get_user_data()
                     do initmyclientcache(v)
                     v

// server getter
server_get_user_data() = UserContext.get( ... )

// the general getter that select the fastest solution
get_user_data() = @slicer_expr({client  = client_get_user_data()
                                                      server = 
server_get_user_data()})

Best,
Rudy

On 31/01/2012 19:04, Owen Gunden wrote:
> Ok, I think I get it. Going back to my original question; in the case
> of onready="initmyclientcache(initval)", you will still have to store
> the initval somewhere. I'm guessing you just store this at the
> toplevel with an @client.
>
> On Mon, Jan 30, 2012 at 8:43 AM, Rudy Sicard<rudy.sicard at mlstate.com>  wrote:
>> Hi,
>>
>> The cookie only stored the identity of the user, there is no data in it (it
>> is traditional).
>> =>  The state is not stored into the cookie but I guess you can easily use a
>> client cache if speed is needed.
>>
>> For instance, you could have a state copy for get access, that can be
>> invalidated by set access or which is refreshed if the state is too old.
>>
>> For now the served client code not client's id specific, so if you really
>> want a minimal number of query,
>> you should not ask the state on the js toplevel but you'd rather ask it on
>> server side
>> while construction the html page and pass it to the client environment using
>> onready event.
>> e.g.
>>
>> function_constructiong_html() =
>> initval = UserContext.get( ... )
>> ......
>> <div onready={initmyclientcache(initval)}></div>
>>
>>
>>
>> On 29/01/2012 01:03, Owen Gunden wrote:
>>> All the state is stored in a cookie? Interesting. That would be
>>> different than how "traditional" frameworks do it, storing an index
>>> into a server-side "session" table.
>>>
>>> Nevertheless, if it's required to contact the server every time I
>>> access the UserContext state (i.e. UserContext.execute), then what's
>>> the point of making it client-side state?
>>>
>>> I'm coming around to the idea that I'm overly paranoid about
>>> performance, and just storing it as a toplevel binding (and serving it
>>> in all of my pages) will be plenty fast. (thinking of all those sites
>>> that import jquery, etc. on every page)
>>>
>>> On Sat, Jan 28, 2012 at 4:33 PM, Adam Koprowski
>>> <Adam.Koprowski at mlstate.com>    wrote:
>>>>>>    Would UserContext work for you here?
>>>>> I hadn't thought of that. But isn't that on the server?
>>>>    All the manipulation functions are server-side (not sure why, in fact)
>>>> but
>>>> the state is on the client implemented with a cookie.
>>>>    Best,
>>>>    Adam
>>>>
>>>> --
>>>> Adam Koprowski                [http://adam-koprowski.net]
>>>> Opa Tech Evangelist @ MLstate [http://opalang.org | http://mlstate.com]
>>> _______________________________________________
>>> Opa mailing list
>>> Opa at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/opa
>>
>> _______________________________________________
>> Opa mailing list
>> Opa at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/opa