Talk:Magic pushbutton

Borland?

Seriously? Can we provide a bit clearer example in a more recent programming language, or at least one that's understandable to general programming public? —Preceding unsigned comment added by Andriyko (talk • contribs) 18:34, 1 June 2009 (UTC)

Citing

If anyone has time to add some cites and refs, there is a brief discussion of the Magic Pushbutton in "Software Project Secrets: Why Software Projects Fail" by George Stepanek ISBN 1-59059-550-5.

What is the Magic Pushbutton?

This article never defines its subject -- after reading it, I still have little idea what the Magic Pushbutton antipattern is. This should be remedied by someone familiar with the topic. --Marnen Laibow-Koser (talk) (desk) 07:15, 6 April 2007 (UTC)

• I'm also confused. Here is what I think is being said: In some cases programmers start by making a graphic interface which is then used to generate definitions of structures and some of their basic behavior. This data generated from the graphics of the human interface is then used directly to specify the business logic. The application begins with an interface made up of magic buttons that are intended to perform certain tasks. Then it became necessary to code the logic behind the interface in terms of the graphics. Unfortunately, relationships that are natural in the graphic context may become cumbersome when working with the data to perform defined operations. If this is a common anti-pattern then there should be some references to it. -- M0llusk (talk) 22:05, 2 October 2008 (UTC)
• From what I understand from the article, "magic pushbutton" refers to giant non-interactive forms, where data is checked only after pressing the submit button. In opposition to interactive forms, where data is checked as soon as it's typed in, and any bad input immediately reported to the user, before submitting the form. If so, the Delphi example is totally irrelevant, in top of being hard to follow (seriously, the very first sentence of the page claims it's about graphical user interfaces and the example doesn't show any GUI!?). -- Shirluban 2A01:E35:8B66:1C40:BD94:1C9F:2CDF:54B1 (talk) 01:08, 10 January 2017 (UTC)

Bad example

Is the phrase "Bad example" a bit confusing to anyone else? Presumably, it is a good example of a magic pushbutton, but an example of bad programming/design. Andjam (talk) 00:41, 17 April 2008 (UTC)

Copyright problem removed

Prior content in this article duplicated one or more previously published sources. The material was copied from: http://books.google.com.au/books?id=xQlG-qVl8VQC&pg=PA14&lpg=PA14. Infringing material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. MER-C 12:20, 3 December 2011 (UTC)

The "example", isn't.

The example given has nothing to do with the article.

A "magic pushbutton" is a form that only validates itself once, at the very end. Magic pushbuttons aren't inherently bad. Most login screens don't bother validating each of the two fields separately. They wait until you click the login button then return validation information. It could be beneficial to have the form validate the format of your input, but mostly the user either knows what they're typing and does it correctly, or mistypes it and gets an error which costs like 3 seconds retyping the information. Or they're not the user and we explicitly want the form to be harder for them.

Where magic pushbuttons become a problem is when you start getting long forms with lots of data. E.g., if I get halfway through my tax return, then it tells me I entered a field incorrectly, now I have to sort through my files to find the paper with the correct number. If it had yelled at me the moment I finished the field (or at least that section of the form) I would likely still have the paper on my desk.

Or forms where software guidance is beneficial. E.g., If I'm doing a simple tax return, I don't need to fill out thirteen forms required for self-employment. Having a form that dynamically hides or highlights sections or fields based on previous information means I don't waste time gathering information I don't need, or panicking because I don't know what that field is even asking for.

Instead, the example given is about modularizing code so the presentation logic and business logic are in different layers. This is mainly an issue if you have multiple interfaces attached to the same process, but can be helpful for simple interfaces because it helps the developer conceptually separate the types of logic, leading to potentially better code. E.g., a simple form might validate itself in the code for the submit button's onclick event. This works fine, but now we want to create a desktop application that does the same thing. Since all the validation code is in the submit button for the web form, our program can't access it. By moving the validation code to a standard library, we can update the validation code later without breaking either interface or duplicating effort.

For small programs, this isn't really important. And the availability of libraries for things like phone number validation means it's often better to handle validation right on the form (using javascript or PHP on the web form and something like C# or VB on the desktop app) instead of calling a function from a module on the server. But when you have complex validation rules, it can make life much easier to separate interface code from data logic. 69.28.44.248 (talk) 00:38, 28 August 2021 (UTC)

Not really an anti-pattern.

"Anti-patterns" aren't less than ideal code. Anti-patterns are solutions to a problem that cause more trouble than they solve. Now, the article on anti-patterns is... well, crap... and has lots of issues with this itself. But there seems to be this notion that any code that's less than perfect is an anti-pattern. This isn't true.

In this case, the problem is that we need to validate the user's input before submitting it. So we attach a function to the submit button that validates the user's input and returns error messages if there's a problem. This works, and is far better than accepting unvalidated input. It's therefore not an anti-pattern, because the solution wasn't worse than the problem.

An anti-pattern would be if there was a bug in the validation function that we solved by copying all the code to each interface and customizing it to be perfect, instead of just fixing the bug in the validation library. We probably introduced more bugs by customizing the logic in four different programming languages, and we introduced a maintenance nightmare by having multiple copies of the same code, in different languages to boot. (It would also have to be something we do on a regular basis, since one of the criteria for "anti-pattern" is that's it's a commonly used solution.) 69.28.44.248 (talk) 00:38, 28 August 2021 (UTC)