Jim I think I am understanding why your server returns javascript. If the server app wants to update a field what type of code snippet does it pass to the client?
I was approaching this with the intention of passing a json object to the client that would pass the parameters required to modify the client UI. I had started this project by writing my own javascript framework. I was creating a container in the DOM for the widget and attaching my own javascript class ($MyFramework.MyClass) to the DOM element and setting the DOM ID to whatever the server side wanted to call it. When it came time to update the UI the server would pass back the DOM ID and arguments for the necessary update. The javascript on the client would use document.getElementById(passed ID) to acquire the object and then I would call the attached class (element.$MyFramework.MyClass(arguments)). This worked well enough until I heard that this type of DOM modification was prone to garbage collection issues, and I was becoming really bogged down in CSS, event bubbling and so on. I found Qooxdoo and was really impressed by the overall direction of the project. It seemed to be the only framework that was geared towards web applications and not web sites. It seems that their is no way to specify an identifier that can be assigned or used to retrieve a qooxdoo widget. On the client side I will need to maintain a hierarchical mapping of application widget-ids to qooxdoo hash values. Thanks, -Chris On Wed, Feb 22, 2012 at 10:52 PM, Jim Hunter <[email protected]> wrote: > 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 ------------------------------------------------------------------------------ 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
