Re: [qooxdoo-devel] How to obtain an existing qooxdoo object

[Derrell L. <der...@un...>]

On Mon, Mar 25, 2013 at 5:16 PM, Chris Bunn <ch...@gm...> wrote:

> Derrell,
>
> I am tracking application state by user in a database, I just don't
> see how to interact with the qooxdoo objects (or widgets) that are not
> known in the event context without using something like the hash
> value. If for example I have a parent/child table structure and I am
> displaying the parent record in one qx.ui.window.Window and I am
> maintain child records in a separate qx.ui.window.Window. I would like
> to update a label containing a running total in the parent record
> window after the completion of each child record edit. At the
> completion of each child record entry I make a call back to update the
> child record but I don't see the application logic can update the
> running total widget in parent record window without knowing the
> hashcode or some indirect reference to it.
>

The principle here is "separation of concerns." One common paradigm is
called MVC: Model, View, Controller. The graphical user interface, at the
frontend, provides the *View* of your data. There could conceivably be
multiple views of the same data. There could in fact, be multiple, entirely
independent graphical user interfaces that all use, display, and manipulate
the data, all written by different people. At the other end, in this
particular example, your backend acts as the *Controller*, saving data in
your database, issuing requests to external resources, possibly even
sending notifications to the frontend.

The View and the Controller communicate via a Data Model. That model
contains, of course, the data to be displayed by the View. In the other
direction, it contains data which the user has changed in the View, that is
to be updated in the backend by the Controller. The model, or sometimes,
whatever means is used to communicate the model between backend and
frontend, may also contain requests for data to be displayed, or an
indication that something has been changed by the user. When there are
multiple users, the model may indicate to users B, C, and D, that some data
was changed by user A.

Using this "separation of concerns" principle means that the backend
doesn't know or care how the frontend displays its data. The frontend
doesn't know or care how the backend stores its data. They each use some
mechanism in the middle, to communicate *data* which is independent of how
it is displayed on the screen, or how it gets saved to a database.

There are multiple common means of transferring the data model between
backend and frontend. REST has seen increasing use in recent years. I still
prefer RPC (remote procedure calls). Other means can be considered. Both
REST and RPC are supported by qooxdoo, for frontend use, out of the box.
Both of those are also commonly used backend technologies, so finding a
server that supports REST or RPC is easy.

This is really a software engineering discussion, with many other options
available. I have really only touched the surface here. It should, however,
give you some food for thought and send you off in search of additional
information on the topic.

Hope that helps.

Cheers,

Derrell