Thursday, November 19, 2009
Response to comments in "Inducing the Great Divide"
I've read the -nice- article Inducing the great divide by Cobus Cruger, and was tempted to answer many comments about his approach to set object properties to visual controls.
Many comments where related to the lack of scalability of this approach, specially when a form has many model objects pointed to views not contemplated in the framework Cobus created.
I also am thinking about this problem since a long time, and started with my own framweork using the same approach of Cobus, and faced the same problems he is facing after the reader's comments.
My conclussion was that it's not possible to create a simple, generic way to fill any control with data from any object, thus, I created a framework where the programmer has to configure the objects by using "associations", where a property of an object points to a TEdit, TComboBox, TListView and so on.
For example, if the program needs to fill a listview with a TCollection of customers, in my framework, I have to configure this:
On Each TForm of the application, the programmer has to configure each control the way I explained in the previous paragraph, then the framework provides two methods, the first one to copy the data from the model and the second does the reverse.
To copy data from model to view:
To copy data from view back to model:
What if I have a component not included in the framework?
It's simple to create a custom association, like the example, that uses TListViewAssociation, one can create a TQuantumGridAssociation, for example.
Sample code:
I uploaded not so trivial example to Code Central, enjoy!.
Many comments where related to the lack of scalability of this approach, specially when a form has many model objects pointed to views not contemplated in the framework Cobus created.
I also am thinking about this problem since a long time, and started with my own framweork using the same approach of Cobus, and faced the same problems he is facing after the reader's comments.
My conclussion was that it's not possible to create a simple, generic way to fill any control with data from any object, thus, I created a framework where the programmer has to configure the objects by using "associations", where a property of an object points to a TEdit, TComboBox, TListView and so on.
For example, if the program needs to fill a listview with a TCollection of customers, in my framework, I have to configure this:
mvFramework.AddAssociation(TListViewAssociation.Create(
ListView1, // the list view associated
Customers, // Customers TCollection
['FirstName','LastName'] // Properties pointed to the First and Second column of ListView1
));
On Each TForm of the application, the programmer has to configure each control the way I explained in the previous paragraph, then the framework provides two methods, the first one to copy the data from the model and the second does the reverse.
To copy data from model to view:
mvFramework.SetDataToView;
To copy data from view back to model:
mvFramework.SetViewToData;
What if I have a component not included in the framework?
It's simple to create a custom association, like the example, that uses TListViewAssociation, one can create a TQuantumGridAssociation, for example.
Sample code:
I uploaded not so trivial example to Code Central, enjoy!.
Comments:
<< Home
So how would you deal with forms where changing one value would possible lead to new values for other fields?
Vegar, if the change is related to form's logic only then I'll use events offered by visual controls. Just look at my example, where I placed a TActionList, who controls the state of Edit and Delete buttons by using its onUpdate event. When there's a selected item in the listview, the actions are enabled, the other way they are not.
A more complex situation could need to fire the SetViewToData method after the onChange event of a control, or more than one control.
The last scenario could lead to the implementation of some kind of observer pattern, where each change in the view object fires a notify for the data object, this isn't much difficult to implement using this framework.
A more complex situation could need to fire the SetViewToData method after the onChange event of a control, or more than one control.
The last scenario could lead to the implementation of some kind of observer pattern, where each change in the view object fires a notify for the data object, this isn't much difficult to implement using this framework.
ok. Most of my views include a lot of dependent numbers where changing one calls for an update of the other. Maybe I will have to steal some of your ideas :-)
I'll be glad to see an example of what do you want to accomplish, then improve the framework to fulfill your needs.
Leonardo.
Leonardo.
Yes, after reading your post I've compiled it with D7. The example was written in D2010.
I had to change a couple of things to compile in Delphi 7:
1) Sales.pas doesn't understood what a TDate is, so I added "TDate = TDateTime;" just above the definition of TSale class.
2) I opened all the forms, and ignored all the warnings, then saved the whole project.
3) In the .dpr file, I removed the MainFormOnTaskBar line.
4) Build all.
That's it.
P.S.: It should compile in Lazarus also.
I had to change a couple of things to compile in Delphi 7:
1) Sales.pas doesn't understood what a TDate is, so I added "TDate = TDateTime;" just above the definition of TSale class.
2) I opened all the forms, and ignored all the warnings, then saved the whole project.
3) In the .dpr file, I removed the MainFormOnTaskBar line.
4) Build all.
That's it.
P.S.: It should compile in Lazarus also.
About the GTSize32v7 thing, I don't have this error, maybe you shuld look at your search path, or browsing path.
Before attempting to use OAUTH, you must obtain a developer key and secret from the service provider. In the sample code provided in this article, I have removed my developer key and secret. No other code modifications have been made.
Post a Comment
<< Home