Getting custom dictionary handle in filter class without @Configured

[Ankit]

Hi

How can we get a handle to a custom dictionary inside a filter without
getting it selected from the UI (using @Configured).

We have a filter which accepts a @Configured property for
KnowledeType, based on the selected knowledge type we want to load a
custom dictionary built with data for the selected knowledge type.

What all have we tried?
We tried to create a new constructor (accepting the knowledge type
arguement) in the CustomDictionary. Called super() and then set the
KnowledgeType property of the class with the one received in the
constructor args.

In the filter we removed the @Configured for the dictionary and
instead added init() method where we call the new constructor with
KnowledgeType argument of the custom dictionary.

This approach is somehow not able to load the custom dictionary and
gives a NullPointer exception since in the custom dictionary the
datastore property remains NULL.

Dictionary code changes:
public DiacriticInsensitiveInValidRepresentationDictionary(){
super();
}

public
DiacriticInsensitiveInValidRepresentationDictionary(KnowledgeType
knowledgeType){
super();
this.knowledgeType = knowledgeType;
}

Filter code

@Configured
KnowledgeType knowledgeType;
private Dictionary validDiacriticInsensitiveRepresentations;
private Dictionary
knownErrorsDiacriticInsensitiveRepresentations;

@Initialize
public void init() {
validDiacriticInsensitiveRepresentations = new
DiacriticInsensitiveValidRepresentationDictionary(knowledgeType);
knownErrorsDiacriticInsensitiveRepresentations = new
DiacriticInsensitiveInValidRepresentationDictionary(knowledgeType);
}

Regards
Ankit

[Kasper Sørensen]

Hi Ankit,

Hmm took me a while to see the problem but now I think I see it. Basically what you need is either a handle to a dictionary or to a datastore (which you then should also pass to the dictionary constructor). Unfortunately I think this is not possible using the current API so we might consider if we should allow for example to inject the configuration object so you can access the datastores and dictionaries from there. On the other hand it may allow a component to do things outside it's intended scope (eg. to open up a connection to another datastore - this kind of behaviour should be handled by the framework IMO).

To make a long story short: Using @Configured Dictionary is the official way for now. There is a hack though, that you can use, but it's not that nice because it touches upon the UI-layer:

AnalyzerBeansConfiguration conf = WindowManager.getInstance().getMainWindow().getConfiguration();

Dictionary dictionary = conf.getReferenceDataCatalog().getDictionary("my dictionary");

Let me know if you have suggestions for a nicer way of doing this.

Regards,

Kasper Sørensen

--
You received this message because you are subscribed to the Google Groups "DataCleaner-dev" group.
To post to this group, send email to datacle...@googlegroups.com.
To unsubscribe from this group, send email to datacleaner-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/datacleaner-dev?hl=en.

[Ankit]

Thanks for your response Kasper.

I think using the hack is quite dirty and does not solve the problem
completely too since I want to get handle to a custom dictionary based
on 2 things we would have: -
1. User selected KnowledgeType
2. Class of the custom dictionary

Using the dictionary name will require that we have some logic in the
filter to get the correct dictionary name somehow.

Solution (Not very clean still):
In ReferenceDataCatalog we introduce a new method to get handle to a
dictionary based on Dictionary class type and KnowledgeType
combination.
We obviously could argue that there can be a scenario where in
configuration we have 2 dictionaries with different names but same
class type and KnowledgeType combination, but I guess that is one of
the non-trivial cases and if such a case exist then we return the
first handle that we can find out.

In case you agree I can try implementing this.

Regards
Ankit

On Dec 23, 2:56 pm, Kasper Sørensen <kas...@eobjects.dk> wrote:
> Hi Ankit,
>
> Hmm took me a while to see the problem but now I think I see it. Basically
> what you need is either a handle to a dictionary or to a datastore (which
> you then should also pass to the dictionary constructor). Unfortunately I
> think this is not possible using the current API so we might consider if we
> should allow for example to inject the configuration object so you can
> access the datastores and dictionaries from there. On the other hand it may
> allow a component to do things outside it's intended scope (eg. to open up a
> connection to another datastore - this kind of behaviour should be handled
> by the framework IMO).
>
> To make a long story short: Using @Configured Dictionary is the official way
> for now. There is a hack though, that you can use, but it's not that nice
> because it touches upon the UI-layer:
>
> AnalyzerBeansConfiguration conf =
> WindowManager.getInstance().getMainWindow().getConfiguration();
> Dictionary dictionary = conf.getReferenceDataCatalog().getDictionary("my
> dictionary");
>
> Let me know if you have suggestions for a nicer way of doing this.
>
> Regards,
> Kasper Sørensen
>

> > datacleaner-d...@googlegroups.com<datacleaner-dev%2Bunsu...@googlegroups.com>
> > .

[Ankit]

While trying this option I see a trouble that KnowledgeType is exposed
at the implementation class level and is private hence we wont be able
to access the value of the field through interface reference even with
reflection. Hence my option stands invalid.

Regards
Ankit

[Kasper Sørensen]

Hi Ankit,

I don't really like that solution because the ReferenceDataCatalog is a generic interface used throughout the framework and such a method would not really make sense when using the framework without the particular plugin/component youre building.

Also it occurs to me that the lifecycle of a Dictionary is actually normally managed by the framework  (in particular, a Dictionary can have @Initialize and @Close methods which will be invoked in the beginning and the end of a job) so just retrieving it from the ReferenceDataCatalog is not a practice I would encourage, because basically you're getting an unmanaged dictionary so you have to manage it's lifecycle yourself. In that case it is actually better to instante it yourself because you then have the concrete dictionary subclass on which you can invoke any lifecycle methods if there are any. 

This may all seem a bit awkward because it is preventing you from just accessing these items and use them. But the intention was always to make the components interchangeable and configurable by the user. In your case this doesn't seem to be nescesary so maybe it should even be considered if the datastore you're using in your Dictionary should even be a regular configured datastore or if it should be something that you make available internally in your plugin-package, ie. as a singleton or something like that?

Lastly I should mention that the previous hack also would allow you to get a hold on the datastore though:

Datastore ds = conf.getDatastoreCatalog().getDatastore("my datastore");

... so you could actually use this for instantiating your dictionary. Only bad thing is that you depend on a string literal for identifying your datastore.

Regards,

Kasper

To unsubscribe from this group, send email to datacleaner-d...@googlegroups.com.