20 Mar
2007
20 Mar
'07
2:06 p.m.
Hi there,
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.
One solution to this is could be the partition of the form into smaller
forms with tabs. The problem is that one should describe once and let the
description prepared to be capable of build several composed forms to each
model.
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).
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.
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.
I'd like to hear opinions about this or to know about better approachs
to solve this problem.
cheers,
Sebastian Sastre
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.
20 Mar
20 Mar
3:23 p.m.
New subject: 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
9:29 p.m.
New subject: Adaptative (to user's role) edition of objects with many"properties"
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
21 Mar
21 Mar
12:02 a.m.
New subject: Adaptative (to user's role) edition of objects with many"properties"
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.
I am sure the maintainer of the Magritte Glorp package can help you
here. This is something that I did in other applications. To see an
open-source example have a look at #beEditable and #bePersistent in
Pier.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
6257
days inactive
6257
days old
3 comments
2 participants
participants (2)
-
Lukas Renggli -
Sebastian Sastre