| OSGi: loading an FXML file from another bundle [message #1131453] |
Thu, 10 October 2013 10:40  |
Eclipse User |
|
|
|
Hi,
I'm working in an OSGi environment where I would like to have a bundle A that provides a central service for loading FXML files. This service should be used by bundle B to load (and do validation, error handling,...) an FXML file from bundle B.
Is that possible with the current implementation of the FXMLLoaderFactory class? The loadRequestorRelative() method does not work as the requesting class is my service from bundle A, but the FXML is located in bundle B.
As a workaround, I'm using the InjectingFXMLLoader class which allows me to specify the requester class.
Of course, it may not be advised to provide a central service like this. Maybe each bundle should have its own utility for loading FXML files. Are there any best practices?
Thanks,
Uwe
|
|
|
|
| Re: OSGi: loading an FXML file from another bundle [message #1132615 is a reply to message #1132561] |
Fri, 11 October 2013 05:14  |
| Eclipse User |
|
|
|
Hi Tom,
I mentioned the validation and error handling simply to give you some context for why we want a centralised FXML loader. But these details are not relevant for the actual problem. Sorry if that was misleading.
Our current implementation looks similar to this:
public class FXMLLoaderService {
@Inject
private IEclipseContext context;
public Node load(final Class<?> requester, final String filePath) {
FXMLBuilder<Node> builder = InjectingFXMLLoader.create(context, requester, filePath);
Node node = builder.load();
return node;
}
}
The file path is a location within the bundle that contains the requester class.
In your FXMLService example, the loaderFactory.loadBundleRelative() method would use a path relative to the bundle in which the FXMLService is located, I believe. As a consequence, all the FXML files would need to be stored in the same bundle as the FXMLService class. But we want to specify a relative path for the bundle that uses this service such that the FXML files can distributed among multiple bundles.
Apart from that, your error handler extension would be a nice new feature. 
Thanks,
Uwe
|
|
|
| Re: OSGi: loading an FXML file from another bundle [message #1132634 is a reply to message #1132615] |
Fri, 11 October 2013 05:26 |
| Eclipse User |
|
|
|
On 11.10.13 11:14, Uwe San wrote:
> Hi Tom,
>
> I mentioned the validation and error handling simply to give you some
> context for why we want a centralised FXML loader. But these details are
> not relevant for the actual problem. Sorry if that was misleading.
>
>
> Our current implementation looks similar to this:
>
>
> public class FXMLLoaderService {
>
> @Inject
> private IEclipseContext context;
>
> public Node load(final Class<?> requester, final String filePath) {
>
> FXMLBuilder<Node> builder = InjectingFXMLLoader.create(context,
> requester, filePath);
> Node node = builder.load();
> return node;
> }
> }
>
>
> The file path is a location within the bundle that contains the
> requester class.
>
> In your FXMLService example, the loaderFactory.loadBundleRelative()
> method would use a path relative to the bundle in which the FXMLService
> is located, I believe. As a consequence, all the FXML files would need
> to be stored in the same bundle as the FXMLService class. But we want to
> specify a relative path for the bundle that uses this service such that
> the FXML files can distributed among multiple bundles.
No this is the IContextFunction trick, the loadFactory is created in the
correct context (IEclipseContext wise) and OSGi-BundleContext wise so it
would load from the requestor bundle!
Please note that each requestor would get its distinct instance of
FXMLLoaderService, that's what IContextFunctions are good for ;-)
>
> Apart from that, your error handler extension would be a nice new
> feature. :)
>
I still ask myself if FXMLLoaderBuilder could not serve as what you try
to do with the service, or how we'd have to modify it to suite your needs.
Tom
|
|
|
|
| Re: OSGi: loading an FXML file from another bundle [message #1137096 is a reply to message #1132634] |
Mon, 14 October 2013 04:56 |
| Eclipse User |
|
|
|
On 11.10.13 11:26, Tom Schindl wrote:
> On 11.10.13 11:14, Uwe San wrote:
>> Hi Tom,
>>
>> I mentioned the validation and error handling simply to give you some
>> context for why we want a centralised FXML loader. But these details are
>> not relevant for the actual problem. Sorry if that was misleading.
>>
>>
>> Our current implementation looks similar to this:
>>
>>
>> public class FXMLLoaderService {
>>
>> @Inject
>> private IEclipseContext context;
>>
>> public Node load(final Class<?> requester, final String filePath) {
>>
>> FXMLBuilder<Node> builder = InjectingFXMLLoader.create(context,
>> requester, filePath);
>> Node node = builder.load();
>> return node;
>> }
>> }
>>
>>
>> The file path is a location within the bundle that contains the
>> requester class.
>>
>> In your FXMLService example, the loaderFactory.loadBundleRelative()
>> method would use a path relative to the bundle in which the FXMLService
>> is located, I believe. As a consequence, all the FXML files would need
>> to be stored in the same bundle as the FXMLService class. But we want to
>> specify a relative path for the bundle that uses this service such that
>> the FXML files can distributed among multiple bundles.
>
> No this is the IContextFunction trick, the loadFactory is created in the
> correct context (IEclipseContext wise) and OSGi-BundleContext wise so it
> would load from the requestor bundle!
I have to correct myself, I think this information was wrong the
OSGi-Context might be the wrong one :-( because the requestor is the
service impl :-(
Tom
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05705 seconds
Home