Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Using XWT Views with Riena(Using XWT Views with Riena Controllers, Ridget binding and Riena custom widgets)
Using XWT Views with Riena [message #552671] Fri, 13 August 2010 06:56 Go to next message
Holger Hoch is currently offline Holger HochFriend
Messages: 8
Registered: July 2009
Junior Member
Hi,

I'm currently investigating on how to integrate views created with XWT into Riena. In Riena each view has a corresponding controller and for each widget that has a special 'binding property' an abstract version of that widget, a so called ridget is created, injected into the controller and bound to the control.
That part was quite easy to achieve when using standard swt widgets in XWT by introducing a namespace handler that is responsible for treating special Riena properties like the above mentioned binding property. This results in quite convenient XWT code like

<Composite xmlns="http://www.eclipse.org/xwt/presentation"
xmlns:x="http://www.eclipse.org/xwt"
xmlns:riena="http://www.eclipse.org/riena">
<Label text="First Name:" x:style="SWT.NONE"></Label>
<Text text="" x:style="SWT.BORDER" riena:binding="txtFirst"/>

Integrating Riena custom widgets seems a little more complicated. I have tried the 'x:Class' and also the 'clr-namespace:...' mechanisms successfully. They are pretty ok for the end user integrating his or her private widgets, but as Riena custom widgets reside in different packages this would require the user to have multiple 'clr-namespace:...' definitions which may become quite inconvenient when using multiple custom widgets.
This is not what an end user would expect from Riena - there should be a single namespace for Riena custom attributes and widgets to enable the user to use something like

<riena:SomeRienaWidget ... riena:binding="some_binding_name"/>

for all Riena widgets, no matter where they are definded (of course it would be Rienas responsibility to register the ridgets within the namspace).

XWT MetaclassService seems to be prepared for handling different namespaces, but XWTLoader currently does not allow registering metaclasses for custom namespaces. So I subclassed XWTLoader creating a RienaXWTLoader that does the custom widget registration using

MetaclassService service = getCurrentCore().getMetaclassService();
service.register(SomeRienaCustomWidget.class, "http://www.eclipse.org/riena");

Unfortunately this did not work as the MetaclassManager.public IMetaclass getMetaclass(ILoadingContext context, String name, String namespace) method alwasy returns null if the namespace is not the default namespace or does not start with 'clr-namespace'.
Ok, a MetaclassManager subclass RienaMetaclassManager fixes that and everything seems to work fine in runtime.

But doing this registration the programmatic way during runtime means that the development time editor is not aware of the Riena namespace and widgets.
I think it would be a great enhancement in extendability if we would have an extension point to plug in custom namespaces as that could be used to make the editor aware of custom namespace and widgets at design time and allow Riena (and other frameworks) users to work without explicit definition of packages, classes etc.
If that sounds like a valid approach I could spend some time on this task...

Regards,
--Holger
Re: Using XWT Views with Riena [message #553784 is a reply to message #552671] Wed, 18 August 2010 20:51 Go to previous messageGo to next message
Yves YANG is currently offline Yves YANGFriend
Messages: 688
Registered: July 2009
Senior Member
Hi Holger,

I see you have investigated a lot. The integration with Enterpise
Client/Server solution is our nest step. I'm now working on the integration
of Spring DI/DM (Genini Project in eclipse) with Angelo. Could you create a
bug on this tropic for the further discussion ?

Best regards
Yves YANG
"Holger Hoch" <holger.hoch@compeople.de> wrote in message
news:i42qb7$4ht$1@build.eclipse.org...
> Hi,
>
> I'm currently investigating on how to integrate views created with XWT
> into Riena. In Riena each view has a corresponding controller and for each
> widget that has a special 'binding property' an abstract version of that
> widget, a so called ridget is created, injected into the controller and
> bound to the control.
> That part was quite easy to achieve when using standard swt widgets in XWT
> by introducing a namespace handler that is responsible for treating
> special Riena properties like the above mentioned binding property. This
> results in quite convenient XWT code like
>
> <Composite xmlns="http://www.eclipse.org/xwt/presentation"
> xmlns:x="http://www.eclipse.org/xwt"
> xmlns:riena="http://www.eclipse.org/riena">
> <Label text="First Name:" x:style="SWT.NONE"></Label>
> <Text text="" x:style="SWT.BORDER" riena:binding="txtFirst"/>
>
> Integrating Riena custom widgets seems a little more complicated. I have
> tried the 'x:Class' and also the 'clr-namespace:...' mechanisms
> successfully. They are pretty ok for the end user integrating his or her
> private widgets, but as Riena custom widgets reside in different packages
> this would require the user to have multiple 'clr-namespace:...'
> definitions which may become quite inconvenient when using multiple custom
> widgets.
> This is not what an end user would expect from Riena - there should be a
> single namespace for Riena custom attributes and widgets to enable the
> user to use something like
>
> <riena:SomeRienaWidget ... riena:binding="some_binding_name"/>
>
> for all Riena widgets, no matter where they are definded (of course it
> would be Rienas responsibility to register the ridgets within the
> namspace).
>
> XWT MetaclassService seems to be prepared for handling different
> namespaces, but XWTLoader currently does not allow registering metaclasses
> for custom namespaces. So I subclassed XWTLoader creating a RienaXWTLoader
> that does the custom widget registration using
>
> MetaclassService service = getCurrentCore().getMetaclassService();
> service.register(SomeRienaCustomWidget.class,
> "http://www.eclipse.org/riena");
>
> Unfortunately this did not work as the MetaclassManager.public IMetaclass
> getMetaclass(ILoadingContext context, String name, String namespace)
> method alwasy returns null if the namespace is not the default namespace
> or does not start with 'clr-namespace'.
> Ok, a MetaclassManager subclass RienaMetaclassManager fixes that and
> everything seems to work fine in runtime.
>
> But doing this registration the programmatic way during runtime means that
> the development time editor is not aware of the Riena namespace and
> widgets. I think it would be a great enhancement in extendability if we
> would have an extension point to plug in custom namespaces as that could
> be used to make the editor aware of custom namespace and widgets at design
> time and allow Riena (and other frameworks) users to work without explicit
> definition of packages, classes etc.
> If that sounds like a valid approach I could spend some time on this
> task...
>
> Regards,
> --Holger
Re: Using XWT Views with Riena [message #554988 is a reply to message #553784] Wed, 25 August 2010 06:14 Go to previous messageGo to next message
Holger Hoch is currently offline Holger HochFriend
Messages: 8
Registered: July 2009
Junior Member
Entered as enhancement request
Bug 323559 - custom namespaces for Riena/other enterprise products widgets
Re: Using XWT Views with Riena [message #581283 is a reply to message #553784] Wed, 25 August 2010 06:14 Go to previous message
Holger Hoch is currently offline Holger HochFriend
Messages: 8
Registered: July 2009
Junior Member
Entered as enhancement request
https://bugs.eclipse.org/bugs/show_bug.cgi?id=323559
Previous Topic:Can't make Eclipse e4 product (Standalong application))
Next Topic:XWT.open string
Goto Forum:
  


Current Time: Thu Apr 25 21:52:04 GMT 2024

Powered by FUDForum. Page generated in 0.02861 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top