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] Bug in Instance Browser in Protege 3.4

Tania Tudorache tudorache at stanford.edu
Mon Mar 30 15:19:42 PDT 2009


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
> _______________________________________
>
> 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
> _______________________________________
>
> 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
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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