For users of SmartGWT, or any other highly customised GWT framework, you might say that we should let them develop their own xml ui definition strategy.
To preempt any possibility that UIBinder architects might remotely have such an attitude - I would say that attitude, if existent, is wrong. Wrong because - that would cause all of us to vacillate across a few ui xml conventions within the same project. - it would miss the opportunity to provide the whole gwt community with a unified convention as jsp and jsf had been for the jee community. Now, that I think I have somewhat successfully preempted anyone from thinking each to his/her own ui xml strategy, comes the actual question. What are any plans for implementing strategies for UIBinder to allow custom widgets? The current situation for UIBinder is untenable, - due to the reliance on individualised element parsers - the inability to stick my own parser into gwt compilation process For example, - I cannot define my own widget hierarchy like menubar or tabbar can, with pseudo-elements like <tab>, <header>, directions, etc - I cannot define a custom widget that effectively implements both HasWidgets and HasHTML. If my custom widget implemented HasWidgets with either HasHTML or HasText, the uibinder parsing part of gwt compiler seems to ignore HasHTML and HasWidget and barfs at me for having forbidden html nodes or text. (Is this a bug or a feature?) There should be a plan and strategy, perhaps by programmers supplying a DTD to signify the allowed nodes and the DTD is compiled with the parser java code. i.e., a gwt element-parser compiler. So, any plans for a gwt element-parser compiler? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
