On Dec 12, 2010, at 2:49 PM, Krzysztof Kosiński wrote:
W dniu 12 grudnia 2010 23:42 użytkownik Jon Cruz <jon@...18...> napisał:
But what would be most helpful is looking over to figure out the clean ways to change the code so that such access is no longer exposed to begin with.
Off the top of my head, the largest problem is that there is no way to create a specific SPObject and add it to the tree. We need to create an XML representation of this object, insert it into the XML tree and rely on the XML tree observers to automatically create the corresponding SPObject for us. Therefore each of the shape tools needs to know how its products are represented in SVG markup, while in the ideal situation only the given shape's SPObject implementation should know this. Solving this would go 90% of the way towards making XML private.
You should run a review of that change. Among other things, some of the classes were fixed to abstract exactly that sort of tool construction needs. (yes, it is a large change so I understand that it is especially easy to miss some of the big-picture issues it addressed)
For example, things were refactored so that the tool for a 3d box did not have to know all about the XML used to create such a box, or even that such a box representation uses XML to begin with.
+ + /** + * Create a SPBox3D and append it to the parent. + */ + static SPBox3D * createBox3D(SPItem * parent); };
But I do agree. That is exactly the sort of encapsulation we need to continue working towards. Abhishek was able to start that with some classes, but there are still many more that need similar cleanup.