On Tue, Jun 14, 2005 at 07:41:55PM +0100, Tim Larson wrote: > On Tue, Jun 14, 2005 at 10:41:57AM +0200, Max Pfingsthorn wrote: > > Thank you very much, Reinhard! > > > > I'll fix that and submit it later today. After the email by Tim > > yesterday, I am a bit afraid that most work is already done and this > > project gets too small... I guess there is some bits of designing to > > be done, and the "marketing" anyway (i.e. docs and further examples). > > Does macro inheritance work yet? Or declaring single fields in the > > library?
Declaring a macro containing a single field works, but the syntax is more verbose than it should be for handling just a single widget, and iirc, it could use some work on being able to specify a new id/name for the field at the point of the macro expansion. ...And yes, there needs to be more/better documentation, and we sorely need to create some simple step-by-step examples of using the macro/library features. Another possible work area: Use the macro/library support to make full forms nestable, with either the same or different templates. The current implementation does not do this, instead requiring such dual use (stand-alone and nested) forms to be implemented as two files, the body of the form in a macro library and then another file containing a Form widget and importing the first file to act as a wrapper around it for stand-alone use. There are similar complications when it comes to using the binding and templating frameworks on nested/ dual-use forms, which could affect the structure of the base flowscripts. Drifting a little bit away from the macro/lib discussion, into my motivation for having such a facility... I would like to have a declarative way of associating bindings, form models, and templates with each other, so when a parent form tells the form framework that it wants to display some sub-form, it does not have to tie the pieces together using code/programming. My use-case is a web-based IDE for editing sitemaps, forms, flowscripts, database mappings, portal configs, etc. where any one of those may be a top-level form, and the various related files/data/configs that they reference could be opened in context as nested/sub forms. Some may think this is silly, but working toward this goal has already proven useful...causing several bugs to be discovered and the code fixed, and producing a number of new widgets now used in other contexts: struct/group, union/choose, class/new (the first implementation of macro-like reusable groups of widget definitions), and a first draft of a macro library system that works for bindings, form models, and form templates. Have fun, --Tim Larson
