|
|
|
|
|
|
| Re: Consistent duplication of custom xwt UI [message #632684 is a reply to message #632663] |
Wed, 13 October 2010 21:30   |
 Erdal Karaca
Messages: 854
Registered: July 2009 |
Senior Member |
|
|
The namespace handler is part of a higher level framework, but I will try to extract a standalone solution...
Anyways, the problems you will face:
What XWTProfile was used to load the xwt parent form?
What options were used to load the parent form?
Cascade data context to embedded form?
Steps to adapt that solution, snippets:
1. xwt form (called test.xwt):
<Browser x:style="None" xmlns="http://www.eclipse.org/xwt/presentation"
xmlns:x="http://www.eclipse.org/xwt" url="google.com">
</Browser>
2. form:
<SashForm xmlns="http://www.eclipse.org/xwt/presentation"
xmlns:x="http://www.eclipse.org/xwt" xmlns:d="ref-urn">
<Browser x:style="None" url="eclipse.org">
</Browser>
<Composite d:ref="platform:/resource/your-bundle/forms/test.xwt">
<Composite.layout>
<FillLayout />
</Composite.layout>
</Composite>
</SashForm>
A) define namespace handler:
public class RefNamespaceHandler
implements INamespaceHandler {
public void handleAttribute( Widget widget, Object target, String name,
String value ) {
// ...
// find a way to fix the open issues mentioned above...
// options must contain 'target' as container (XWTLoader.CONTAINER_PROPERTY)
url = new URL( value )
XWTForms.loadWithOptions(url, options);
}
}
B) register namespace handler:
XWT.registerNamespaceHandler("ref-urn",
new RefNamespaceHandler());
As xwt does not support embedding external forms, this is rather a workaround... I am using it to modularize the application UI...
|
|
|
|
|
|
|
| Re: Consistent duplication of custom xwt UI [message #638494 is a reply to message #581818] |
Thu, 11 November 2010 13:50 |
St Clair Clarke
Messages: 118
Registered: March 2010 |
Senior Member |
|
|
Hello Yves,
As the lead on e4, I think you should be able to discuss this issue with WindowBuilder developers and come to some agreement that benefit all eclipse users.
WindowBulder is the most advanced tool for building eclipse UI. Now that Google purchased it and literally donate it to all users for free, the number of users will increase exponentially.
For us not to be able to use this tool because of some issues in XWT is a big negative in the future use of e4. Very soon, the word will spread that one cannot use this tool to simply embed one XWT UI in another - such a fundamental part of todays programming. I don't know how many developers out there are still hand-coding. At the most, few!
If you noticed, the number of hits on this topic is sizable - I think it is an indication of its problem. Any one experimenting with e4 will come upon this problem sooner than later.
I implore you and your team to work out this stumbling block with the WindowBuilder team for the sake of all of us. If you know of another tool equivalent or near equivalent to WindowBuilder please let me know.
I am very excited about e4. However, this issue is killing my enthusiasm.
Please re-open this issue and let us move forward.
Currently, I don't think there are many users who are doing significant production development with e4, so I don't think it would be breaking implementation by developers if both your team and WindowBulder team put your heads together to sort this issue in a more amicable manner.
In both your arguments are sound reasoning, but at the end of it all the problem still exists.
FACT: WE THE USERS OF WINDOWBUILDER AND FUTURE DEVELOPERS WITH E4 NEED HELP. PLEASE OBLIGE US. IT WILL BE TO THE BENEFIT OF ALL ECLIPSE USERS.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04368 seconds
] 
Search
Help
Register
Login
Home
