University of Namur & University of Stockholm ProjectProject specific questions and answers from the project at the University of Namur & University of Stockholm .RE: Is it possible to link a certain amount of instances to each other, soWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109352014-04-11T12:37:32Z2014-04-11T12:37:32ZCurrently we do have limitations here on platform level. See http://www.adoxx.org/live/faq/-/message_boards/message/17008?p_p_auth=feNHVr3A. We have defined a CR on that for our development team and I keep you posted as soon as I have news on that.Wilfrid Utz2014-04-11T12:37:32ZIs it possible to link a certain amount of instances to each other, so thathttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1107942014-04-11T12:37:22Z2014-04-11T12:37:22ZIs it possible to link a certain amount of instances to each other, so that when one moves, the other move as well ?2014-04-11T12:37:22ZRE: Is it possible to somehow add scripts to a library, when exporting a liWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109312014-04-11T12:37:06Z2014-04-11T12:37:06ZYes, this is possible. Script can be added to the library in the "File Management" throught the Development Toolkit (Extras -> File Management). These scripts are accessible using the "db:\\" path name in your calls. (see the XML framework on top)+<br /><br />See video. <a href="http://www.youtube.com/watch?v=ILI1FPyRMuI">http://www.youtube.com/watch?v=ILI1FPyRMuI</a>Wilfrid Utz2014-04-11T12:37:06ZIs it possible to somehow add scripts to a library, when exporting a librarhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109272014-04-11T12:36:50Z2014-04-11T12:36:50ZIs it possible to somehow add scripts to a library, when exporting a library on the admin tool ?2014-04-11T12:36:50ZRE: Is it possible to check if an instance is inside another instance on anWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1107892014-04-11T12:36:18Z2014-04-11T12:36:18ZThis is possible through an implicit relation called "Is inside" that is provided at platform level. The prerequesite is that the container class is inherited from "__D_aggregation__". The "Is inside" relation auto-connects objects that are inherited as instances from any class (inherited from "__D_construct__") with the respective container. This can be validated using e.g. AQL queries.Wilfrid Utz2014-04-11T12:36:18ZIs it possible to check if an instance is inside another instance on an ADOhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109222014-04-11T12:35:54Z2014-04-11T12:35:54ZIs it possible to check if an instance is inside another instance on an ADOscript level ?2014-04-11T12:35:54ZRE: Is it possible to implement a new export, import function to XML ? LikeWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109202014-04-11T12:35:35Z2014-04-11T12:35:35ZFor another project we develop together with the guys from University of East London a plugin framework in ADOxx for developing custom XML export. The basic idea is that each XML transformation plugin is an XSL file that provides the transformation logic. Please find attached the implemented resource as a link to a forum post.<br />In this case a default set of transformation plugins can be provided within the library and additionally, the user can develop and provide new plugins as required.<br /><br />Related Forum Post: <a href="http://www.adoxx.org/live/faq/-/message_boards/message/61668">http://www.adoxx.org/live/faq/-/message_boards/message/61668</a>Wilfrid Utz2014-04-11T12:35:35ZIs it possible to implement a new export, import function to XML ? Like crehttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1107822014-04-11T12:35:14Z2014-04-11T12:35:14ZIs it possible to implement a new export, import function to XML ? Like creating an addon for ADOxx or something.2014-04-11T12:35:14ZRE: Variant Management in ADOxxWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109162014-04-11T12:34:42Z2014-04-11T12:34:42Z<span style="font-size: 12px"></span>a) Updated all relation classes to have a "__Variants__" attribute. This attribute is important to store the display options in different variants<br />b) Added a new modelattribute as a table to store all deleted relation instances and re-create them. The implict way through the UpdateAction event is regarded as too vulnerable and did result in unpredictable behaviour.<br /><span style="font-size: 12px"></span>c) Update the event listeners in external coupling. Please find attached the extract from there as a file.<br />d) Commented issues and open items where necessary and marked the code I changedWilfrid Utz2014-04-11T12:34:42ZRE: Variant Management in ADOxxWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109142014-04-11T12:33:37Z2014-04-11T12:33:37ZPlease find below some results from the investigation:<br />+ the default models are created in the bottom right corner. I am not sure if this is on purpose or I missed something in the scripts.<br />+ in contrast to the last version discussed, you did add instances to different views, correct? So the effect observed is actual logical having in mind the implementation of the catch mechanisms for the DeleteRelatioInstance event:<br /><br />a) in a first step the deletion of the class instance is cancelled<br />b) since deletion of the relations happen before, that and have already taken place, the wrongly deleted relation class instances are re-created.<br />c) Since some relations class instances exist only in other variant views, the re-creation also re-creates the relation class instances in other views such as the ones in view 3 where the same goal is related to the role that results in the log behavior described.<br /><br />To overcome this issues, I see 2 different options:<br />1) Make sure that only unique names exist per view - which means reverting to the last discussed version when it comes to naming of objects<br />2) Update the relation class instance recovery implementation to include also the variant visualization.Wilfrid Utz2014-04-11T12:33:37ZRE: Variant Management in ADOxxhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109122014-04-11T12:32:45Z2014-04-11T12:32:45ZIn the section "DeleteRelationInstance", relationclassid, frominstanceid, toinstanceid take some strange values...<br /><br />I'll tell you what you need to do to recreate the event and you'll be able to see the strange things in the log in the modelling environment.<br /><br />So first got to the fourth variant (ctrl+4). Then I try to delete the "Goal1", which is an element that shouldn't be able to be deleted. So the start is correct in the log. Dependency Links and to/from goals, but at one point there are Roles that appear in the log and I don't understand why... There is absolutely no link between a role and a goal in this variant.<br /><br />Basically what I want to happen in variants 3 and 4 (crtl+3 and ctrl+4) is to create some models that appear at the start and that can't be deleted by an user, as we did in variants 1 and 2.2014-04-11T12:32:45ZVariant Management in ADOxxWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109102014-04-11T12:23:56Z2014-04-11T12:18:54ZAttached a generic implementation of the variant management approach in ADOxx on a generic level to substitute for the view-based implementation we did discuss earlier. Please find a brief summary of the implementation below:<br /><br /><strong>a) Views vs. Variants:</strong><br />The main difference between the two approaches is that views related to the metamodel/class level and variants can be even on instance/object level. Based on this definition, we can define variants similiar as views in the "Modi" attribute, also use the INCL and EXCL statement to perform certain view restrictions on class level and additionally have also variants on instance/model level. In order to prepare your implementation for this change, <br />i ) the current views have to be transformed to variants (they could also co-exist, but I do not think that in your scenario this is necessary). For my generic implementation I added 3 variants, the code would look like that in the "Modi" attribute<br /><br /><div class="code"><span class="code-lines">1</span>MODELTYPE "Model" from:none attrrep:"DummyModelAttrRep"<br /><span class="code-lines">2</span>INCL "Car"<br /><span class="code-lines">3</span>INCL "is related to"<br /><span class="code-lines">4</span>VARIANT "A"<br /><span class="code-lines">5</span>VARIANT "B"<br /><span class="code-lines">6</span>VARIANT "C"<br /></div><strong><br />ii) Variant Setting Persistence on Instance Level</strong><br />Add a global attribute for all classes and relation to allow for instances to store information to which variant they belong and where they should be position for certain variants. This also means that the previously communicated restriction that one instance can only exist in one variant is actually not correct and you could potentially have the same instance in different variants on different positions. For the implementation and simplicity reasons I did keep the instance <-> variant relation on a 1 to 1 level. <br />The attribute needed is of type STRING and should be named "__Variants__". For modelling classes, just add this attribute to the top level class (__D-construct__ and __S-construct__), for relation classes, you need to add the attribute manually to each class.<br /><br /><br /><strong>b) Variants Switch</strong><br />Variants are accessible in the "View" menu in the sub-element "Variants". A default variant is added named <No variant> in order to make sure that models without variants can still be imported. To make thinks more obvious, this could also be added to the quickaccess bar as specific buttons.<br /><br /><strong>c) Limitation Variants in Table View</strong><br />A limitation of the approach is that the table view does not support variants and will always show all instances created in all variants<br /><br /><strong>d) Interaction update: </strong><br />In order to make sure that newly created instances are only added to the currently active variant, 2 AdoScripts are needed to set the Position/Positions attribute correctly and append the "iuv:0" statement to the end. This statement says that the object should only be available in the current view but not in the others. <br />This implementation would actually overwrite the settings of variants. If you want to remove the settings menu entry for variants you can add ACTION "variants.options" visible:0 to the "Default Settings" Library attribute.<br /><br /><strong>e) Default model creation: </strong><br />to create the default model in different variants, please see the AdoScript attached. The script is triggered for the event "AfterCreateModelWindow". Since this event is triggered every time you open a model, an additional flag as a modelattribute has been added to check whether the model has been already initialized. Model attribute "Is initialized" defined as an attribute of abstract class "__ModelTypeMetaData__" and referenced in "Modi"<br />The generic approach would create 3 different variant defaults, showing the letter of the variant as a model. An extension would be, to reuse objects in different variants, if you are interested in this approach I could extend the sample if needed.<br /><br />Please find attached the ABL file that contains the 3 AdoScript that are triggered by the event in the library, for your reference also as separete files. To provide some traceability and debugging in the scripts I added the Debug shell and also the Debug Logging Window.<br /><br />When setting up variant views in amodel programmatically, please consider to switch between variants also programmatically to persist the changes in the "__Variants__" attribute. The following snipplet will between the default variant ("") and the to be switched, also possible during the switch event.<br /><br /><div class="code"><span class="code-lines"> 1</span>CC "Modeling" SET_ACTIVE_VARIANT variant:"" quiet<br /><span class="code-lines"> 2</span>CC "Modeling" SET_ACTIVE_VARIANT variant: (activeVariant) quiet<br /><span class="code-lines"> 3</span><br /><span class="code-lines"> 4</span>ON_EVENT "BeforeExtSetVariant" {<br /><span class="code-lines"> 5</span> IF (newvariant != "") {<br /><span class="code-lines"> 6</span> # WORKAROUND: Switch programmatically to empty before going to new variant<br /><span class="code-lines"> 7</span> CC "Modeling" SET_ACTIVE_VARIANT variant:"" quiet<br /><span class="code-lines"> 8</span> }<br /><span class="code-lines"> 9</span>}<br /><span class="code-lines">10</span><br /><span class="code-lines">11</span><br /><span class="code-lines">12</span>.<br /></div>Wilfrid Utz2014-04-11T12:18:54ZRE: Error messages ModificationsWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109082014-04-11T12:15:57Z2014-04-11T12:15:57ZThis is system/platform message and can not be configured or customized yet. Potentially it would be possible to catch the event beforehand and provide a custom message.Wilfrid Utz2014-04-11T12:15:57ZError messages Modificationshttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1107732014-04-11T12:15:31Z2014-04-11T12:15:31ZI have a question regarding the [amodraw-05] error message. Is the message automatically generated or can I change parts of this error message ?2014-04-11T12:15:31ZRE: Default models appear for different modes/variants of same modelWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109042014-04-11T12:14:57Z2014-04-11T12:14:12ZAfter further analysis, does this represent your scenario:<br /><br /><strong>Interaction process - Default Model</strong><br />a) User creates a new model of the single modeltype that is defined for your library<br />b) A default model is created, this model has different views which are potentially completely different from each other, but build on an overlapping set of concepts. This means that the views are not distinct from each other when it comes to defined classes and relations<br />c) The user should have the chance to change views and see different representations graphically. The level on how this views are related to each other (e.g. can 1 instance be potentially in 2 views?) is not yet clear.<br /><br />I do believe that the views are not appropriate since they target a view on the metalevel as a class and relation filter. I am currently thinking that we could make use of the VARIANT concept in ADOxx to realize this approach. This would lead to the situation, that we would initialize the default model for all views/variants once and set the variant relation accordingly when creating. When switch views/variants, the model is redrawn and the representation is realized.Wilfrid Utz2014-04-11T12:14:12ZRE: Default models appear for different modes/variants of same modelhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1107702014-04-11T12:12:45Z2014-04-11T12:12:45ZI've tried with the "AfterCreateModelWindow" event, but I still get the default instances in all the modes and not only in the two modes I want those default instances to appear.<br />Basically what I want to do, is that when a user creates a new model, some default non deletable instances appear in 2 of the 6 modes that come with this model.2014-04-11T12:12:45ZRE: Default models appear for different modes/variants of same modelWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1109012014-04-11T12:12:06Z2014-04-11T12:12:06ZThe reason for this issue relates to the the components/messageports both commands/events come from. The event "CreateModel" is an even that is triggered by the "Core" and essentially is usable with a model representation in the graphical editor (you can potentially create a lot of models without the UI interaction).<br />The AdoScript command you use to retrieve the the VIEW MODE relates to the Modelling messageport that relates to the availability of a mdoel in the Modelling Editor to perform certain commands. <br /><br />The event that could potentially be used for your implementation is the "AfterCreateModelWindow", which is triggered everytime a model is loaded in an editor, so you would need to have a toggle if the code should only be executed once.Wilfrid Utz2014-04-11T12:12:06ZDefault models appear for different modes/variants of same modelhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1107652014-04-11T12:11:19Z2014-04-11T12:11:19ZI'm trying to have default models only appear for different modes. The thing is, I can't seem to check the mode in the CreateModel event and use an Execute file, without getting error messages.<br />Here is what I got:<br /><div class="code"><span class="code-lines">1</span>SETG nCreateModelID: (modelid)<br /><span class="code-lines">2</span>CC "Modeling" GET_VIEW_MODE modelid: (nCreateModelID)<br /><span class="code-lines">3</span>SET modelview: (modename)<br /><span class="code-lines">4</span><br /><span class="code-lines">5</span>IF (modelview = "ModeName") {<br /><span class="code-lines">6</span> EXECUTE file: ("PATH for the default model for this mode")<br /><span class="code-lines">7</span>}<br /></div><br /><br />I get an error on the IF condition, which might be because the event happens after the model has been created. Any tip on how to avoid this problem ?2014-04-11T12:11:19ZRE: AfterCreateModelingNodeWilfrid Utzhttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1107592014-04-11T12:08:04Z2014-04-11T12:08:04ZThe origin parameter is set as an integer parameter directly in the event and can be used to implement the scenario you describe. Please find a little code snipplet attached, the INFOBOX statement needs to be replaced with your code respectively <br />As for any other parameter available in an event, please consider that you need to create a local/global variable if you want to have access to the parameter in an externally implemented AdoScript file.<br /><br /><div class="code"><span class="code-lines"> 1</span>ON_EVENT "AfterCreateModelingNode" {<br /><span class="code-lines"> 2</span> IF (origin = 0) {<br /><span class="code-lines"> 3</span> CC "AdoScript" INFOBOX "DEMO: The object has been created manually"<br /><span class="code-lines"> 4</span> }<br /><span class="code-lines"> 5</span><br /><span class="code-lines"> 6</span> IF (origin = 1) {<br /><span class="code-lines"> 7</span> CC "AdoScript" INFOBOX "DEMO: The object has been pasted"<br /><span class="code-lines"> 8</span> }<br /><span class="code-lines"> 9</span>}<br /></div>Wilfrid Utz2014-04-11T12:08:04ZAfterCreateModelingNodehttps://www.adoxx.org/live/c/message_boards/find_message?p_l_id=&messageId=1108922014-04-11T12:07:24Z2014-04-11T12:07:24ZI would like to know, how exactly the "origin" parameter works in the "AfterCreateModelingNode" event.<br /><br />I would like to create a condition, where a window only pops up when the origin of a created instance is 0.2014-04-11T12:07:24Z