|
Without knowing all the details, it seems I have to point the obvious: do whatever is easier for the user. Don’t let him wade through a long, complicated form just because it makes your code nicer. In the end, users’ time is more valuable than yours (at least because there are so many of them) and making them happy should be the most important thing. Without them your company would not survive and you’d be looking for a job.
Mircea
|
|
|
|
|
I'm all for simplification, but I don't have a choice in how the form is structured and all the fields displayed are required. My question was aimed at the code layout / structure.
modified 12-Oct-21 7:08am.
|
|
|
|
|
Mircea Neacsu wrote: making them happy should be the most important thing
Except that sometime the most desired thing is to wipe them out totally 
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
 Sure, but don’t we have the same love/hate relationship with many in our own families.
Seriously speaking, I’m a passionate advocate for a user centric point of view. I’ve seen too many programmers and ‘architects’ in their ivory tower looking with disdain to lowly users and forgetting our whole profession come in existence just to help these users. Can you imagine the people at MIT programming the Apollo guidance computer and saying “screw these astronauts, they are just some trained monkeys”?
Mircea
|
|
|
|
|
Be careful what you wish for - we are all users, occasionally...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I don't believe a "user" has anything to do with the issue. It's the following programmers who are affected.
Gus Gustafson
|
|
|
|
|
The way the OP formulated the question led me to believe that he has a choice of showing a form with sections/fields that appear and disappear depending on different user selections vs showing different, simpler forms.
If that's not the case my comment does not apply.
Mircea
|
|
|
|
|
My comment still applies. What the user views is a result of an architectural/design decision; what a following programmer sees appears to be the subject of this question. Kornfeld Eliyahu Peter's response is, I believe, the correct one.
Gus Gustafson
|
|
|
|
|
It's quite probable you are right. That would make my answer a bit of a rant but it wasn't with bad intentions 
Mircea
|
|
|
|
|
see yourself in 1 year, what kind of psychopath will you be when you'll have to do changes in that code.
Refactor your code.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
That's definitely part of my consideration on choosing the approach
It's quite likely that another company will do the maintenance though due to an arrangement we have
|
|
|
|
|
I've successfully used a single dialog with all content and then injected the display and validation logic from a container.
It should give you the best of both worlds.
veni bibi saltavi
|
|
|
|
|
Welcome Back Mr. Vilmos. 
Long without seeing you.
I hope everything is fine with you and your people.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Complexity is perhaps going to make it easier to extend.
Duplication will in all likelihood make it easier to debug.
I know it's the wrong answer from a software engineering point of view - but from the point of view of someone who spends a lot of time fixing defects on a huge code base I would go for duplication.
I have seen a lot of code that makes use of inheritance and quite frankly I have found it to at times be something of a nightmare.
Complexity is clever and is elegant but it can make tracking and fixing bugs a lot more difficult.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: Complexity is clever and is elegant but it can make tracking and fixing bugs a lot more difficult.
Yeah, that's what I'm hoping to avoid.
|
|
|
|
|
That's when you're overdoing it.
Put everything common in a base file that you inherit. Duplicate the rest.
|
|
|
|
|
I would also favour composition over inheritance where possible.
So you could have a baseclass form that is very basic, then the implemented forms can perhaps use some form of builder to class to individually tailor those forms.
Using composition may make it easier to see what each form is built from.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Inheritance and specialization.
Maybe make the common sections into UserControls, etc.
|
|
|
|
|
A bit of a different idea: could you implement the common code in UserControls and classes so they have a well defined internal API?
|
|
|
|
|
Hmm, metal note: refresh the page and read any new posts before posting. PIEBALDconsult beat me to this by about 2 hours and 30 minutes.
|
|
|
|
|
So this means you are voting for duplication? 😂
|
|
|
|
|
Every time I've re-used UI for multiple forms I've come to regret it.
Ask yourself, who are the stakeholders for every form?
Are they the same? Do they know if another form is changed? Do all forms change at the same time?
If any of your answers is "no" then duplicate them, they look the same (for now), but are functionally different.
I didn't and am now in a situation where one form is evolving while the other isn't and the amount of if-else's is too damn high! 
Now, I only re-use specific elements or components on a page.
Talking web (ASP.NET MVC and Razor Pages) and WinForms experience here (maybe your hybrid approach?).
|
|
|
|
|
A series of "user controls": no "duplication" - only reuse. Show / collapse based on context.
The common "70%" is an obvious candidate for abstracting into a user control that becomes familiar; UI, business rules, or both.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
ideally ...
1) define a generic base Form with common features/controls/logic all specific types will use.
2) define specific Forms that inherit from the base Form.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Some interesting comments in this thread - funnily enough almost all focussed on the technical details of one approach or the other rather than a general principle.
To my mind, and after decades of coding in lots of environments, I (and this is only my personal opinion here!) always find a single codebase is overall easiest to maintain. Having multiple copies of similar, but not quite the same, code is just asking for trouble, especially as a generic logic error may not manifest in the same way in all duplicates.
Careful structuring of the code, with - useful! - comments about what each section (however coded) is doing and why, will be much easier to keep working or amend than multiple similar versions. Especially so for someone unfamiliar with the codebase.
Obviously for very small chunks of functionality this may not be true, but the more complex the process being modelled the greater the benefits of not creating multiple copies...
All IMHO, of course, as I said!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
