Thank you for the answer. The connections are no problem, I was thinking
more in terms of the relation of the folder structure and the generate.py
script. I have been thinking some more about this since posting and I would
like to separate the SDK and the generate.py script from the exposed
folders. One way would be to use file system links, but another way would
be to generate the source and build folders in a different location. I
would like to integrate generate.py into the build system such that it is
executed automatically and when deploying I don't want unnecessary files to
be visible to any client.
But I guess that during development it should be possible to skip
generate.py by generating everying (generate.py source-all if I recall
correctly).
/Stefan Larsson
2015-02-02 13:01 GMT+01:00 halcwb [via qooxdoo] <
[email protected]>:
> A quick glance at the play2 framework suggests to me that this is
> comparable with having a .net MVC solution as backend. In both cases, on
> the server side you just have one view, which is the qooxdoo app. The
> qooxdoo app communicates with the server side controllers, which are in
> this case functioning as services. In my .net mvc I have the qooxdoo front
> ends (one for desktop, one for mobile) in separate folders, and what I can
> tell, in your case these could be put in the public folder. But you could
> also put the app in an entirely different folder, not that you might then
> use JSONP to avoid cross domain calls.
>
> You can then either implement communication with the server side
> controllers using a RPC approach or calling them like a REST service. To
> use the RPC approach you'll need to map the calls on the client side to the
> correct controller/action.
>
> Hope this helps.
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://qooxdoo.678.n2.nabble.com/Play2-framework-qooxdoo-best-practices-tp7586751p7586755.html
> To unsubscribe from Play2 framework + qooxdoo, best practices?, click
> here
> <http://qooxdoo.678.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7586751&code=c3RlZmFuQGxhc3RzeXMuY29tfDc1ODY3NTF8LTMxODI5NDM2NQ==>
> .
> NAML
> <http://qooxdoo.678.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21workgroup%3Aworkgroup.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
/Stefan
--
View this message in context:
http://qooxdoo.678.n2.nabble.com/Play2-framework-qooxdoo-best-practices-tp7586751p7586756.html
Sent from the qooxdoo mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
