Community
Participate
Working Groups
Add templates to XWT. There is a link on the wiki to UI Template but its not setup. I am opening up this enhancement request to track the enhancement. If templates do not support XWT's mission, we can close this request. It would be desirable to have some aspect of jface compatibility. For very simple controls with a single component of content, you can use other techniques but for list controls, templates make it easier to specify L&F very succinctly. Sub-capabilities include: a) data binding with the ability to specify the source of the binding including the template parent binding specialization as well as general ancestor/type locating and element name locating. b) base classes that allow the templated parent to be located as well as apply templates as part of the visual UI rendering process e.g. applyTemplate. c) hierarchical resource finding. d) ability to not immediately evaluate a template definition in xml I think a & c are mostly done in XWT but this needs to be validated. Yves, having done this in eface, does XWT have enough underlying machinery to make this an easier proposition? I implemented a rough template capability using aspectj ITDs for pivot.
(In reply to comment #0) > Add templates to XWT. There is a link on the wiki to UI Template but its not > setup. I am opening up this enhancement request to track the enhancement. If > templates do not support XWT's mission, we can close this request. Indeed, UI template is a powerful feature to manage Data and List Data presentation. > > It would be desirable to have some aspect of jface compatibility. For very > simple controls with a single component of content, you can use other > techniques but for list controls, templates make it easier to specify L&F very > succinctly. Sub-capabilities include: > > a) data binding with the ability to specify the source of the binding including > the template parent binding specialization as well as general ancestor/type > locating and element name locating. > > b) base classes that allow the templated parent to be located as well as apply > templates as part of the visual UI rendering process e.g. applyTemplate. > > c) hierarchical resource finding. > > d) ability to not immediately evaluate a template definition in xml > > I think a & c are mostly done in XWT but this needs to be validated. > > Yves, having done this in eface, does XWT have enough underlying machinery to > make this an easier proposition? I implemented a rough template capability > using aspectj ITDs for pivot. The Control Template and Data Template are implemented in eFace. But in XWT, we need more investigations to support this features since the List/ComboBox and ListViewer/ComboBoxViewer are not designed to support any kind of UI form.
Yes, we would need a few more classes inheriting from Composite and Control to make this work. jface viewers (non-nebula) are only about strings and images so overall, templates do not help make those viewers simpler and I think you already cover the direct stuff in xwt today. I don't think there is any help for jface viewers and the underlying specific swt components. There is precedence in swt for "content" controls, ScrollView has the idea of a child control that it manages so even basic swt has notion of what is needed to be robust in this area. Hence, XWT would be getting into the business of having "widgets" it has created and users extend from. Today XWT is really a specification DSL (XAML) for building UI trees--that's a big change from today and I want to confirm that this new element of XWT would fit into XWT. You need a baseline "WPF" set of classes--no way to avoid that--but you can make them generic enough that there are no platform specific issues to worry about. Here are my questions: a) The ability to hold a parsed XML fragment (the template definition) and instantiate it on demand. This means we have to hold a reference to the XWT "loader" that created that component so we can access resources in the hierarchy when the object is instantiated later. You can simulate this by placing XWT in separate XML files, but this reduces the simplicity of XML specification and makes it harder to use. Is this present today or does it need to be added to the XWT loader. b) Databinding: need data binding infrastructure that supports "source" specifications including find ancestor and other types of behavior. Is there a general "extension" mechanism whenever a "{" is encountered for an attribute value, call a specific extension processor? Is this in XWT today? c) One of questions for you is whether PMF is a better way to handle the concept of UI templates? d) Do you know if we write the template facility and it looks like WPF and XAML are there licensing issues? > > The Control Template and Data Template are implemented in eFace. But in XWT, we > need more investigations to support this features since the List/ComboBox and > ListViewer/ComboBoxViewer are not designed to support any kind of UI form.
(In reply to comment #2) > Yes, we would need a few more classes inheriting from Composite and Control to > make this work. jface viewers (non-nebula) are only about strings and images so > overall, templates do not help make those viewers simpler and I think you > already cover the direct stuff in xwt today. I don't think there is any help > for jface viewers and the underlying specific swt components. There is > precedence in swt for "content" controls, ScrollView has the idea of a child > control that it manages so even basic swt has notion of what is needed to be > robust in this area. > > Hence, XWT would be getting into the business of having "widgets" it has > created and users extend from. Today XWT is really a specification DSL (XAML) > for building UI trees--that's a big change from today and I want to confirm > that this new element of XWT would fit into XWT. You need a baseline "WPF" set > of classes--no way to avoid that--but you can make them generic enough that > there are no platform specific issues to worry about. > I totally agree with you. > > Here are my questions: > > a) The ability to hold a parsed XML fragment (the template definition) and > instantiate it on demand. This means we have to hold a reference to the XWT > "loader" that created that component so we can access resources in the > hierarchy when the object is instantiated later. You can simulate this by > placing XWT in separate XML files, but this reduces the simplicity of XML > specification and makes it harder to use. Is this present today or does it need > to be added to the XWT loader. At the current stage, we can keep XML resources in memory and to create UI elements as needed. It is the concept of IUIResource to load a XWT file in memory. So it is not hard to hold a parsed XML fragment and instantiate it on demand. > > b) Databinding: need data binding infrastructure that supports "source" > specifications including find ancestor and other types of behavior. Is there a > general "extension" mechanism whenever a "{" is encountered for an attribute > value, call a specific extension processor? Is this in XWT today? > Now, it is not possible. > c) One of questions for you is whether PMF is a better way to handle the > concept of UI templates? I don't think so. PMF is a development tools, not runtime component. > > d) Do you know if we write the template facility and it looks like WPF and XAML > are there licensing issues? > XAML and WPF are part of Open Specification Promise. It is already validated by Eclipse IP Team. There is no issue to implement in XWT. > > > > > > The Control Template and Data Template are implemented in eFace. But in XWT, we > > need more investigations to support this features since the List/ComboBox and > > ListViewer/ComboBoxViewer are not designed to support any kind of UI form.
> > a) The ability to hold a parsed XML fragment (the template definition) and > > instantiate it on demand. This means we have to hold a reference to the XWT > > "loader" that created that component so we can access resources in the > > hierarchy when the object is instantiated later. You can simulate this by > > placing XWT in separate XML files, but this reduces the simplicity of XML > > specification and makes it harder to use. Is this present today or does it need > > to be added to the XWT loader. > > At the current stage, we can keep XML resources in memory and to create UI > elements as needed. It is the concept of IUIResource to load a XWT file in > memory. So it is not hard to hold a parsed XML fragment and instantiate it on > demand. > I'll look through the code. I need to be able to have the rest of the file parsed and handled except the XML fragment that is a child of the template object. > > > > b) Databinding: need data binding infrastructure that supports "source" > > specifications including find ancestor and other types of behavior. Is there a > > general "extension" mechanism whenever a "{" is encountered for an attribute > > value, call a specific extension processor? Is this in XWT today? > > > > Now, it is not possible. > Alright, that's a bit more work then. I'll start looking through the code to see what might be needed. Thanks!
After playing around, I was able to get delayed evaluation to work fine, the basis of the template mechanism. It will need alot of maturing though to understand how to best fit into SWT. I'll open some related bugs to track the different changes that are needed to support templates and use this issue to track the general capability. a) Allow markup extensions as an extensible mechanism: 335197 b) Allow deferred evaluation of XWT XML nodes to allow playback (this makes XWT playing back much like a factory design pattern): 335199 c) Using (a) to allow more relative source options in data binding mechanisms: 335200
In light of WB, VDE is not supported anymore.
