Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Handly » A proper way to handle configuration files
A proper way to handle configuration files [message #1563618] Wed, 14 January 2015 09:51 Go to next message
Eclipse UserFriend
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 12:44 Go to previous messageGo to next message
Vladimir Piskarev is currently offline Vladimir PiskarevFriend
Messages: 68
Registered: January 2014
Member
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 #1591368 is a reply to message #1572956] Thu, 29 January 2015 13:44 Go to previous messageGo to next message
Eclipse UserFriend
Hi Vladimir and thanks for your explanation, which confirms my own findings of JDT and CDT model.

I understand you're now working on Handly 3.0, which will eventually provide an example of how to treat configuration files in model. Before this is available to adopters, could you please shortly describe how this example is going to be designed from an architectural point of view? This would really help me to check if I'm going the right way.
Re: A proper way to handle configuration files [message #1591384 is a reply to message #1591368] Thu, 29 January 2015 13:54 Go to previous messageGo to next message
Eclipse UserFriend
Some additional notes/questions to get you a better idea what I'm currently struggling with: I'm trying to understand design decisions behind classes like PerProjectInfo (JDT), PathEntryManager (CDT), CProjectDescriptionManager (CDT). What all these classes have in common is that they provide some information, which apparently was decided to be kept outside model elements. So generally it seems to be a good idea to manage configuration and settings data independently on the model using special data classes and/or special managers. On the other hand there's a lot of body implementations (called element info) in both JDT and CDT caching various element-related information. What's the exact reason not to put also the configuration data here? What's a rule of thumb to decide what to cache in an element body VS what to manage outside of a model?
Re: A proper way to handle configuration files [message #1591699 is a reply to message #1591384] Thu, 29 January 2015 17:49 Go to previous messageGo to next message
Vladimir Piskarev is currently offline Vladimir PiskarevFriend
Messages: 68
Registered: January 2014
Member
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 18:00]

Report message to a moderator

Re: A proper way to handle configuration files [message #1592053 is a reply to message #1591699] Thu, 29 January 2015 22:21 Go to previous messageGo to next message
Eclipse UserFriend
Hi Vladimir, thanks for you patience with my questions. You're right the best way here is to follow the JDT way. I just want to be sure I understand this from various points of view before doing important design decisions, and this is only possible thanks to your kind help. The support you provide to Handly adopters is outstanding. Kudos to you!

[Updated on: Thu, 29 January 2015 22:24] by Moderator

Report message to a moderator

Re: A proper way to handle configuration files [message #1592654 is a reply to message #1592053] Fri, 30 January 2015 06:33 Go to previous message
Vladimir Piskarev is currently offline Vladimir PiskarevFriend
Messages: 68
Registered: January 2014
Member
My pleasure! And no worries; that's what I'm here for :-)
Previous Topic:On M-theory and H-models...
Next Topic:Announcing Handly 0.2.2 Release
Goto Forum:
  


Current Time: Thu Apr 18 01:43:12 GMT 2024

Powered by FUDForum. Page generated in 0.02666 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top