Hi, > So, instead, with this new system (note I wasn't involved with the old > system), I do everything with metadata. (Credit where credit is due, the > other programmer was starting to do some of this, though he couldn't quite > take it down to the interface and there are some things I had to add > later.) Every "thing" (class) has a description of what it's made out of, > and what type each of those things are. When I go to edit an instance, the > Javascript pulls down that description, and a description of the instance > (and all of its associated sub-instances), and instead *generates* a form > to edit the object based on what it is made of.
Ok. I can assure you that I've been doing that myself, and that this attitude describes my general approach to computers and programming: If the machine can be told to do tedious work for me, I'd rather tell her how to do it than do that work myself for the thousands time. I did this for a LDAP browser/editor once, nice thing. But - there is a big BUT here - if we're talking about GUIs, we inevitably enter the realm of taste and customization requirements. And that's the point where things get tricky: technically inclined people can be easily satisfied with simple and pureley functional interfaces. But even I as a strong FFF (form follows function) believer have to say: The form _does_ matter, once the function is in place. In my more complicated qt forms, I had to invest quite an amount of time to rearrange my controls in a way that (hopefully) communicated the purpose of the whole thing. These days the rollout will come and certainly some feedback will tell me that I still didn't do a perfect or even good job. But then I'll fire up my designer, and can rearrange things - without further bothering in the code. To me the importent lesson to learn is not to mingle layout with logic. And as layout follows its own rules (that techies sometimes have difficulties to grasp), one should be as flexible and powerful with layouting tools as it gets. > How do I decide the order to create the fields? Classes carry a metadata > field called "order" that lists the fields it wants in order, the > remainder will by default be tacked on the end. What if I don't want a > certain field to display? There's a metadata field that lists the ones we > want to display for editing, there's another I can use to just filter a > couple out if the first isn't present. What if I want a particular widget > to do something special like be a certain width? I've created a metadata > "escape hatch" that lets me pass parameters directly to the <input> node; > it's "bad style", but sometimes useful. Everything I use is backed by a > database which has limited typing abilities, so I have a field called > "humantype" that declares the human type of the data, so I can then create > intelligent widgets for that, too. One of the things we can do, for > instance, is create an "image" widget that specifies a URL for an image, > and as validation, shows it there in the browser. We could also make it > accept uploads. Then, just by labelling a field as an "htmlImage", we get > the image editor, no form redesign, no muss, no fuss. I'm not convinced that this is really a superiour way to go. I'm all with you in terms of form-validation, constraint checking and mapping to the persistence layer. I do all of this based on meta-information (or reflection, which is the same). But what you propose is that you create a style-annotation which in the end will grow until it becomes a unmanagable beast. Instead, I prefer to have the designer (this time the person doing the html templates, not the tool) make the decision if a text-property of my object becomes a simple <input type='text'> or a <textarea> - to me, both just contain and propagate strings. So I say: Use html (or qt xml gui description files) for what they are, and programming for the rest. Having said that, I can only emphasize again that I'm very well in favour of automation of tasks - and where my data-types have an inherant flexibility, I certainly prefer to generate editing forms (as e.g. zope does for zclasses) instead of having to write them on my on. But usually customization will be required, and then I'll have to deliver it. -- Regards, Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
