| A proper way to handle configuration files [message #1563618] |
Wed, 14 January 2015 04:51  |
Eclipse User |
|
|
|
Hi Vladimir!
I'm working on a model consisting of projects, which contain various configuration files besides source files themselves. A configuration in such file might have significant impact on a way a project and its children are represented in the model - e.g. it might contain a list of subfolders considered source folders. On the other hand, a configuration file is not meant to be edited by user and there's no reason to treat such file as a source file, i.e. build AST for it etc.
To get you a better idea of what I'm talking about, quite a good example/analogy of this might be .classpath file in Java project. Unfortunately a part of JDT responsible for this seems to be quite complicated.
Could you please elaborate a bit how do you work with such files in Handly?
Thanks in advance.
|
|
|
| Re: A proper way to handle configuration files [message #1572956 is a reply to message #1563618] |
Mon, 19 January 2015 07:44  |
| Eclipse User |
|
|
|
Hi Ondrej,
Good question!
You are right that managing "classpath"-like concept in the model can be pretty tricky, as the Java model shows. Unfortunately, there seems to be no good way to "generalize" it: clients may have various needs in this area. So it was decided to leave it out of the Handly Core scope. That means there is no out-of-the-box support for this in Handly. This is a result of the (tough) design decision between "sins of omission" and "sins of comission" in the core framework.
That said, I should be able to demonstrate how to do this kind of things in a more advanced example for adopters, which is planned for Handly 0.3. Meanwhile, I can only sketch what it would basically take:
* A configuration file (like .classpath) usually contains a list of entries (like IClasspathEntry in JDT) that influences the model (e.g. determines the project's children). As you hinted, this file is not represented in the model per se, i.e. as a file element.
* Usually this file is read on-demand and its information is cached in the model manager (see PerProjectInfo in JDT).
* That information is used to compute the list of children in the #buildStructure method (see JavaProject#buildStructure for an example)
* Also, you have to track changes to this configuration file (as part of the delta processor logic) and update the model as necessary (see DeltaProcessor#readRawClasspath and ClasspathChange in JDT). Usually you will also want to notify model clients about the change (via special flags in element delta like F_CLASSPATH_CHANGED in JDT).
I'm sorry if this description doesn't help a lot. I hope that the more advanced example will eventually make it more clear.
Please let me know if you have further questions about it.
Best regards,
Vladimir
|
|
|
|
|
| Re: A proper way to handle configuration files [message #1591699 is a reply to message #1591384] |
Thu, 29 January 2015 12:49 |
| Eclipse User |
|
|
|
Hi Ondrej,
Perhaps your question already answers itself, in part.
In my experience, a good rule of thumb would be to just follow JDT lead in structuring your model -- the old "monkey see monkey do" rule. You cannot lose that way, and if some problem arises later down the road, JDT may already have a solution.
A reason for this rule is simply that only the old JDT guard would know the exact answer to your question. A first reference to PerProjectInfo can be found on the Eclipse Bugzilla as early as 2002. Probably it was in the design from the very beginning.
We can only guess that separating such data from the model may be related to the fact that it is also needed by other clients that don't depend on the model (such as the Java builder), and that it probably has somewhat different lifecycle than the model. But that's just that -- a guess. There may be other reasons -- efficiency, synchronization, etc. We don't know the whole story behind it.
As a rule, the body only contains non-key information about the model element, including a list of its children (child handles). The key information is stored in the handle.
So, my advice would be to keep information pertaining to model elements themselves in handle/body pairs, and manage project configuration data separately, just like JDT does. Al least, I'm going to use exactly that pattern in the aforementioned example.
HTH,
Vladimir
[Updated on: Thu, 29 January 2015 13:00] by Moderator |
|
|
|
|
Powered by
FUDForum. Page generated in 0.04205 seconds
Home