hardeeprai wrote: ↑
Sat May 11, 2019 1:29 pm
Don't think that way. Early discussion will be beneficial.
I try to change in that regard, because I don't really like sharing incomplete work, even though this approach will hinder anyone following it.
So what I did yesterday was mostly organisational, as kkremitzki suggested I cloned his github repo FreeCAD-Blog and set an own github page up for it. You can reach it under https://github.com/podestplatz/FreeCAD-blog
. Till now I have created one post bringing together all the references (at least I hope that I got all) that were posted to this topic.
Besides the repository for the blog I created a new one for the plugin
itself, and the documentation that belongs to it. In the ./doc directory you will find the first attempt on the UML Class-diagram. Note however, the class "Template" is just used for copy and paste. I used it to set the font to Sourcecode Pro, which was kind of tedious, and since I didn't know if these font changes translate to newly created classes too I have gone with the copy&paste approach. The classes presented in this diagram are all for representing the data from the markup.bcf
file (except for the class "Project").
What still itches me a little is the situation on the right with SchemaConstraint
and its subtypes. My intent here is to represent the constraints from extension.xsd
(regarding TopicStatus, TopicPriority etc.) as a type in python. Ideally I want this type to be an enumeration, but that opens the problem of how are these types then created? The main issue here is that the constraints in extensions.xsd
might change over time and I think manually adapting the enumerations is not that maintainable. This however creates the need of dynamic creation of these enumerations/classes in python. No I know that it is basically possible to create whole classes during runtime (as demonstrated in this blog-post
). An advantage of this approach is that when the, let's say, status of a topic shall be changed it only can assume valid values, because these are the only ones available for this type. That means no need for extra code that checks the status
variable. However this opens up another, not so small, issue: somehow the type system has to be enforced, since python is dynamically typed. That means the variables should not be directly accessible by the user, otherwise additional code has to be written that checks whether the type of a variable is the correct one. But as I plan it, an dedicated interface for manipulation exists anyway.
Another (hybrid-)approach comes to mind: The classes are created empty and during startup the plugin parses extension.xsd
and fills the enums with the possible values.
In the end I still have to think about how it is done best, and what is the most maintainable version.
I hope I could convey these ideas somewhat understandable.