Closed Thomas-dot-G closed 9 years ago
I think it works :+1: , would you add a test for us?
For improvement, would we do something to make the method display more elegant rather than using a arraylist of object? But I don't have an answer yet.
First I wanted to use a composite design pattern, but it didn't work. So I have no other solution for now. I'll make a test !
I think CreateDrawing
is a good name. @Thomas-dot-G you can change the interface. For the arraylist of objects, I am ok that we keep it for now. We can improve it later when we come up with a better solution.
A way to avoid using Object could be applying the composite pattern to Canvas :
Canvas has a list of SVGFile : List
Not sure what you mean... I'm not sure that you can insert SVG between shapes with your composite. Because with the list, a sag file is treated quite like a shape, just inserted. Order matter here.
I don't see the problem, can you explain more? What I meant was :
Class Canvas {
private attribute Liste
... }
interface Liste
E is the generic type. So in the case of canvas, E would be SVGFile.
Maybe what you meant was that we can insert other svg files only in svg file, and not in Canvas. In this cas, we can simply put in the class SVG the attribute :
class SVGFile{
private attribute Liste
No what I mean is that if I want to put a svgfile over a shape and then another shape over the svgfile, how do you do that ?
I thought it wa possible to insert a svg in a svg.
After reading wiki, maybe we would use the Decorator pattern
For example, we have ShapeState
as Component
and other concrete shapeStates, and we make a ShapeDecorator
, and SVGFile
implement this decorator. the operation
shared among these classes is createDrawing()
.
This pattern is also a composite one.
I do understand, but how do you insert a svg file in the 4th position if there is 6 other shapes for example. This could be done if the SVGFile had only other SVGFile to display, but that is not the case.
A bad news, since the second presentation can not do this type of insertion, I think we should give up this branch.
Sure the second presentation can, just not the same way. Rather than creating a new frame of something we just need to take what is inside and add it to the drawing the same way:
for example: 1- draw a circle 2- //draw another drawing including a rectangle 2.1- draw the rectangle 3- draw a line (first drawing)
Ok, that would work. But how user can describe this kind of insertion with the language we create? To be honest, users would probably can/never use this feature with our language.
Why ? I used it in the main function, so it works and can be used. And actually it is asked by the subject...
What I mean is where user find another pic to add, especially in the case of AWT presentation. But if it's required, maybe the only way to do this is :
.svg -> SVGFile -> all shapes -> AWT ?
What is even the problem of finding another pictures? The user can create his own pictrues, and after that, use them to add somewhere else.
Yep, I understand user can create a pic, but it's a svg. To insert the svg to another svg is easy. But if we need to do the same thing in AWT, we have to finish issue #58 with lots of codes. So if it's not required, we'd better not to do it now. But if if's required, we then will go into this path :
.svg -> SVGFile -> all shapes -> AWT
Personally, I like this feature. But I just dont want us to expand the project too much.
.svg -> SVGFile -> all shapes -> AWT
Not sure what you mean by that.
I think it can be done the exact same way as the svg thing, except you don't put the frame around it.
It's not a feature, it is actually mandatory
@Thomas-dot-G what I mean is that we don't have a awt file to insert. svg is the only way to save a pic in our case. So we have to extract shapes form svg and than insert them to another awt
No but first, someone create a AWT drawing, then a second one, and then wants to see how one into another looks, without having to rewrite every thing, so he just put the first one into the second one.
So we have to extract shapes from the first AWT drawing, because if the user wanted AWT, there is no reason for us to use xml as they must be independent of one each other.
@Thomas-dot-G : you want to insert AWT into AWT, and therefore it is independent from svg.
We dont have the first awt. AWT is a JFrame, a UI class. If user relaunch the program, it's gone. What we can load as a file are, firstly, the script itself and the svg file.
yes, if it is done in the same main. The frame is an object, and we can get what is inside. And something else, we could even sterilized the object, even in txt, java can write in txt the object that can be easily retrieved as a java object (any objects)
I know about sterilized object, but I think it would be too hacky because a sterilized object file has no value to users. Since we will add the feature to transform .svg file into a java object, it would be better that we use that new feature to do this insertion.
Talk to you guys later ;)
I thought that having to transform the xml file in java object would just be a feature. But that would ruin our design pattern where we can swap the model.presentation.something as we want. In your case, I wouldn't be possible. I think that xml et awt should not be related
AWT is just for presentation, whereas XML is for the core. Without xml we won't have any svg files. Without AWT we can still can svg files, so I agree that XML and AWT should not be related.
I don't think neither that it is necessary to transform XML to Java objects. The two work fine without each other.
I think you are too worry about the concept about "ruining design pattern". In fact it won't. ;)
The two presentations are still isolated. We just add another part that is in charge to read svg file, which is also isolated. The svg reading result would directly be an arraylist
Like the PS software, we also can read/write images and display it.
Not sure, but if we agree with that, It means that we can get a new awtPresentation with that, and so insert it. So is it really related to that PR ?
I think it's do-able. But for me, we can finish this PR first. I think this PR is already well enough since it works. To refine the structure and implement the insertion for awt, that's next step.
Fine with me
26 add insert method
And also add the isFillable method to know if a shape can be filled with some color.