Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] [POSSIBLE VIRUS:###] Re: Bug in Instance Browser in Protege 3.4

Tania Tudorache tudorache at stanford.edu
Mon Mar 30 18:16:59 PDT 2009


Hi Jonathan,

Thank for sending the widget. This is not related to the rename, because 
the widget does not rename the instance, so it makes sense that the the 
listener is not invoked.

I am trying to understand what happens in your widget. So each time the 
setValues method is called in your widget, you compute the value of 
Class Name and set the values of Class Name to that value. By this you 
modify the underlying KB (this change goes also to the server). This 
will trigger other events in the KB - own slot value changed.

The direct instance list tries to stay sorted (in another thread, 
unfortunately). Each time you change the browser text of an instance, 
the instances list will try to resort itself and it seems that there is 
a moment when the selection is the wrong thing and this is when the slot 
widget does the computation.

This might be tricky because it is multi threaded code. Tim wrote that 
code so maybe he will see immediately what is going on. In any case, if 
you will send us offline the code of the slot widget, it will help a lot 
with the debugging.

Tania


Jonathan Carter wrote:
> Hi Tania,
>
> Thanks for getting back to me.
>
> I've tried adding the frameReplaced() event handler in the same way 
> that AbstractSlotWidget used to look.
> I've installed the event handler in the same way, too - in the setup() 
> method and the setInstance() method.
>
> However, I'm still having trouble and as far as I can tell, the 
> frameReplaced() event handler is never being called - I've got a trace 
> line in there that is never written to the command line (as it should).
>
> The problem I'm seeing occurs when my AutoTextWidget is used on a slot 
> that is the display slot. 
> In this case, instead of using the values of the other slots on the 
> form for that instance, it seems that the slot values on the 
> previously selected instance are used when you click instances in the 
> Instance Browser.
>
> I've included my test-harness project and the original widget jar (as 
> it can be run in Protege 3.4 RC1 and 3.4 full and my changes haven't 
> affected the behaviour). Let me know if you need to see the source.
>
> To install the plugin, unpack the 'essential-widgets.zip' ZIP file to 
> your plugins directory. I've also included by updated JAR - just 
> replace the original 'essential-widgets-2.0.jar' with the 
> 'essential-widgets-2.1.jar' to try it with the frameReplaced() handler 
> in place.
>
> To see what's going on, open the project, go to the Instances tab, 
> select 'ThirdClass' in the Class Browser and then select different 
> instances. The Class Name slot should be a string made up of the 
> following pattern "Name=" plus the value of Integer Slot plus "::" 
> plus the value of the SecondClassUsed slot.
>
> In RC1, this will behave such that the name does reflect the slot 
> values but with RC2 and full release, the Name is made up of the right 
> slots but from the wrong instance.
>
> Thanks again for your help - and please don't hesitate to get back to 
> me if you have any questions.
>
> Regards
>
> Jonathan
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________
>
> Jonathan Carter - Head of Technical Architecture
> Enterprise Architecture Solutions Ltd
> Email: jonathan.carter at e-asolutions.com 
> <mailto:jonathan.carter at e-asolutions.com>
> _______________________________________
>
>
> Proud sponsors of The Essential Project.
> The free open-source Enterprise Architecture Management Platform
> www.enterprise-architecture.org <http://www.enterprise-architecture.org/>
> _______________________________________
>
> On 30 Mar 2009, at 23:19, Tania Tudorache wrote:
>
>> Hi Jonathan,
>>
>> It definitely makes sense to add the replaceFrame logic in your slot
>> widget. I don't remember the exact context of why I have removed that
>> piece of code from AbstractSlotWidget. I think it was unnecessary in
>> most widgets, because the widgets already treated the replaceFrame event.
>>
>> The idea is that every widget should handle the frameReplaced event
>> because each may need to do specific things. You probably won't have a
>> performance penalty. If your widget gets the frame replaced event (and
>> the replaced frame was one that it was displaying), then your widget
>> needs to refresh its display. As I mentioned before, a replace is really
>> a delete and a create. If you had listeners attached to the old
>> (replaced) frame, you do not need to detach them and reattach them to
>> the new frame, because there is some code that already does that.
>>
>> I hope this is helpful. If you still have problems, please send me the
>> widget.
>>
>> Tania
>>
>>
>> Jonathan Carter wrote:
>>> Hi Tania,
>>>
>>> I've been having a look at this and it's making sense to me to know
>>> that the frameReplaced() event handler has been removed from
>>> AbstractSlotWidget and therefore my widget - and hence your
>>> recommendation.
>>>
>>> As it's important to my widget to be able to track references to the
>>> instances of other SlotWidgets on the same Form, I'm looking at using
>>> the code that was removed from AbstractSlotWidget to implement my
>>> frameReplaced() event handler. Basically, re-introducing the event
>>> handler to the setInstance() method which then handles the update by
>>> loading the values for the slots into the widgets.
>>>
>>> However, before I do, could you advise me as to whether I am going to
>>> run into more trouble by taking this approach? I'm not clear whether
>>> this was removed from AbstractSlotWidget for performance reasons (as
>>> the comment on the latest edit of the class suggests - and because of
>>> my requirements, I'll have to take the performance hit) or something
>>> more fundamental that I'm missing.
>>>
>>> Thanks very much for your help with this.
>>>
>>> Regards
>>>
>>> Jonathan
>>> _______________________________________
>>>
>>> Jonathan Carter - Head of Technical Architecture
>>> Enterprise Architecture Solutions Ltd
>>> _______________________________________
>>>
>>>
>>> Proud sponsors of The Essential Project.
>>> The free open-source Enterprise Architecture Management Platform
>>> www.enterprise-architecture.org <http://www.enterprise-architecture.org>
>>> _______________________________________
>>>
>>> On 27 Mar 2009, at 22:41, Tania Tudorache wrote:
>>>
>>> Hi Jonathan,
>>>
>>> I cannot reproduce the problem in the InstancesTab.
>>>
>>> One thing that your slot widget has to be aware of is the frame replace
>>> event. When you rename a frame, a lot of things happen in the
>>> background: the frame is actually deleted and a new one is created with
>>> the new name. So, your widget has to listen for the frame replace event
>>> and react accordingly (e.g., refresh the display in the slot widget).
>>> The old frame will disappear or it will be invalid and your widget has
>>> to display the new frame.
>>>
>>> If this information does not help you with the widget, then please send
>>> it to me and let me know how to reproduce the behavior.
>>>
>>> Thanks,
>>> Tania
>>>
>>>
>>>
>>> Jonathan Carter wrote:
>>> Hi Tania,
>>>
>>> Thanks for getting back to me.
>>>
>>> Please do send me the JAR and I will test it out.
>>> It sounds like things have got a bit more complex around the instance
>>> lists. The multi-threaded rendering of the instance list is a very
>>> nice enhancement, by the way. It seems that the issue I'm experiencing
>>> is related to the list or possibly the renaming of the display slot as
>>> the widget is behaving correctly if I open an Instance Editor as a
>>> separate window.
>>>
>>> I don't want to distract you with it but if it helps to have a copy of
>>> my widget for local testing, please let me know.
>>>
>>> Thanks again
>>>
>>> Regards
>>>
>>> Jonathan
>>> _______________________________________
>>>
>>> Jonathan Carter - Head of Technical Architecture
>>> Enterprise Architecture Solutions Ltd
>>> _______________________________________
>>>
>>>
>>> Proud sponsors of The Essential Project.
>>> The free open-source Enterprise Architecture Management Platform
>>> www.enterprise-architecture.org <http://www.enterprise-architecture.org>
>>> _______________________________________
>>>
>>> On 27 Mar 2009, at 01:18, Tania Tudorache wrote:
>>>
>>> Hi Jonathan,
>>>
>>> Thank yo very much for the detailed bug report. We have done indeed some
>>> bug fixes in the direct instances list, which obviously do not work.
>>>
>>> We'll fix this for the patch release. Once we make the fix, I can send
>>> you a jar, so that you can test it.
>>>
>>> The rename operation is very tricky in the new generation of Protege 3.4
>>> (after b130), because a rename actually means a delete and a creation.
>>> That is why several widgets started having refresh problems, and it
>>> seems, also selection problems. We tried to get all these bugs, but we
>>> missed some.
>>>
>>> We'll keep you updated.
>>>
>>> Tania
>>>
>>>
>>> Jonathan Carter wrote:
>>> Hi
>>>
>>> I'd like to report what I think is a bug in the Instance Browser that
>>> was introduced between RC1 and RC2 and is still there in the full
>>> release of Protege 3.4.
>>>
>>> When I create the first instance of a class in the Instance all seems
>>> well, (see [Screenshot 1]). However, when I create a second instance,
>>> both of the instances in the Instance Browser are automatically
>>> selected (see [Screenshot 2]). Now I am not sure which one of these is
>>> actually selected.
>>> For most cases this actually seems to have little effect - more of a
>>> glitch, but I now suspect that the "more than 1 instance selected" bug
>>> reflects a bigger underlying problem with the recent changes made to
>>> the Instance Browser.
>>>
>>> In particular, I have a custom slot widget that I have written that is
>>> now behaving very erratically since the change to the Instance Browser
>>> was made. This slot widget is a key part of The Essential Project
>>> toolset and provides automatic naming of instances (or any string
>>> slot) based on a pattern of the browser text values of other slots on
>>> the same form - configurable from the Form widget controls. Perhaps it
>>> would help if I explained a bit more about how this Slot Widget works.
>>>
>>> The widget is designed to work as a user data-entry labour-saving
>>> device and so operates in the client (using listeners on other slot
>>> widgets) rather than driving the auto-text from the underlying
>>> knowledge base. This makes it easy to run on stand-alone and
>>> client-server mode and means that the additional overhead of it
>>> calculating the automatic text is removed from the underlying
>>> knowledge base. All it's activity is scoped to the parent FormWidget
>>> of the slot widget in question but since RC2, this widget (which has
>>> been working fine since Protege 3.1) is gathering text from slots on
>>> other instances of the same class - and I believe that this is where
>>> the "more than 1 instance selected" is more serious than it at first
>>> appears. It seems that my widget is now reading slot values for one
>>> instance from another instance of the same class. This shouldn't be
>>> possible and is worrying.
>>>
>>> Interestingly, if I create new instances via an Instance Slot Widget
>>> (rather than in the Instance Browser), things behave normally and as
>>> expected with my auto text widget.
>>>
>>> I noticed that there have been some changes introduced
>>> into DirectInstancesList.java in the time frame between RC1 and RC2.
>>>
>>> Just to be clear, Protege 3.4 RC1 is fine, RC2 and full release have
>>> this "bug".
>>>
>>> I'd be more than happy to work together on resolving this (whether
>>> it's my widget or whatever) offline to get to the bottom of this as
>>> quickly as possible.
>>>
>>> Thanks very much
>>>
>>> Regards
>>>
>>> Jonathan
>>>
>>> [Screenshot 1]
>>> ___________________
>>>
>>> [Screenshot 2]
>>>
>>> ____________________
>>> Jonathan Carter - Head of Technical Architecture
>>> Enterprise Architecture Solutions Ltd
>>> _______________________________________
>>>
>>>
>>> Proud sponsors of The Essential Project.
>>> The free open-source Enterprise Architecture Management Platform
>>> www.enterprise-architecture.org 
>>> <http://www.enterprise-architecture.org/>
>>> _______________________________________
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> protege-discussion mailing list
>>> protege-discussion at lists.stanford.edu 
>>> <mailto:protege-discussion at lists.stanford.edu>
>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>
>>> Instructions for unsubscribing:
>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>>
>>>
>>> _______________________________________________
>>> protege-discussion mailing list
>>> protege-discussion at lists.stanford.edu 
>>> <mailto:protege-discussion at lists.stanford.edu>
>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>
>>> Instructions for unsubscribing:
>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> protege-discussion mailing list
>>> protege-discussion at lists.stanford.edu 
>>> <mailto:protege-discussion at lists.stanford.edu>
>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>
>>> Instructions for unsubscribing:
>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>>
>>>
>>> _______________________________________________
>>> protege-discussion mailing list
>>> protege-discussion at lists.stanford.edu 
>>> <mailto:protege-discussion at lists.stanford.edu>
>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>
>>> Instructions for unsubscribing:
>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> protege-discussion mailing list
>>> protege-discussion at lists.stanford.edu 
>>> <mailto:protege-discussion at lists.stanford.edu>
>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>
>>> Instructions for unsubscribing: 
>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>>
>>
>> _______________________________________________
>> protege-discussion mailing list
>> protege-discussion at lists.stanford.edu 
>> <mailto:protege-discussion at lists.stanford.edu>
>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>
>> Instructions for unsubscribing: 
>> http://protege.stanford.edu/doc/faq.html#01a.03
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> protege-discussion mailing list
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>   




More information about the protege-discussion mailing list