Hey, > In some cases, that is a good enough workaround. But it also means that > as afar as working with the data-bound widget in Javascript goes, you > only get the IDs. > > Sometimes, I need controller.getSelection() to give me the model objects > to work with, but I also want to be able to do: > > controller.getSelection().push(15) > > or: > > controller.getSelection().push(duplicate_instance) > As the selection in a simple array, you have to decide whats the content of it. Either its ids or model items. But having both is somehow strange and does not work at the moment.
> That is: select an item that I do not have the original instance of, > because I serialized a new instance from the server. > > It's like if you had to implement a server-side search function for the > Qooxdoo feedreader demo. If the server returns feed object IDs and > article IDs, how would one update the feed reader UI widgets to jump to > a particular search result? The most easy way is a search algorithm and simple search for the object by the given id. If thats too slow, you can pick the solution Mustafa suggested and mirror all data in some kind of index, most likely a object where searching has O(1) which would solve the speed problems. > I am using a helper to search my trees now, but it's not a pretty > approach either. My thought was a custom Qooxdoo identity system: > > If each qx.core.Object had a "_getIdentity()" method, the user could > implement this method at his discretion. If it is missing, things work > just the way they do now. The data binding controllers would have to be > updated to use this new identity system instead of the native JS identities. But how would that solve the issue that you want to have both, the id and the instance as selection? This sounds like a mix of hash code and model property to me. Whats the difference? > This is obviously a significant addition, and I don't know about the > design considerations involved. I wonder how other frameworks solve > this. But I do feel like something is missing here. > > In the linked thread, a further idea was discussed, which I think would > be useful as well, though it solves a different problem: a marshaller > than helps with resolving references. And that would be a search algorithm, I guess. With that, we would simply move the search form app code to framework code. ;) > In a feed reader, if I query the server for a list of articles of the > feed the user just selected, and each article has a "feed" property > pointing to the feed it belongs to, then I want article.getFeed() to > return the same instance of the Feed object that is already loaded. The content is the same but not the JavaScript object. If you want to have that, you have to tweak the store and implement a merge algorithm which only copies the data to the old instance and disposes the new. Regards, Martin ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
