flare and the PureMVC framework

[34all]

Good morning,

hope all are well.

This demo is my first attempt to fit flare into the wonderful PureMVC framework. The implementation follows Chandima Cumaranatunge’s excellent PureMVC walk-through in its updated version by Alastair (in order to work with version 2.0.3 of PureMVC)

Make sure you have PureMVC in your class path in order to be able to run this demo.


My first PureMVC based application so please be patient.

TO BE DISCUSSED


Cheers

martin


ps this demo is the complementing the flare and the model view controller pattern demo which achieves exactly the same result as this demo here.


NEW VERSIONS
Just attached the second version of this demo to this thread. The previous one missed the ApplicationFacade class.

Please see one of the replying threads for version 3 of this demo.



requires flare version 2008.07.29 or higher

[MoritzStefaner]

Hi,

very interesting, I made some experiments with flare already, and also looked at the PureMVC framework before, so I find it quite interesting to see how to merge these two...

I only briefly looked at the code, some things I noticed:

- Isn't the ApplicationFacade class missing?

- Not sure if it makes sense to have "NodeSprites" as data objects in the model? Shouldn't these be data objects that are referenced in the data property of the respective NodeSprite? For example, if you make a visualization of books, you will want to store the author, the title, the ISBN etc. - Where would this data go in your example?

- The identification of model nodes via their "modelName" looks a bit provisional - why not use a dictionary with the model data objects (or their IDs) as keys?

Thanks for sharing! And looking forward to your answers!

[34all]

Hi Moritz,

thanks a lot for feedback.

Oh yes the ApplicationFacade has been missing, sorry. The new attachment of the thread includes it. I also removed the embarrassing modelName lookup joke and use a dictionary instead.

NodeSprites etc. I briefly mentioned why I did it in the description of my second MVC attempt flare and the model view controller pattern

Code:

In this demo here the flare Data class is also used in the model layer to hold the data (yet in a different instance than the one used in the view). This is solely due to the laziness on side of the author when it comes to writing demo programs and most likely not the way to go in normal applications. Nevertheless I hope this is not crucial for the discussion I would love to stimulate.

So PureLaziness approach, sorry. The NodeSprites and implicitly the EdgeSprite are used for the sake of holding the graph related information. Information about individual should be candidates for the node.data field I guess. But I can't say I am particular happy with how it is right now.


Once more thanks a lot for the feedback. I will wait for further feedback which definitely should flow into the next version/step. It would be great if people would have suggestion how to hold the graph data in the model. Is there a necessity to always create an individual data model or could there be a chance that we create something more generic, similar to the flare Data class without all the visualization connected overhead? Or should we better ...


I am really looking forward for further feedback. Also hopefully everybody feels invited to post suggestion how to improve in form of source code ... As mentioned before, I am by no means an OO architect, so for sure there are heaps of more qualified people around. A mature framework template for flare application would be for sure a big contribution for the wonderful flare project which is offered to us so generously.

cheers

martin

[34all]

Good morning,

here comes my third step on the way of trying to fit flare in the PureMVC framework. This demo still holds on to using the flare classes Data,EdgeSprite and NodeSprite in the model layer. In order to get a feeling for it it even uses them to a greater extend by using them also to hold and communicate node and edge attributes (node label, node type, edge type, edge importance). In addition this demo introduces new user interaction (mouse click events) which are just to explore the PureMVC framework but of course not crucial for the flare-PureMVC question.

My confused state of mind concerning the model layer and flare data classes boils at the moment down to

• using flare classes in the model layer works and is nice since it uses well proofed and well known structures and also brings all the flare utilities for these classes with it (GraphMLConverter etc)
• it feels odd, particular using these classes for the communication between model and view (the view getting a sprite from the model etc)
  

Hope the community will help my out of this confusion since not joining these two gems (PureMVC and flare) for future application feels unthinkable.

   

cheers

martin



requires flare version 2008.07.29 or higher

[MoritzStefaner]

34all Wrote:My confused state of mind concerning the model layer and flare data classes boils at the moment down to

• using flare classes in the model layer works and is nice since it uses well proofed and well known structures and also brings all the flare utilities for these classes with it (GraphMLConverter etc)
• it feels odd, particular using these classes for the communication between model and view (the view getting a sprite from the model etc)
  

If you take a look at the GraphML converter, it is actually using only classes from flare.data ( like flare.data.DataField, flare.data.DataSchema etc.) so there is no reference to Sprites or DisplayObjects here...

flare.vis.Data (the one used in the Visualization class), in contrast, is a "Data structure for managing a collection of visual data objects." (from the docs).

So I think the proper way would be to only use flare.data classes and alikes in the model, and flare.vis objects (Nodesprites etc) in the view, and store their model data in their data property. Of course, in many cases, there will be a 1-to-1 mapping between view objects and model objects. But in other, more complex settings, you might want to select only a subset of model items for visualization, or provide several coordinated visualizations for the same data items. In these cases, you need a strict separation between data and display.

Does that help?

[34all]

Great,

that definitely clarifies a lot, thanks Moritz. Obviously I confused a lot around flare's class structure and also with the previous advice you gave me. So I will let this flow into a new version of this personal struggle with flare and PureMVC and hope to get further advice from you and/or other people around

Highly appreciated

martin

[34all]

Okay,

I looked a bit into it. While the flare.data package should for sure be the choice for the model layer it is at the moment a very rudimentary graph data storage package without any particular graph related convenience functionality (like addNode, addEdge etc) or even classes for Node and Edge representation. Since the prefuse.data from the java prefuse package contains all these it is for sure due to the fact that flare is still alpha. So for now I would say I could

• be lazy and just use the flare.vis.data package
• be diligent and implement this missing functionality
• hope that this will be done by the flare team or anybody else soon anyway
• use for the time being a different graph representation package for the model layer like http://lab.polygonal.de/ds/ (just the first one I found ...)
  

Not sure yet ....

martin

[MoritzStefaner]

Ah yes, you are right, all the graph manipulation + query functionality is in fact in flare.vis! While this is quite helpful for the quick tryouts, it does not really play together well with MVC based acrhictecture.... Hmhmhm.

[jgervin]

What about some sort of circular reference? Use a singletonmodelLocator, on the model side, from cairngorm that is bound, via binding, to the vis.data property. Sure the model isnt' seperated from the view, but then for puremvc we can make it think the model is on the model side and we can use the Proxy as normal.

Did anyone ever come up with any other solutions?

[34all]

Hi Jgervin

hope you are well.

Could you put a demo together exemplifying your suggestion? Would be very interesting and maybe we could revive this discussion here a bit

Cheers

martin