You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have project builders VitruvProjectBuilder for each domain, which are added to projects to start monitoring changes and propagate them to an associated VirtualModel.
This approach has several drawbacks. First, it initializes the domain-specific monitors implicitly during a project build, which requires projects to be (unecessarily) built on Eclipse startup. While this could be fixed with some better configuration, the second, more important problem is that change monitoring happens project-wise. If a VirtualModel is supposed to preserve consistency between multiple projects, in particular between multiple projects of the same domain (such as multiple Java plugin-in projects), changes become monitored and propagated in an isolated way, which can easily result in unnecessary failures, because projects depend on each other and thus the models within the VirtualModel will be inconsistent. We need to consider a development project (not an Eclipse project) as a whole, which means that one domain needs to monitor changes to all associated Eclipse projects.
I thus propose to do something like the following:
We do not use builders anymore but implement a kind of virtual model view extensions for Eclipse. We have some explicit representation of active views for a virtual model (can be an explicit project like the VSUM project), which stores the monitoring information, i.e., the projects, file extensions and whatever other information necessary for each domain.
Please note that this, in the current implement, leads to some overlaps which may make thinking about responsibilities diffult: The project to monitor are both a current state representation of the virtual model, as well as views on which the user operates. This is not how views should finally work, but how is currently done. At the end, the virtual model should have a current representation of all models it covers, and the user may have another representation of the views he operates on.
Monitoring is only relevant for the latter, which is why we must not mix up the current VSUM project, which manages the state of the virtual model, with monitoring information for views.
This is just an initial documentation of problems and first ideas, but the topic requires further discussion and its proper solution especially requires a proper definition and implementation of views, as well as according workflows in Eclipse. I only want to document my initial ideas, as I faced these problems when refactoring view-related implementations of domains.
The text was updated successfully, but these errors were encountered:
We currently have project builders
VitruvProjectBuilder
for each domain, which are added to projects to start monitoring changes and propagate them to an associatedVirtualModel
.This approach has several drawbacks. First, it initializes the domain-specific monitors implicitly during a project build, which requires projects to be (unecessarily) built on Eclipse startup. While this could be fixed with some better configuration, the second, more important problem is that change monitoring happens project-wise. If a
VirtualModel
is supposed to preserve consistency between multiple projects, in particular between multiple projects of the same domain (such as multiple Java plugin-in projects), changes become monitored and propagated in an isolated way, which can easily result in unnecessary failures, because projects depend on each other and thus the models within theVirtualModel
will be inconsistent. We need to consider a development project (not an Eclipse project) as a whole, which means that one domain needs to monitor changes to all associated Eclipse projects.I thus propose to do something like the following:
We do not use builders anymore but implement a kind of
virtual model view
extensions for Eclipse. We have some explicit representation of active views for a virtual model (can be an explicit project like theVSUM
project), which stores the monitoring information, i.e., the projects, file extensions and whatever other information necessary for each domain.Please note that this, in the current implement, leads to some overlaps which may make thinking about responsibilities diffult: The project to monitor are both a current state representation of the virtual model, as well as views on which the user operates. This is not how views should finally work, but how is currently done. At the end, the virtual model should have a current representation of all models it covers, and the user may have another representation of the views he operates on.
Monitoring is only relevant for the latter, which is why we must not mix up the current
VSUM
project, which manages the state of the virtual model, with monitoring information for views.This is just an initial documentation of problems and first ideas, but the topic requires further discussion and its proper solution especially requires a proper definition and implementation of views, as well as according workflows in Eclipse. I only want to document my initial ideas, as I faced these problems when refactoring view-related implementations of domains.
The text was updated successfully, but these errors were encountered: