Yes, we maintain a 1 to 1 mapping of controls and we designate the ID of the control. We create objects with code like:
var my-custom-id = new swep.customObject(); // it is created in the correct scope to make it easy to update and the server knows that I have a customObject named my-custom-id and that makes it easy to update. Jim On Wed, Feb 22, 2012 at 7:05 PM, Chris Bunn <[email protected]> wrote: > Jim and Derrel, > > Thanks for identifying how I can retrieve the identifier for each > widget. If I can't specify an identifier for a widget how does the > back-end know the qooxdoo identifier for a widget? > > Do you maintain a mapping of identifiers on the client side? > > Thanks, > Christopher > > On Wed, Feb 22, 2012 at 6:11 PM, Jim Hunter <[email protected]> wrote: >> 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 > > ------------------------------------------------------------------------------ > 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
