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?
Perhaps peruse the Symfony Form component, and see if it's to your liking.
Yes you can save your time and reduce no. of forms,by making common forms in multi-languags.Noow its possible to convert page content according to there country's language.Rest form that are specific for that country need not to make it in multilanguage. Once you consult your web designer company ,they will surely suggest about the technology.
It's not just the languages, that would essentially be driven by a config code that lists the names for the lables.
...but also each form may have 60% of it's design from a gloabl form and then 70% from a local form, local to the specific country.
It would seem better to me to instead of having 20 or 100 local forms that it should be just 1 global form that can have some config code written for each country. That config code would determine what to display on the form.
any ideas on forms inheritance or other?
I would opt for the first, because that keeps the objects leaner. That is to say, if you have an object with the standard rules and then a list of multiple exceptions (most likely ending up in an if/then/else galore) it's not very clear what's happening, whereas separate classes that just list the differences between them and the base object are easier to follow.
In terms of front end I would make it so that PHP can read the form model and build input fields accordingly, so you don't have to code each any form yourself, and change it when the form changes, etc.
If you do it that way then you 1 main form and then each country has it's own form, then you have another form for each country business process.
So you might have:
x another 100 counties
x another 10 business processes
Isn't there some way to build a dynamic form on the fly so that you have 1 form ProcessBonus for every country, that form inherits fields from MainForm, and then it checks configuration Class in the background to build the form dynamicaly for each country?
I'm trying to avoid having 10 form types and then another 100 local forms for each country, that would be well over 1000 forms and would be unmanageable wouldn't it?
Sure can, but that would be an enormous config class. Not sure if that's workable.
Or, given the amount of data, maybe you could create a config file, like a JSON file or something that defines which fields every class should have, and then create classes that can load their config from that?
'fields': ['first_name', 'surname', 'bonus'],
And then if the country is not in the per_country list assume it has no additional fields/business rules.
Just thinking out loud here.
I hear there is something called Java Interfaces as well although it sounds like another OOP, I'm not sure what's it's called in .NET.
There could be some combination of forms inheriting using "Interfaces" and then configursation items for each form taken either from a DB or from JSON?
This topic is now closed. New replies are no longer allowed.