Why do we need slideGraphics.fillRect(…) and slideGraphics.drawRect(…) in TextGraphicObject.doPaint ? For me everything works fine without them. May be I am missing something ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is so that when you right click and open the properties of the textBox and change the line color/size/type that it is drawn around the text box. The gray border is not shown during the presentation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I want your advice: I am going to add a new constructor for TextGraphicObject which will get "angle" as parameter (I need it for SlidesReader to read info about rotated text object):
public TextGraphicObject (final Rectangle bounds, final String text, final Slide slide, final boolean autoSetBounds, final double angle)
My question is which "bounds" object is prefer to pass (and prefer to save in xml): before rotating or their final value after rotating ?
P.S. Of course I can not to add a new constructor and just run "rotate" function in SlidesReader, but I don't want SlidesReader will contain a logic related to graphic objects. It should know just read data from xml, create graphic object and add it to slide.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
codistmonk, thank you. I agree with you completely. It is more natural to use bounds before rotation.
I have one more design point to advice:
SlidesReader and SlidesWriter know exactly the structure of our graphic objects in the current implementation. It was good for now, till our objects were relatively simple. Now, after I implemented rotation for text object I have to add additional functions to the text graphic object especially to support SlidesReader and SlidesWriter.
I suggest following re-design:
1. New constructor will be added for each graphic object: GraphicOject( Node node). This constructor will be called by SlidesReader. Graphic object itself reads data from the node and fill the private fields. Of course there will be many common functions:readBounds, readLineStyles, …. We may put these functions to XMLUtility or some other class.
2. New function: Node readObject() will be added for each grapic object. This function will be called by SlidesWriter before adding a new node to document.
This way, all logic is hidden in graphic objects, and slides reader/writer perform only read/write from/to document.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"What about "getXMLRepresentation" or "toDOMNode"?" - I agree, it is more clear.
"I'm not exactly sure what you mean but the current SlidesReader and SlidesWriter obviously need to be updated
when the graphic objects are changed." I have a new "player" in text object - angle, which I need to save and read from XML.
Now I don't want to add a new constructor for text object which gets angle as parameter (I didn't need it till now) and I also don't want to call rotate() function from SlidesReader because SlidesReader should not know nothing about internals of text object.
I also opened a defect about support load/save for table object. Our table object is 2-dimensial array of text graphic objects. So, I also don't want SlidesReader know about it. I prefer to have constructor in table object which will get xml-node and read all data from it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't want to add a new constructor for text object which gets angle as parameter (I didn't need it till now) and I also don't want to call rotate() function from SlidesReader
Maybe we could create an interface GraphicObjectModel that would encapsulate model data.
With that, the constructors of the graphic objects would always have just one parameter (TextModel, RectangleModel, …).
Each model :
* would contain position, size, rotation, style, …
* could be created from a DOM node (reading) or converted into one (writing).
Beside simplifying SlidesReader and SlidesWriter , this approach would have the added advantage of making the models (and their XML representations) independent from the view components (graphic objects).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW, we already have a classes PolygonalModal and Triangle which inherits from it. But they are hidden inside graphic objects. I will think about your idea. Thank you..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And who will create and fill data of this model object before pass it to constructor of graphic object ? SlidesReader ?
I was thinking SlidesReader could have something like:
new TextGraphicObject(new TextModel(node))
TextModel (and the other models) would also have another constructor with "normal" parameters (ie not a DOM node)
to be used when creating graphic objects with the mouse:
new TextGraphicObject(new TextModel(position, rotation, style, text))
But this is just a possibility.
We don't have to put XML handling in a constructor of the model.
We can instead have SlidesReader read the node and fill the model
(either with a constructor or with a bunch of setters) before passing it
to the graphic object.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Till now, we looked at model as geometric description of graphic object (see line and triangle), now you suggest to add info about colors, styles, … . So it begins to look as proxy to graphic object. I suggest to wait with it till our application will grow a little and we understand better what exactly we want from model.
Besides, our graphic objects looks quite a simple for now, so if we will add 2 functions of xml-node, it will not make them so complex.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe the model should be everything that goes in the XML.
More precisely, the model should be the minimum amount of data needed to create a presentation.
That includes positions, styles, texts, …
it begins to look as proxy to graphic object
I disagree (if you are talking about the Proxy design pattern, I don't see how it applies here).
The view components (graphic objects) create a visual representation for the model objects.
Color and style are needed as much as coordinates to display an object.
I think It's only natural to have that information part of the model.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
codistmonk, model object you offer affect not only XML reading/writing. Regular creation of graphic objects by drawing should also use the model class.
I agree wih your idea, but I afraid a little to make this change immediately: it affects too many files and can introduce bugs. So, lets do it in 2 steps:
1. Simplify slides reader and writer by moving logic of reading and writing nodes to graphic objects. (This is also not small change). This step will prepare a foundation for involving models because it will be more easier to move code from graphic objects.
2. Implement model object after rotate and flip will be finally completed including save/load. So the skeleton of the model object will be more clear. I assume it should serve not only XML.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why do we need slideGraphics.fillRect(…) and slideGraphics.drawRect(…) in TextGraphicObject.doPaint ? For me everything works fine without them. May be I am missing something ?
It is so that when you right click and open the properties of the textBox and change the line color/size/type that it is drawn around the text box. The gray border is not shown during the presentation.
Do we need parameter "autoSetBounds" in constructor of text graphic object ? As I see, it is always FALSE.
Yes, it is true when pasting text.
I want your advice: I am going to add a new constructor for TextGraphicObject which will get "angle" as parameter (I need it for SlidesReader to read info about rotated text object):
public TextGraphicObject (final Rectangle bounds, final String text, final Slide slide, final boolean autoSetBounds, final double angle)
My question is which "bounds" object is prefer to pass (and prefer to save in xml): before rotating or their final value after rotating ?
P.S. Of course I can not to add a new constructor and just run "rotate" function in SlidesReader, but I don't want SlidesReader will contain a logic related to graphic objects. It should know just read data from xml, create graphic object and add it to slide.
I would use the bounds before rotation but I the other option seems ok too.
codistmonk, thank you. I agree with you completely. It is more natural to use bounds before rotation.
I have one more design point to advice:
SlidesReader and SlidesWriter know exactly the structure of our graphic objects in the current implementation. It was good for now, till our objects were relatively simple. Now, after I implemented rotation for text object I have to add additional functions to the text graphic object especially to support SlidesReader and SlidesWriter.
I suggest following re-design:
1. New constructor will be added for each graphic object: GraphicOject( Node node). This constructor will be called by SlidesReader. Graphic object itself reads data from the node and fill the private fields. Of course there will be many common functions:readBounds, readLineStyles, …. We may put these functions to XMLUtility or some other class.
2. New function: Node readObject() will be added for each grapic object. This function will be called by SlidesWriter before adding a new node to document.
This way, all logic is hidden in graphic objects, and slides reader/writer perform only read/write from/to document.
I'm not exactly sure what you mean but the current SlidesReader and SlidesWriter obviously need to be updated
when the graphic objects are changed.
I haven't done much work on text objects yet, because I felt that their API wasn't
very convenient.
That sounds ok.
I agree with the idea but "readObject" doesn't seem to be an appropriate name.
What about "getXMLRepresentation" or "toDOMNode"?
"What about "getXMLRepresentation" or "toDOMNode"?" - I agree, it is more clear.
"I'm not exactly sure what you mean but the current SlidesReader and SlidesWriter obviously need to be updated
when the graphic objects are changed." I have a new "player" in text object - angle, which I need to save and read from XML.
Now I don't want to add a new constructor for text object which gets angle as parameter (I didn't need it till now) and I also don't want to call rotate() function from SlidesReader because SlidesReader should not know nothing about internals of text object.
I also opened a defect about support load/save for table object. Our table object is 2-dimensial array of text graphic objects. So, I also don't want SlidesReader know about it. I prefer to have constructor in table object which will get xml-node and read all data from it.
Maybe we could create an interface GraphicObjectModel that would encapsulate model data.
With that, the constructors of the graphic objects would always have just one parameter (TextModel, RectangleModel, …).
Each model :
* would contain position, size, rotation, style, …
* could be created from a DOM node (reading) or converted into one (writing).
Beside simplifying SlidesReader and SlidesWriter , this approach would have the added advantage of making the models (and their XML representations) independent from the view components (graphic objects).
And who will create and fill data of this model object before pass it to constructor of graphic object ? SlidesReader ?
BTW, we already have a classes PolygonalModal and Triangle which inherits from it. But they are hidden inside graphic objects. I will think about your idea. Thank you..
I was thinking SlidesReader could have something like:
TextModel (and the other models) would also have another constructor with "normal" parameters (ie not a DOM node)
to be used when creating graphic objects with the mouse:
But this is just a possibility.
We don't have to put XML handling in a constructor of the model.
We can instead have SlidesReader read the node and fill the model
(either with a constructor or with a bunch of setters) before passing it
to the graphic object.
Till now, we looked at model as geometric description of graphic object (see line and triangle), now you suggest to add info about colors, styles, … . So it begins to look as proxy to graphic object. I suggest to wait with it till our application will grow a little and we understand better what exactly we want from model.
Besides, our graphic objects looks quite a simple for now, so if we will add 2 functions of xml-node, it will not make them so complex.
I believe the model should be everything that goes in the XML.
More precisely, the model should be the minimum amount of data needed to create a presentation.
That includes positions, styles, texts, …
I disagree (if you are talking about the Proxy design pattern, I don't see how it applies here).
The view components (graphic objects) create a visual representation for the model objects.
Color and style are needed as much as coordinates to display an object.
I think It's only natural to have that information part of the model.
codistmonk, model object you offer affect not only XML reading/writing. Regular creation of graphic objects by drawing should also use the model class.
I agree wih your idea, but I afraid a little to make this change immediately: it affects too many files and can introduce bugs. So, lets do it in 2 steps:
1. Simplify slides reader and writer by moving logic of reading and writing nodes to graphic objects. (This is also not small change). This step will prepare a foundation for involving models because it will be more easier to move code from graphic objects.
2. Implement model object after rotate and flip will be finally completed including save/load. So the skeleton of the model object will be more clear. I assume it should serve not only XML.