2 Answers
2

I first started using Traits and TraitsUI to build GUI's as a postdoc researcher in Mechanical Engineering. My previous experience with building GUI's was with MATLAB's GUIDE, and I found TraitsUI to be very straightforward and easy to get started with by comparison. TraitsUI has a very linear progression of progress versus effort, and for the limited amount of GUI building I did with it, it was more than sufficient.

As a professional developer (full disclosure: I work at Enthought), my perspective has shifted somewhat. First, it is important to make the distinction between Traits (the typing, validation, notification, and dependency system) and TraitsUI (the GUI layer built into and based on Traits). I use Traits all the time, and it undergirds a lot of the code I write. Particularly for its dependency and notification utilities, I consider it to be invaluable.

It doesn't take too long, however, to start bumping into the limitations of TraitsUI for application building. As I mentioned before, TraitsUI is sufficient for small- to mid-sized applications, but it gets difficult to create more-complex layouts, and we were spending a lot of time wrestling with TraitsUI to produce larger, more involved and flexible application interfaces.

That led to the more-or-less blank-slate development of Enaml. Enaml uses a constraints-based layout system at its core and integrates with Traits. From the outset, it addresses the layout weaknesses of TraitsUI. Every one of us that has used both systems prefers Enaml, and we consider it the tool of choice for GUI-building moving forward. The level of control and flexibility to lay out GUI's is remarkable --there are some nifty demos to check out in the repo.

That said, there is a slightly (but only slightly) steeper initial learning curve since it is helpful to have a grasp of certain concepts such as MVC separation from the outset. An experienced developer would see the value in this right away, but it might be more of a hurdle for a new user with a science or engineering background. It is only a slight hurdle, though, and easily cleared. Also, while the feature set is nearly complete, there are still a few holes. There is steady progress on filling them in, but Enaml is technically still in beta.

Overall, if you are trying to decide which tool set to learn, my recommendation is to learn Enaml. It's what we are and will be using going forward.

thanks for taking the time to elaborate your extremely detailed answer. I added more context to my original question, if you don't mind answering or pointing me to an specific Enthought forum, thanks again!
–
PabloGJan 2 '13 at 13:27

1

Unfortunately, I am out of depth on the rest of your question. Let me recommend you to the Enthought-dev list (enthought-dev@enthought.com). I'm sure you will get some more specific help there.
–
Tim DJan 6 '13 at 21:47

To answer the secondary part of the question, there isn't any ORM or database support baked-in to Traits, so you'd have to roll your own. This is largely because Traits was developed to support scientific application development, rather than enterprise app development (but that is is why Traits does have NumPy support backed in).

There's an unfortunate awkwardness caused by the fact that most ORMs (such as SQLAlchemy, Django's ORM, and I see Peewee as well) and Traits both use declarative-style interfaces and metaclasses to make defining object structures very easy, but at the downside of not playing very nicely together. If you want to avoid an explicit bridging layer then you need to have a solid understanding of both Traits and the ORM.

If I were developing this sort of app, I'd probably end up avoiding the use of the ORM and writing directly from traits to the DBAPI layer, possibly defining some custom trait types for this purpose (eg. Property trait factories whose fget and fset execute database queries).

All of that said, and admitting to my bias in favour of Enthought's technologies, there are some tools out there which may be more suited to sitting simple CRUD UIs on top of a database. One possibility is Dabo, but there are others out there such as Camelot.