Re^2: Is there a Perl MVVM or MVP framework?

[romandas]

Thanks for the reply.

I figured the app was a bit small for using a framework. What isn't coming clear though is how all the bits of the GUI get organized. I mean, I can create a button and a menu, but do I keep all these in the same file (called GUI)? Or is each window a package?

I figured the framework would help me understand how it's all supposed to come together.

[halfcountplus]

Okay, like I said, I have done some stuff with perl's Tk module. I've also done GUI programming in C with Gtk+.

GUI API's are "widget" oriented. A button is a widget. A text entry is a widget. A window is also a widget. Some widgets "belong" to other widgets -- perl's Tk module is object oriented. Usually there is considered to be a "top level" widget which is the eventual ancestor of all other widgets. The top level widget is a window.

So the widgets are perl objects created from widget classes, which some classes inherit from others. Ie, no, each window is not a package unto itself. TkCodex is pretty complex and in fact does use a database (via Storable, not SQL) but it is still all one file (1300 lines/45k -- I am not totally proud of the sometimes sloppy/dense looking code, but I still use it on a near daily basis and it has not required any bug fixes in a year).

That is the general scheme of all GUI libraries, whether in perl or not (altho in C there are no formal objects/classes, the idea is same). I would recommend Tk because it is a common perl package, and it is highly functional without being to hard to use. Gtk will likely match your destktop better on a linux box, and has probably some additional capacities if you want to embed 3D graphics, et al. Outside of linux, it may "clash" and is possibly harder to learn/use than Tk (certainly, the C library is...). Qt would be a good choice on windows or mac, but I notice perl/Qt has been unmaintained for a long time.

I also know there are tk and gtk programmers here at perlmonks -- they helped me. So take your pick and if you have a problem, this is the place to get assistance. Like I said before, and I can't stress this enough, do a small experimental project FIRST before you start fooling around seriously. Life will be much easier that way and the time it takes will be saved later because of the learning. An address book, or anything else you can think of to make into an SQL database, is ideal. You do not need to separate the GUI and the db code into separate packages (altho you can if you want). You just use the GUI buttons or whatever to issue queries, insertions, what-have-you (I'm presuming you've already done a bit of SQLite manipulation in perl using DBI), and you can display strings using "label" or "textarea" widgets.