Actually Derrell, maintaining the state at the server works quite well for us (we have a custom written server in Delphi that interfaces with our Oracle server and maintains the status of each connected user). We are able to redisplay the page, in it's current state, whenever the users hits F5 because we maintain the objects state.
In answer to Chris's original question, we create unique ID's for each control we create at the server. And the objects are pooled to keep the total number to a manageable level. So whenever the server needs to update a control, it knows the ID and it's very easy to send a small piece of JavaScript back to the client to update the object. We have to do it this way because we do not have a 'set' visual framework. Everything is created and rendered on the fly based on a form configuration that is saved in a database. So every client that uses our software has a totally different look and feel based on how they set up the pages. Qooxdoo handles this like a champ. The unique ID's work great and pooling keeps us from chewing up large amounts of ram. Jim On Wed, Feb 22, 2012 at 3:19 PM, Derrell Lipman <[email protected]> wrote: > On Wed, Feb 22, 2012 at 18:10, Chris Bunn <[email protected]> wrote: >> >> Hello >> >> I am new to working with qooxdoo, and am still trying to familiarize >> myself with the API. I am trying to determine the best way to access a >> widget object after it has been created and outside of the scope it >> was created in. In the application that I am working on the back-end >> logic maintains the state and widget IDs of the application UI, it >> then send a JSON message to the qooxdoo application to visualize the >> UI. When a UI event occurs it the qooxdoo application sends a JSON >> message with information related to the event, the back-end returns a >> JSON message that tells what widgets to update. The problem I am >> having is that I don't see a way to specify an identifier for a >> widget. If there is a way how do you obtain the object using the >> identifier. > > > Each widget has a unique identifier called a "hash code" which you can > retrieve with: > var hash = myWidget.toHashCode() > > You can later retrieve that widget, given its hash code, with: > var myWidget = qx.core.ObjectRegistry.fromHashCode(hash); > > Maintaining widget state (as opposed to maintaining a model of the data > which happens to be represented by widgets at the GUI) at the server feels > dangerous to me. The application can get reloaded, the server needs to be > notified and discard old state, etc. Although not unheard of, it is an > unusual design. Are you sure that now that you're using qooxdoo, that's the > best way to do things? > > Cheers, > > Derrell > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
