Bug 323559 - [Riena] Integration with Riena/other enterprise products widgets
Summary: [Riena] Integration with Riena/other enterprise products widgets
Status: NEW
Alias: None
Product: XWT
Classification: Technology
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-25 02:11 EDT by Holger Hoch CLA
Modified: 2013-01-24 15:31 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Holger Hoch CLA 2010-08-25 02:11:14 EDT
Build Identifier: 20100617-1415

Integrating Riena custom widgets i have successfully tried the 'x:Class' and also the 'clr-namespace:...' mechanisms. They are pretty ok for the end user integrating his or her private widgets, but as Riena custom widgets reside in multiple 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.

[copied from newsgroup message #552671]

Reproducible: Always

Steps to Reproduce:
n/a
Comment 1 Yves YANG CLA 2010-08-26 17:06:10 EDT
I have renamed it for the general integration purpose. Please use the prefix [Riena] in the title for other relative issues. 

(In reply to comment #0)
> Build Identifier: 20100617-1415
> 
> Integrating Riena custom widgets i have successfully tried the 'x:Class' and
> also the 'clr-namespace:...' mechanisms. They are pretty ok for the end user
> integrating his or her private widgets, but as Riena custom widgets reside in
> multiple 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"/>
> 

I think there are some overlap on UI and data binding between XWT and Riena. I think it is a confusion for the users because of 2 expressions of Data binding.

I think we should stay on the extensibility of the new namespace management same as our CSS support. Probably, we need to extend the INamespaceHandler to handle the elements. Could you explore this possibility?