We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date

V5: Model and NodeCollection refer to Node not INode?

My V4 diagram application leverages the INode interface concept to keep non-visual objects in the model. This worked well as the DgtNonVisual base class just had to implement the INode interface and it could be added to any collection of nodes in the V4 implementation.

In V5, the Model and NodeCollection modification methods such as Add and Remove only take a Node instance. I expected these to take an INode instance.

Please consider modifying the V5 diagram implementation to make heavier use of the INode interface instead of the Node class - especially when dealing with collections of arbitrary nodes.

Apolon.

7 Replies

J. J.Nagarajan Syncfusion Team April 5, 2007 08:08 PM UTC

Hi Apolon,

The current diagram code was fully refactored and the refactored code of Essential Diagram will surely have much better usability and supportability. We have made a lot of changes, implemented a lot of features and fixed more defects in v.5. The new source will not support the older source completely.

We will release the new build with our main release which completely supports the older version(v.4.4). We have not shipped our support for older version right now with the beta release. This suport will be made availiable with the main realse.So this will affect your ongoing projects because of any chnages in our API.

Thanks for using Syncfusion product

Regards,
Nagaraj


AI Apolon Ivankovic April 6, 2007 02:40 AM UTC

Nagaraj,

I appreciate that given the major restucturing between V5 and V4, it is not possible to facilitate all backward compatibility requests. Regardless, please consider the backward compatibility requests individually and on their own merits. If an item of V4 functionality still fits in with the V5 object structure approach and is requested by a customer, then why not add it?

In my opinion, one of the most important features a third party component vendor such as Syncfusion can supply is backward compatibility. It is as important if not more than new-fangled widget "to keep up with Jones's". So even when you make a major API change, it is important to consider existing customers that use the previous API version and wish to move to the restructured API.

So, thanks for the information that V4 Ess Diag functionality will still be included in the V5 deliverables. This does help me in my application version planning. Will you be fixing faults in identified by customers in the V4 implementation?


AI Apolon Ivankovic April 6, 2007 02:43 AM UTC

Back to the original subject of this post:

It appears that the V5.1 beta is using the Node class in various collection APIs when I think the better approach would be to use INode instances i.e. the Model, NodeCollection and Group classes should all deal with INode instances and not Node instances.

Can you look at changing the Model, NodeCollection and Group classes to deal with INode instances for future releases?

This would allow my application to be able to implement node objects that are not forced to inherit from the Node base class.

Apolon.


J. J.Nagarajan Syncfusion Team April 10, 2007 05:12 PM UTC

Hi Apolon,

Thanks for your feedback. We have completely refactered our source code in v.5. If we change the Model, NodeCollection and Group classes to deal with INode instances, we have to face some other problems. However I will forward this to our feedback to our development team to know the thought some this.

Thanks,
Nagaraj


J. J.Nagarajan Syncfusion Team April 11, 2007 07:54 PM UTC

Hi Apolon,

Thanks for your interest in Syncfusion product.

Could you please send us a sample on your scenario with V4 implementation of INode interface concept to keep non-visual objects in the model. So that we could do the needful in suggesting the apporpriate code for v.5 implementation.

We have opened a new Direct Trac incident(33264) in this regard. Please follow up that incident and let us know.

Thanks,
Nagaraj


AI Apolon Ivankovic April 13, 2007 08:58 AM UTC

The application classes that implement INode using the V4.x API are non-visual nodes that are stored along with the visual nodes. I will change the approach and store the non-visual information separately and not in the Ess Diag model object. This works around the issue for my application in practice.

Regardless I think the Model, NodeCollection and Group should deal with INode instances not Node instances from an API "integrity" perspective. Otherwise what is the point of the INode interface if the only implementation that will ever result in compilable application code is a Node instance. To me the existance of the INode interface is at odds with the Model/NodeCollection/Group classes only working with collections of Node instances. It sticks out like a sore thumb and it seems a shame to do all this V5 API rework and still have a design inconsistency at that level. This is just my two cents worth.


J. J.Nagarajan Syncfusion Team April 18, 2007 08:01 PM UTC

Hi Apolon,

Thanks for the details.

I have forwarded this feed back to our developer and we will try to implement the INode instance for Mode, Group and NodeCollection classes.

I am doubtful in the insertion of your nonvisual objects. Any specific data could be attached to Node.Tag property. I could set Node.Visible property to false and attach any application specific data to Node.Tag property.

Please provide a scenario where non-visual objects need to be inserted into document.

Thanks,
Nagaraj

Loader.
Live Chat Icon For mobile
Up arrow icon