I am writing extension methods for a old code that I am trying to migrate without changing the actual code...
Here is the scenario -
Here is what I have
UltraWebGridObject.DisplayLayout.AllowEdit = true;
And wanting it to perform this without changing the code..
WebHeirarchicalDataGridObject.Behaviors.EditingCore.Behaviors.CellEditing.Enabled = true;
Now I wrote a extension method for DisplayLayout like this (Not sure if this is even the way to attack this problem). (As DisplayLayout does not exist in the new WebDataGrid)
public static EditingBehaviorCollection DisplayLayout(this WebHierarchicalDataGrid grid) { return grid.Behaviors.EditingCore.Behaviors; }
How can I write a extension method for AllowDeleteDefault and set the true to it? Did I make any sense? The reason I am trying this there are several places in my code and code behind where this piece exists and i would not like to touch the code and mess it up.
Thoughts or suggestions - Please..
Hello Kishore,
Thank you for posting in the community.
If you are planning to not change the code listed at the top, does this mean that you intend to extend the WebDataGrid control in order to expose a DisplayLayout with properties similar to the UltraWebGrid ones in this case ? I would suggest considering this carefully as this would require custom coding which may complicate the scenario further. Note that such customizations of the control or any issues following from that are not supported. As the UltraWebGrid and the AIKDO WebDataGrid have differing architectures I would suggest refactoring any UWG specific code to the WebDataGrid equivalent instead of attempting to expose an API for WebDataGrid, similar as the one in the ultra grid.
Please do not hesitate to contact me with any questions.
Don't get me wrong - I like your idea/thoughts as on a positive note: Job security, but why no thought was put to backward compatibility. We have to invest 3 full time developers replacing or migrating 75 web data grids in an application that handled update/inserts/deletes manually in the code behind - now the total architecture has changed (as you were mentioning).
We have 20+ applications like this, so how long it will take for us to fix it. I don't have a good feeling about Infragistics going forward 3-4 years down the line what is the guarantee that you wont replace with a new framework or architecture???
Did any one in Infragistics ever thought about writing a piece of code that can look like one Ultragrid - and use all the new stuff and probably could make a ton of money for releasing that type of patch or a library. May be you should ask your experts to work on this. Because as of right now - our migration plan is around 2 years analyzing all the applications that use Infragistics.