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.