xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steiner, Dominik" <Dominik.Stei...@gigatronik.com>
Subject AW: AW: MVC and batik?
Date Tue, 23 Aug 2005 12:33:26 GMT
Thank you Thomas,

you saved my day, too...

I think I'm now seeing light at the end of the tunnel...

God bless you... :-)

Dominik 

-----Urspr√ľngliche Nachricht-----
Von: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
Gesendet: Dienstag, 23. August 2005 14:08
An: batik-users@xmlgraphics.apache.org
Betreff: Re: AW: MVC and batik?

Steiner, Dominik wrote:

> Thank you for getting back to me so quickly.
> Perhaps writing can help to (dis)solve my confusion.
> 
> I already tried to use interactors, but as they don't allow for 
> multiple events getting processed at the same time (drawing and 
> at the same time zooming and panning)

    Well, interactors are designed to be modal, so the 'draw' interactors
can be checking if the cursor is near the edge of the image and pan
the document.  I don't think I've ever seen an system for doing what you
seem to be talking about.  That said you are always welcome to register
your own Swing Event listeners on the Canvas, or of course subclass
the canvas to adjust it's event processing.

> By layered model I just want to have different layers in my canvas 
> (for drawing, a background, the drawn shapes, etc), which I can
> easily insert into the SVGDocument as <g>-nodes.

    Ohh, yah that simple.  You might use 'svg' elements instead but
'g' element's will work find as well.

> So the DOM-tree and the elements would be my model. 
> 
> 	1) But how can I move the SVGDocument out of the JSVGCanvas into a
> 	separate model class? 

    Well we just said the DOM tree is your model so there is no need for
a separate one.  But if you really want to wrap it and provide some
higher level application specific interfaces:

	MyModel = new MyModel(canvas.getSVGDocument(),
		canvas.getUpdateManager().getUpdateRunnableQueue());

    Since all your changes must eventually be reflected in the document
all you need to make sure is that your changes all happen in the
UpdateManager's RunnableQueue.  This is no worse (in fact it's better)
than Swing which requires all model changes to take place in the Swing
thread.

> Then the model should update the view component that registers with it, 
> so in this case the GVT tree, which batik manages automatically.

    Right so nothing for you to do, just update the model (DOM tree).

> But the controller which receives the mouse events has to change the 
> model (the elements of the DOM tree), but these don't specify any 
> appropriate geometrical information, I would have to fiddle them 
> out of the attributes strings, especially for complex path elements.

    Well it might not provide _all_ the geometrical information you
want but it provides a lot of basic information.  Even for the
attributes (I presume you mean path 'd' attributes here) there are
interfaces for iterating over the elements of the path.

    If you want you can of course go to the bridge to link to the
'gvt' tree in your extended model, just make sure that you only
update the DOM.

> I already tried using the overlay and the SVGGenerator for inserting 
> the java2d shapes into my DOM tree. This works fine for drawing pure 
> java2d objects but when I want my DOM tree objects to be interactive 
> by registering EventListener with them, 

   Ok, and the problem is? Add them to the document and attach
a listener... Actually for most drawing programs you are just as
well off registering a single 'global' Event listener on the root
SVG element.  Have you read my ApacheCON 2003 presentation:

	http://people.apache.org/~deweese/ac2003/ApacheCON2003.pdf

    It covers a bunch of techniques for this sort of stuff...

> 	2) How do I get the conversion from element to java2d shape which 
> 	can then manipulate and rewrite to the DOM-Tree via the SVGGenerator?

   canvas.getUpdateManager().getBridgeContext().getGraphicsNode(Element)
   canvas.getUpdateManager().getBridgeContext().getElement(GraphicsNode)

> I'm already failing to interactively change a <g>-Element which contains 
> various paths as child elements. 
> 
> 	3) I guess that I would need to attach a transformation to it, 
> 	but how do I do that starting from the handle()-method of the 
> 	listener which I register with this element?

	evt.getTarget().setAttributeNS(null, "transform", 	
				       "translate(...)");

> This still sounds confusing, doesn't it? 

    It sounds like you don't know DOM 2 very well, and don't know much
about the SVGDOM which builds on DOM 2, so you're looking to reinvent
the wheel ;)  (to be fair for a real drawing application you will
need to go below these using the BridgeContext to map between DOM and
GVT tree's, but it's all there).  Where I think you will get in real
trouble is if you try to depart from viewing the DOM tree as the
underlying 'Model' for the rendered document.  The more information
you try and keep out of the DOM tree the more opportunity for conflicts
with Batik you are likely to have.

> But I think basically what I want to do is not only interactively draw 
> shapes but also change the existing elements of the DOM tree, by 
> registering EventListener with them...

    Sure, just update them, Batik will handle the rest.  Between the
SVGGraphics2D and the SVG parsers you should have good 'tools' to build
exactly what you want or you can just use the existing stuff with a
little bit of inefficiency (so build a path element with the
SVGGraphics2D just to grab it's 'd' attribute, although I'll say that
writing the code to spit out a 'd' attribute from a GeneralPath is
pretty trivial).

> Perhaps you can point me out where my error of thinking lies.... 
> I'm deeply grateful for any hints... :-)
> 
> Dominik
> 
> -----Urspr√ľngliche Nachricht-----
> Von: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
> Gesendet: Dienstag, 23. August 2005 11:56
> An: batik-users@xmlgraphics.apache.org
> Betreff: Re: MVC and batik?
> 
> Hi Steiner,
> 
> Steiner, Dominik wrote:
> 
> 
>>I'm just wondering if there is a good way of implementing the MVC 
>>pattern in Batik? I was fiddling with it the last few days and e.g. 
>>tried to move the svgdocument which I think is the model out of the 
>>canvas into a layer model. But this didn't work.
> 
> 
>      I'm not sure I follow you.  There are different ways to
> partition the universe so I'm unsure what you are trying to do.
> So to Batik the SVG document is essentially the Model the View
> is the GVT tree we use for rendering and the Controller is the
> Bridge (it keeps the view in sync with the model).
> 
>      This of course shouldn't impact most users of the toolkit, they
> just play with the model and things happen, so I suspect that this
> isn't really what you are talking about.  Also I don't understand
> what you mean by a 'layer' model....
> 
> 
>>So I'm wondering if I'm just confused and trying to do the impossible or 
>>if someone has practical design hints for batik in general and a svg 
>>draw program in special.
> 
> 
>      Well the simplest way to do a draw program is to simply
> add elements to the Canvas.  The interactors/overlays are good
> to maintain very high interactive performance while the user
> draws or drags elements around (typical move a proxy type stuff).
> 
>      If you are encounter other issues I might be able to make
> suggestions but I don't know where to go from here.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message