April 11th, 2013, 09:26 AM
Object oriented forms
I need to design about 20 forms for various business processes.
We have to do this for about 10 countries and need some form of object prietnted approach because each country has different business rules and some different bits of data. However, there is also common data between some of these countries.
For example, we have 5 bits of data, 4 are common to every country, 1 is specific for individual countries.
eg common Name, Address, Telephone, Male/Female
eg Bonus payment
To avoid having to have 200 forms (20 forms x 10 countries), what is a good way to go about designing forms that can inherit from each other?
It's more complicated than that but should we have a base form that all countries can inherit and then specific country forms or 1 form with a base and then country specific validation rules.
It's a question of how do you manage all the code changes easily in an enterprise application without the code being too unwieldy?
April 12th, 2013, 04:23 PM
What language is this in? C? Someone asked to move this post to another forum so I want to make sure where it should go.
April 15th, 2013, 06:48 AM
No particular language but could be anything in .NET, C#, Infopath, etc.
Originally Posted by Viper_SB
April 18th, 2013, 05:51 AM
any ideas on forms inheritance or other?
April 18th, 2013, 10:37 AM
It's an ambitious and inovative idea that sounds like it should work, but there will need to be a lot of thought going into it and undoubtedly a lot of work to get it to work.
You didn't say whether these would be hard-copy forms or on-screen forms in an app or on a web page. That may not be important.
All I could do would be to speculate, which I'm sure you've already done yourself. I would assume that you'd be dealing with objects that generate these forms. These objects would consist of other objects that make up the sections of the form. Those section objects could be virtual, or the final form could be the one that's doing the inheriting. Like I said, a lot of thought would have to go into it.
One problem I can see would be in the formatting. Each section would need to be able to relocate and resize itself. Again thinking in terms of a hard-copy form that has to fit on 8½×11 paper, each form object would need to make those sections fit that format. Of course, if it's an on-screen form, then you would have more latitude, including giving each section its own screen, in which case the parent object (ie, the object representing the entire form) would only be involved with scheduling and controlling each section's appearance on the screen as well as storing the information entered so far and pre-populating certain fields of the sections accordingly (eg, if a name or ID number is to carry over from one section to another).
For example, I recently had to fill out a long, long form on-line. There was a pull-down list box for jumping directly to a particular section. Each section could have an indefinite number of entries (eg, past employment, a list of references or relative), so I was prompted to enter the first one then after I had filled in all that information it asked if I had another one to add. If I answered yes, then it would take me through another sub-section for that one, else it would take me to the next question. And at those points, a box listing the ones I had already entered would be present along with the option to edit one of those. It also presented a list of which items had not been completed yet, plus the last section would validate the entire form and list which items had not been completed. Just a real-world application that might give you ideas.
That's all that comes to mind while waiting for the coffee to kick in. I have no expertise in this matter.
Last edited by dwise1_aol; April 18th, 2013 at 10:46 AM.