What should the next version include?

Coordinator
Sep 8, 2009 at 1:22 AM

Please use the Issue Tracker tab to add suggestions of what the next version of ICE should include.

Also, if you develop enhancements, please kindly contact us, we'll be happy to incorporate them in our next build.

 

Sep 9, 2009 at 8:35 AM

I would like to see the systems internal managers seperated behind interfaces,for example the filedownloadmanager and the mainmanager should not be so coupled, to allow clients to use the ICE engine with offline data ( which may be provided from Cache )

Sep 9, 2009 at 8:37 AM

Also i would like to see the xml settings, inital node selection and styles mirrored via a fluent interface to give the developer a choise.

Coordinator
Sep 9, 2009 at 3:53 PM
orialmog wrote:

I would like to see the systems internal managers seperated behind interfaces,for example the filedownloadmanager and the mainmanager should not be so coupled, to allow clients to use the ICE engine with offline data ( which may be provided from Cache )

 I agree with you, it is an important thing, especialy in terms of modularity within this project. We may be able to plan this achitecture review for the next versions.

Coordinator
Sep 9, 2009 at 11:19 PM

orialmog,

In my next update I planed to enhance the loading system.

Can you send me a more detailed explaination on how you want to link ICE to your cache or file system, and what exactly are your use cases.

Sep 10, 2009 at 1:33 PM

As it stands I cant fault the engine as it was me that raised the need to seperate the loading process out. Since version 1.0 ive ported the engine, (nice work by the way) to wpf and want to use a local cache of sql compact, data would be preloaded on connect with the network (my customers all run on laptops), it is also adventageous for scalability of the silverlight ice engine to be able to do this too no? If I can make one remote call to populate my model and the same time populate ICE its a great plus (dont get me wrong I think the FiledownloaderManager is very clever code). It would be nice to see this subsystem abstracted to Somthing like a INodeModelFactory, that I can implement on my own, and totally skip the xml conversion, as i could then define adapters from my model (which is on the client) push it to ICE and be done.

Coordinator
Sep 10, 2009 at 4:18 PM

Thank you.

As you have seen, our engine is deeply linked to the Xml format. This was a choice we've made to ensure that ICE will be used as a unique component (black box) and not as a class package. (could run on every Http platform and require only to understand Xml and html) We've never really thinked about a WPF implementation. Now, I think I understand your problem, and I have two propositions for you (after I've clean up the architecture dependencies of course).

1) You can make your own version of the MainManager class to populate your model with your Data.

Pros: It shouldn't take you too much time, you don't have to adapt your data too much, and you will be able to add your own interface on top of it quite easily.

Cons: There is a great chance that your project become really different form ICE (Silverlight) and we will not be able to help you improving it. Your project will become a new branch based on ICE v1.1.

 

2) You can link your data to a lower level (the loading process) and provide your data and settings in our Xml format.

Pros: We can include WPF version of ICE in this project and it will be improved by you and the community, and someone who wants to switch from a local to a web version (or from a web to a local version) will just have to change the data interfacing.

Cons: The architecture of the WPF solution will have to accept the Silverlight technology restrictions and the Xml format, this new project might require more work and time.

 

In both solutions, you must now you are welcome to contribute by any way to our project.

Sep 11, 2009 at 2:28 PM
cpoirot wrote:

2) You can link your data to a lower level (the loading process) and provide your data and settings in our Xml format.

Pros: We can include WPF version of ICE in this project and it will be improved by you and the community, and someone who wants to switch from a local to a web version (or from a web to a local version) will just have to change the data interfacing.

 I will look into doing it this way.

Coordinator
Sep 11, 2009 at 3:25 PM
Edited Sep 11, 2009 at 3:27 PM

Great!

Just now I'm working on an enhanced version of the file loader and the main manager.

It should enable you to change the file access quite easily.

