Bug 323559

Description Holger Hoch 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