Hi Martin,
we did implement a crossdomain backend using the postMessage api in a hidden
iframe. That way we could reach out to our server backend while still
developing our application from the file uri. Also it is very nice with a
couchdb backend since you get plain json from the couch and could then send
it as either json or javascript object to the application using a
postMessage call.
We solved the serialization/deserializsation problems with the correct
marshaling by implement an own CouchDocumentMarshaler extending the
qx.data.marshal.Json implementation. With this approach also the
qx.util.Serialize thingie works like a charm.
If I find some time to cleanup our code (currently its quite hacky and there
are application dependent parts in it) I will contribute it back to qooxdoo.
And yeah, I work for SinnerSchrader since a short period. Currently we
create a backend admin tool for a customer which will probably closed
source.
And also yes, I was at jsconf.eu. It was awesome, wasn't it? :-)
Regards
Markus
2010/10/8 Martin Wittemann <[email protected]>
> Hello Markus,
>
> we build our own qx.data.store and qx.data.marshal implementation.
>
> What was the reason for doing so? Is it something general like XML data?
> I'm always interested what the limitations of the framework classes are so
> its really interesting to hear some details. :)
>
> Now we want to have the build model to be send back to the server as
> native javascript object. For that we would like to use
> qx.util.Serializer.toNativeObject. Is this the right aproach or is there
> something simpler?
>
> Yes, that sounds like the right approach.
>
> If this is correct then there is a bug/missing feature in the serializer
> which uses qx.util.PropertyUtil.getProperties() instead of
> qx.util.PropertyUtil.getAllProperties(). In the current implementation only
> the actual class is 'demodelized' instead of the real class hierarchy.
>
> In the cases we used it, getProperties() was totally ok. But I don't see a
> reason why it should not take all properties. So that's, as you said, a bug.
> Would you mind open up a bug report for that? I would take care of that
> after my vacation in three weeks.
>
> SinnerSchrader Deutschland GmbH
>
> Your working for SinnerSchrader? What app do you develop using qooxdoo?
> Have you been at jsconf.eu?
>
> Best,
> Martin
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
--
Markus Wolf, Developer
[email protected]
T +49.40.39 88 55 - 324
SinnerSchrader Deutschland GmbH
Völckersstraße 38, D-22765 Hamburg
Amtsgericht Hamburg HRB-Nr. 63663
Geschäftsführer: Matthias Schrader (Sprecher), Holger Blank,
Laurent Burdin, Thomas Dyckhoff, Chris Wallon
Büros: Hamburg, Frankfurt am Main
http://www.sinnerschrader.de | Creating Radical Relationships.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
