The same pitfalls exist in Web app development in the form of Templating systems and/or languages that encourage burying Model logic inside HTML. That capability is great for quickly cranking out a few pages that slam some forms into a DBMS. But when the application starts expanding, and the page contents and navigation get complicated, that approach also starts to suffer from the forest v. trees problem, as well as the ripple effect when minor changes are made to either the view or the model.
Some years ago I also discovered that perl/Tk isn't suitable for large scale GUI apps,
Perl/Tk is perfectly suitable for large scale apps (I know it is; I've seen me do it). Tcl::Tk probably is too. (tho tracking down widgets for it tends to be much more of a chore than just hopping over to CPAN). wxPerl is probably also a capable solution. And now my personal preference is for browser based AJAX/Javascript solutions. But when model logic gets muddled up with view logic, they will all suffer from both tangled complexity, maintenance ripple effects, and probably GUI lock-in.
So, to reiterate: isolate view logic from the model, and avoid clever code (e.g., pseudo-events, or GUI dispatched closures loaded with model logic, etc.)
In reply to Re^3: Perl Tk - propagating events
by renodino
in thread Perl Tk - propagating events
by TGI
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |