Max Motovilov wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:038301c40150$3f870040$1d00a8c0@pdimov2...
Not a problem. You can always serialize your widget and capture its current state into XML.
Looks to me like this is all about tradeoffs. A runtime UI data repository (DOM-based, perhaps) simplifies widgets (well maybe not, it is all a matter of the right wrapping of the interfaces after all - what is easier, writing marshalling code or using property mechanism to expose your essential data?) and promotes flexibility: with serialization-based approach your RAD tool may have to re-create all or large part of application's windows every time a change is made, same applies to user-customizable UI elements (menu editing, stylesheets etc.). Also, the ID tag example may be extended to allow XPointer/XPath addressing at which point you'll have to give up the serialization approach for sure :)
Hmm, it looks like you have a DOM hammer and you see a GUI nail. ;-) A widget graph can be represented as a DOM but from where I sit it's simply not needed. No, my RAD tool does not recreate anything (note present tense here), when you change (the equivalent of) a label's text it just calls (the equivalent of) l->set_text. It only serializes (to XML, binary, or whatever the archive du jour is) when I save the widget graph to a file. With an appropriate query engine, you should be able to do XPointer/XPath on a widget graph directly if you feel so inclined, although I'd probably prefer a visitor approach. Anyway, I have tried the serialization approach and it works. I haven't tried a DOM-based graph representation (probably because I haven't grown accustomed to the DOM hammer yet), so I can't say how well it would perform.