[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