hcOPF Designtime Strategy
One of the great things IMHO about hcOPF is the design-time binding. This feature requires you to install a design-time package into the IDE containing the MetaData for your objects.
The hcUIObjectBinder component uses the ThcUIBindingItems specified by the developer to create the appropriate mediator class at run-time and bind the specified attribute (by name) to the specified control (by name). If you name your controls consistently it would even be possible to add automatic design-time binding by inferring the mediator from the type of control, and matching the name of the control and the attribute. That feature isn’t available yet, but after configuring the bindings for 30+ controls on a form you can bet I have it planned.
My current project has grown to the point where the objects contain lots of code other than that used at design-time. Initially I have used some conditional directives to limit the units implicitly imported into the object design-time package. This has become increasingly difficult as things have grown and have added complications during the compile cycle. If I’ve built the design-time package recently, then some of the DCUs are built with the conditional directives, so I either re-compile the entire main project, or change the Unit Output Directory for the design-time package to a separate directory (which is what I did).
To make it easier to keep fleshing out the objects, I have considered 2 different approaches:
1) Using Include files containing all the common code used by both the design-time and run-time objects.
2) Creating the base business objects for design-time use and concrete objects descending from them for run-time use.
Neither approach is ideal.
Include files break up the code so much it’s harder to navigate and make sure changes in one file don’t prevent compilation. Too bad Delphi doesn’t support partial classes. If it was just the object metadata it would be one thing, but the code for child lists has to be included so they can also be bound at design-time. Using include files makes it easier to generate class definitions from the database, but I already have a utility that generates my entire unit so I have a good starting point for a business object.
Likewise, inheritance breaks up the class so reading it and understanding the whole run-time object can be more challenging. This is typical of OOP design though.
What approach would you use and why?