20 Mar
2007
20 Mar
'07
3:23 p.m.
for applications sometimes the user want to edit
an object that
has many instvars to edit or it's composed. I guess that this could
lead to forms too large to be practical for the end user's daily use.
Certainly.
This could be archieved by different form building
policies. A
concrete form build's policy should define the look of the
component. To give a simple example of this policy: if the
component to build is no bigger than 6 "fields" it should be like
"the normal ones" (actual default) but if it has more than 6
"fields", put the first 6 in a tab and the next 6 in another tab
(or more, until the total ammount of fields are reached).
A subclass (or a replacement) of MAContainerComponent is your friend.
There are other ways to define custom rendering strategies as you can
see on the slides 48 to 54 at:
http://www.lukas-renggli.ch/smalltalk/magritte/tutorial.pdf
The policies should be extensible but generic
enough to
maintain economy in the design. Is also desirable collaboration
with user's role to gain additional customization of the observation.
When developing an application I basically find myself describing
objects (1), writing new or custom interpreters of these descriptions
(2) and adding some glue code (3).
As you observed the interpreters included with Magritte are very
basic and usually require some customization when being used in a
real world applications. However the requirements for different
applications are usually so different that (in my opinion) it makes
no sense to try to make something that works for everybody. For
example, have a look at http://www.juniorwebaward.ch and click on
'Anmelden' (or 'S'annoncer' if you are in the french version). What
you have there is a flow of automatically generated Magritte forms.
You have something very similar at http://www.seasidehosting.st,
however there are some distinct differences. It is very easy to
iterate over a set of descriptions and build your own custom
interface and integrate it with different validation strategies.
A smarter policy could take advantage of grouping
info set in
the descriptions. As an example some fields could belong to the
#'admin.indetification' or #'operator.identification' group/role to
keep grouped the right fields of the editor's form for the object/
model.
For the project I am currently working on I added a group property to
MADescription that does exactly that. The interpreter looks like this:
renderContentOn: html
group := nil.
html heading level: 1; with: 'Preferences'.
html form multipart; with: [
self editor description do: [ :each |
each group = group ifFalse: [
html heading level: 2; with: (self labelForSelector: each group).
group := each group ].
html heading level: 3; with: each label.
html render: (self editor childAt: each); break ].
html submitButton
text: 'Save';
callback: [ self editor commit ] ]
PD: as a side note I'm evaluating to use Magritte
with Glorp
mapping (like Ramon Leon suggest) so, if I'm undesrtanding this
right, the descriptions to map the persistance of the model objects
should be "like" another role observating them but describing the
persistance wanted.
I am using properties for that, e.g. something like #bePersistent to
tell the description to be considered for persistency or
#beSearchable to tell the description to build indexes and to be
considered for searches, etc.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch