Hi JB
We've been using server-side JS for a while now, it forms the glue between
pages and also the server side of the apps that we build. Each app is
defined in XML and then compiled into Qx code for the client; the properties
are kept synchronised between the client and the user's session on the
server, events fired on the client can be caught by the server, and
functions can be called on the client by the server (or vice-versa). The
widgets bind automatically to XML documents which are persisted in the
database.
Up until now, the server side JS for the Qx apps has been strictly
procedural programming - i.e. functions only, and reuse is by including
other .js files. There has always been scope to really improve server side
integration by building smart objects rather than being restricted to just a
function call, but it's been a low priority. Now that at least one app is
getting particularly complex it's more justifiable to look at it again.
The app is for use on our customer's extranet by external suppliers so we
know our users quite well and we're confident that scalability won't be a
problem - worst case is that we have to buy a couple of extra Gb of RAM J
John
From: Jean-Baptiste BRIAUD -- Novlog [mailto:[email protected]]
Sent: 20 November 2009 8:06 AM
To: qooxdoo Development
Subject: Re: [qooxdoo-devel] Using Qooxdoo core in a non-Web environment
HI John,
I didn't try it but I'm thinking to it since long time, at least for some
part of the server code.
I would be very interested to know the context of your project.
How did you arrive to that idea ?
What are the big figures of your project : number of end-user, do you have a
database, do you have SQL ...
How will you address the persistence of the data manipulated by the qx
application ?
Concurrency on server side ?
Scalability ?
Regards,
JBB.
On Nov 19, 2009, at 17:34 , John Spackman wrote:
Hi guys,
We have some server side code that is written in Javascript and is executed
by Rhino; I am *so* pleased to have a proper object model when developing
client code but the more complex the server side gets the more I want to
develop server classes in the same way.
Has anyone experimented with a non-GUI, server-only version of the Qx
framework?
I'd be really interested to know if anyone has experimented with this
before, and/or what the potential issues might be in making Qx server-side
compatible. For example, my (completely uninformed) guess is that the
generator would work just fine except that the bootloader it produces would
need to work differently (i.e. loading of scripts etc), and potentially
there might need to be a way to exclude some classes or packages.
On a possibly related note, how does the qx.application.Native get used?
Regards
John
----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
http://p.sf.net/sfu/bobj-july_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
