20 Mar
2007
20 Mar
'07
9:29 p.m.
This is so interesting..
I didn't use Glorp before. Can you tell me more about how I can take
advantage of your #beSearchable group proposal using Glorp? Some reference
to start with would help.
thanks,
Sebastian Sastre
-----Mensaje original-----
De: smallwiki-bounces(a)iam.unibe.ch
[mailto:smallwiki-bounces@iam.unibe.ch] En nombre de Lukas Renggli
Enviado el: Martes, 20 de Marzo de 2007 11:24
Para: Magritte, Pier and Related Tools ...
Asunto: Re: Adaptative (to user's role) edition of objects
with many"properties"
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
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki