I have created a few information views allowing the name to be auto-generated by the model. The names jump around, rename themselves, in the Instance Browser.
The names end up mixed up rather randomly.
Example:
ClassRoster::LMSView has the name LMSView and is a refinement of ClassRoster
ClassRoster::PortalView has the PortalView and is a refinement of ClassRoster
If I click on the names in the Instance Browser, the names will swap back and forth. ClassRoster::LMSView will point to the instance with name PortalView and visa versa.
I'm running Protege 3.4 (final release) on MySQL in multi-user mode.
Jim
Information_View bug
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Jim,
Thanks for letting us know about this. We are looking into this now, have reproduced the bug and have identified that a code change introduced into Protege after 3.4 RC1 is causing our widget some problems. We're working to resolve this.
I would like to suggest that you download Protege 3.4 RC1 and install it alongside your Protege 3.4 full release.
You won't have to completely re-do all the installation, as your database configuration and metaproject (for the server) can be used with RC1.
However, you should deploy the Essential Widgets to the 3.4 RC1 plugins folder, turn off the Sort Classes in Class Browser preference and copy the metaproject that you have created already to the default location in your new 3.4 RC1 installation.
That is:
- Copy <protege 3.4>/examples/server/metaproject.*
- To <protege 3.4_rc1>/examples/server/
overwriting the default metaproject.pprj, metaproject.pins and metaproject.pont files.
In addition, you will need to re-deploy the MySQL JDBC driver to the RC1 installation in its root directory.
Start Protege 3.4 RC1 and open your Essential Architecture Manager repository project. This will continue to use the database that you have already set up and it's likely that when you browse you Information Views, this version will repair the names that have gone bad.
Thanks again for bringing this issue to our attention and apologies for the trouble it has caused.
Hopefully, working with Protege 3.4 RC1 will help get you going in the meantime.
Don't hesitate to let us know if you have any issues or queries about the suggested approach.
Jonathan
Thanks for letting us know about this. We are looking into this now, have reproduced the bug and have identified that a code change introduced into Protege after 3.4 RC1 is causing our widget some problems. We're working to resolve this.
I would like to suggest that you download Protege 3.4 RC1 and install it alongside your Protege 3.4 full release.
You won't have to completely re-do all the installation, as your database configuration and metaproject (for the server) can be used with RC1.
However, you should deploy the Essential Widgets to the 3.4 RC1 plugins folder, turn off the Sort Classes in Class Browser preference and copy the metaproject that you have created already to the default location in your new 3.4 RC1 installation.
That is:
- Copy <protege 3.4>/examples/server/metaproject.*
- To <protege 3.4_rc1>/examples/server/
overwriting the default metaproject.pprj, metaproject.pins and metaproject.pont files.
In addition, you will need to re-deploy the MySQL JDBC driver to the RC1 installation in its root directory.
Start Protege 3.4 RC1 and open your Essential Architecture Manager repository project. This will continue to use the database that you have already set up and it's likely that when you browse you Information Views, this version will repair the names that have gone bad.
Thanks again for bringing this issue to our attention and apologies for the trouble it has caused.
Hopefully, working with Protege 3.4 RC1 will help get you going in the meantime.
Don't hesitate to let us know if you have any issues or queries about the suggested approach.
Jonathan
Essential Project Team
-
jason.powell
- Posts: 32
- Joined: 04 Feb 2009, 15:01
Jim,
Until this problem is resolved, we believe that you have a couple of options.
The first option would be to consider which is more important to you at this particular moment; EAM or the Protege Collaboration Panel? You can still work collaboratively in EAM without the Collaboration Panel - we have done so very effectively and it certainly isn't a pre-requisite for working multi-user by any means. So, for now, you could choose to use EAM without the Collaboration Panel. Now, it may be that you are using the Collaboration Panel of Protege for other projects, but if not, this approach would be our recommendation.
Otherwise, the second option would be to disable the AutoText wherever you notice this errant behaviour (unfortunately, it is not restricted to Information Views; we have reproduced the bug in other areas of the model that use auto-naming, e.g. Technology Products). With this approach, it would mean that you will have to manually maintain the names of your Information_View instances, but this is quite manageable, depending upon the scale and scope of your model at this time (we would also recommend that you continue to observe the "ConceptName::ViewName" naming convention so that your model is unaffected when the issue is resolved).
To disable AutoText for the affected slots, you should firstly click on the Project | Configure... menu item in Protege, place a tick next to the "FormsTab" entry in the displayed list and click "OK". You should now have a Forms tab displayed in Protege. Next, select the affected Class (e.g. Information_View) in the Class Browser and then click on the Forms tab. From here, in the right-hand pane, you can change the type of form widget used for the "name" field from "AutoTextWidget" to "TextFieldWidget" using the drop-down list box in the top right corner of the Form Editor (see illustration below). Note that it seems that it is only slots that are used as the "Display Slot" (see top of Form Editor) that are affected by this bug and so it should not be necessary to make this change for all slots that use the AutoTextWidget.
We hope this helps and, again, we are doing our very best to resolve this issue as soon as possible.
Jason
(Essential Project Team)
Until this problem is resolved, we believe that you have a couple of options.
The first option would be to consider which is more important to you at this particular moment; EAM or the Protege Collaboration Panel? You can still work collaboratively in EAM without the Collaboration Panel - we have done so very effectively and it certainly isn't a pre-requisite for working multi-user by any means. So, for now, you could choose to use EAM without the Collaboration Panel. Now, it may be that you are using the Collaboration Panel of Protege for other projects, but if not, this approach would be our recommendation.
Otherwise, the second option would be to disable the AutoText wherever you notice this errant behaviour (unfortunately, it is not restricted to Information Views; we have reproduced the bug in other areas of the model that use auto-naming, e.g. Technology Products). With this approach, it would mean that you will have to manually maintain the names of your Information_View instances, but this is quite manageable, depending upon the scale and scope of your model at this time (we would also recommend that you continue to observe the "ConceptName::ViewName" naming convention so that your model is unaffected when the issue is resolved).
To disable AutoText for the affected slots, you should firstly click on the Project | Configure... menu item in Protege, place a tick next to the "FormsTab" entry in the displayed list and click "OK". You should now have a Forms tab displayed in Protege. Next, select the affected Class (e.g. Information_View) in the Class Browser and then click on the Forms tab. From here, in the right-hand pane, you can change the type of form widget used for the "name" field from "AutoTextWidget" to "TextFieldWidget" using the drop-down list box in the top right corner of the Form Editor (see illustration below). Note that it seems that it is only slots that are used as the "Display Slot" (see top of Form Editor) that are affected by this bug and so it should not be necessary to make this change for all slots that use the AutoTextWidget.
We hope this helps and, again, we are doing our very best to resolve this issue as soon as possible.
Jason
(Essential Project Team)
Essential Project Team
Thanks Jason.
I'll discuss this with the other Architects. We are mostly using the Collaboration panel to gather meta-discussions about how we want to use various parts of the EAM.
One more question:
Do I need to downgrade the server version of Protege and all of the clients, or just the server version?
I'll discuss this with the other Architects. We are mostly using the Collaboration panel to gather meta-discussions about how we want to use various parts of the EAM.
One more question:
Do I need to downgrade the server version of Protege and all of the clients, or just the server version?
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Unfortunately, you would have to downgrade all the client installations - it's a client-side issue that we have at the moment.
I would also recommend down-grading the server so that you can safely run the client on the server to perform admin tasks etc. (Although it's possible / likely that the RC1 clients will work with a 3.4 (full) server - but we haven't tried that)
Jonathan
I would also recommend down-grading the server so that you can safely run the client on the server to perform admin tasks etc. (Although it's possible / likely that the RC1 clients will work with a 3.4 (full) server - but we haven't tried that)
Jonathan
Essential Project Team
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Just a quick post to let you know that we have just released an updated version of Essential Architecture Manager which resolves the widget bug with Protege 3.4
You can download a patch update of the Essential Widgets to use with your Protege 3.4 installations or take the new release of Essential Architecture manager which also includes an update to the Essential Viewer analysis and reporting tool.
Assuming that you have not removed your existing Protege 3.4 full release (i.e. NOT RC1), you can drop the widgets into the /plugins folder of your full release on all your clients and servers, replacing the entire com.enterprise_architecture.essential.widgets folder.
Your repository Protege project will be compatible with the new version of Protege.
The updates are available from the downloads page
Jonathan
You can download a patch update of the Essential Widgets to use with your Protege 3.4 installations or take the new release of Essential Architecture manager which also includes an update to the Essential Viewer analysis and reporting tool.
Assuming that you have not removed your existing Protege 3.4 full release (i.e. NOT RC1), you can drop the widgets into the /plugins folder of your full release on all your clients and servers, replacing the entire com.enterprise_architecture.essential.widgets folder.
Your repository Protege project will be compatible with the new version of Protege.
The updates are available from the downloads page
Jonathan
Essential Project Team