If you want to begin your implementation, you have to create a function that will use the following objects: string Url (a custom path to retrieve your data. E.g.; file:///C:/mydata/xml1.xml or "mydataSource.myTable.myObject"), int Timeout (time in milliseconds. Ensure your function end in a specified time E.g.; 10000). If you function succeed it will return a MemoryStream with the content of the file.

Coordinator
Sep 15, 2009 at 12:15 AM
Edited Sep 15, 2009 at 12:17 AM

orialmog

I've just finished my modification. Now you can change the loading system by following this procedure:

1) Create a sub class of the abstract class ICE.download.Loader. To do so, you have to create your own version of StartLoading(). This function must lunch you loading procedure asynchronously and end by calling one of the following function.

The loading succeed : SetResult(Stream stream)

The loading Failed : SetError(string error)

2) You have to change the class reference in the following line: (App.xaml.cs ln 92. In your code: ICESurface.xaml.cs ln 35)

new MainManager(e.InitParams, typeof(yourNameSpace.YourLoader));
I've also had some time to review your work. it's great!. I think the MVC Asp.net project should stay out of the project source and be proposed as another Starter Kit. (the code is more "ICE maker" oriented as PHP solution for ICE would be).
Do you prefer to send us a new version of your patch or do you want me to integrate the one you sent us last week?
Sep 17, 2009 at 8:37 AM

Well done on the new version, looking good, the abstraction is very solid.
If you are doing to add my contribution of the WPF port what do you require from me. Do you want me to port the this version?
I would like to contribute a url handler for my default implementation of "Loader" that uses pattern matching to find the correct loader's conversion method,
my idea is when the developer requests data for thier model via a url the implementation of the default
loader finds a method with the parameters that match the urls query ie

a simple example for animal lovers, a url
 /John/garfield/1

match to
 
IEnumerable<Node> GetNodeData(string person, string dog, int animalId);

so to register this url pattern would be
 "{/person/dog/animalId}"

this would take the boring task of parsing the urls for data away from the developer, maby also the default will try to find a physical file on disk first before looking for said conversion methods, what do you think?

(Also how difficult would it be to get ice to scroll to centre of the new node(s) when expanded, currently when there is an expandtion it may occur off screen)

 

Coordinator
Sep 23, 2009 at 4:51 PM
Edited Sep 23, 2009 at 4:52 PM

Hi,

First I'd like to say I'm sorry to answer you so late.

About your WPF component implementation, please feel free to send us a new patch. I still have to talk to Mr Tourpe about this feature. (review any additional maintenance efforts and consider the need of this feature) Of course, if you have any comment to add, please add it to the feature proposition. I will ask Mr Tourpe to validate or not the feature request before the end of the week.

About your pattern parser, I think it would be an error to integrate in ICE a personal naming convention (by personal, I mean "not validate by W3C or any other convention working group). Fortunately, ICE do not depend on an real URL pattern (It is in fact an "xs:string"),  you are allowed to use the url field (XPath "\\node\url") with any particular pattern for your own implementation of the Loader component.

To answer your question about center the screen on an opening node, it is possible. The thing that might take you a lot of time is to create an animation to progressively go from the current point of the screen to another one (it would be easier with Silverlight 3.0 framework but the transition has not been planned yet). Behind that, there is no real challenge to this modification. Anyway, based on my experience, I think that a lambda user might dislike to see the map constantly moving from one point to another. I think the best solution still to allow the user to grab the map and change the zoom level by himself But that mean you must not add another object or layer on top of it.

Thank you.

 

Sep 29, 2009 at 8:04 AM

My machines in for upgrades, will undertake a new patch as soon as possible.

Sep 29, 2009 at 10:21 AM

If this project could be integrated with the NodeXL project (http://nodexl.codeplex.com) - that would be pretty cool and so useful!

Oct 2, 2009 at 11:56 AM

WPF support would be fantastic.

 

Coordinator
Nov 12, 2009 at 3:30 PM

What do you think of the possiblity to apply gravity forces on specific nodes, as opposed to the entire graph? This could enable some cool effects. Say your graph represents people assigned to a project. Those still "unassigned" could be applied a gravity to visually show that they're waiting to be assigned, etc.