[Opa] Dom.put_inside error?

Mads Hartmann Jensen mads379 at gmail.com
Wed Aug 17 06:00:51 EDT 2011


Hi, 

Thanks for the detailed feedback. As my goal is to submit the application I'm working
on to the developer competition it's probably best I use the work-around for now ;) 

I'm getting another error in another piece of code:

Error: File "stdlib/core/rpc/core/opaserialize.opa", line 340, characters 8-47, (340:8-340:47 | 11685-11724) @fail: OpaSerialize.partial_serialize

Do you reckon it's the same kind of problem I'm having? Unfortunately I can't seem to reproduce
the error in a simple example so if you want to have a look at it I would have to send you 
my entire application (it's not that big).  

Cheers,
Mads

On Aug 17, 2011, at 11:53 AM, François-Régis Sinot wrote:

> Hello Mads,
> 
> This is not really a bug, but more a limitation of the current version
> of Opa. At the moment, the only entry points between server and client
> (both ways) are top-level functions. So in your example, page is
> executed on the server, so Dom.of_xhtml is executed on the server, which
> results in an abstract type that we cannot send to the client.
> 
> We are working at the moment on a new version of Opa where this
> limitation is lifted, but this is really a big rewrite with lots of
> consequences, so don't hold your breath for it (expected delivery date
> in experimental stage: mid-september).
> 
> In the meantime, while Adam's work-around is perfectly sensible and
> works well in many cases, I can suggest another one for your specific
> case. Instead of the Dom.put_inside line, write: 
>  _ = Dom.transform([#test <- <>Clicked!</>])
> 
> What happens here is that there is some kind of mini-DSL for Dom
> transformations that allows the execution of the Dom.of_xhtml to be
> delayed until on the client. This DSL is limited and not very cleanly
> integrated at the moment, but it does the job !
> 
> Hope this helps !
> 
> François-Régis.
> 
> Le mardi 16 août 2011 à 15:25 +0200, Mads Hartmann Jensen a écrit :
>> Hi Adam,
>> 
>> 
>> Thanks! :) I'll se if that solves my problem temporarily till the fix
>> gets released. Good luck with the bug :) 
>> 
>> 
>> /Mads
>> 
>> On Aug 16, 2011, at 3:13 PM, Adam Koprowski wrote:
>> 
>>> 
>>>  Dear Mads,
>>> 
>>> 
>>>  Indeed, looks like a bug. Thanks for the report -- I'll pass it
>>> along to our team and we'll get back to you once it's fixed.
>>> 
>>> 
>>>  Temporary workaround: Put the when_ready function at top-level
>>> (you can also mark it with @client directive for good measure, as
>>> the error is due to serialization of some data before passing it
>>> back to the server in case the when_ready function is on the
>>> server).
>>> 
>>> 
>>>  Best,
>>>  Adam
>>> 
>>> On Tue, Aug 16, 2011 at 14:23, Mads Hartmann Jensen
>>> <mads379 at gmail.com> wrote:
>>>        Hi Adam,
>>>        Your example does indeed work. Here's an example that
>>>        doesn't work :) 
>>> 
>>> -- 
>>> Adam Koprowski  [http://adam-koprowski.net] 
>>> R&D @ MLstate   [http://opalang.org | http://mlstate.com] 
>>> 
>> 
>> _______________________________________________
>> Opa mailing list
>> Opa at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/opa
> 
> -- 
> François-Régis Sinot
> R&D @ MLstate
> 104 rue du Faubourg Saint-Antoine, 75012 Paris, France
> 



More information about the Opa mailing list