[Bese-devel] Introduction and questions...

[Jan Rychter]

>>>>> "Marco" == Marco Baringer <mb at bese.it> writes:
 Marco> in particular i'm toying with some ideas on building a ucw form
 Marco> library (seperating out vladimir's excellent form stuff from the
 Marco> presentation stuff) which would benifit greatly from javascript
 Marco> integration.

In that case, here are some comments based on my short experience
building a simple application with UCW.

I found the current (ie) forms API rather cumbersome to use, even though
it looks very elegant at a first glance. I'm still trying to understand
just what kind of API I'd like to use -- but this isn't easy stuff.

One immediate comment on what we have now: I don't think I will ever use
its automated presentation facilities (things like generating form
labels from the names of CLOS slots). I believe that in all practical
applications (e.g. code that is used by users, not developers) one will
want to have an object specifying the interface and one will want to
provide names and paramerers for all form elements.

In general, presentation-type approach seems neat in theory, but is
usually too strict in practice. For example, viewing data and accepting
data are completely different things in most web applications -- you
usually view data grouped in tables and you accept it on a per-item
basis in forms. I can't fit that into a presentation framework without
a lot of pain.

What I ended up with in my current application is that for most forms
I'd use interface elements (specified via :component slot attributes)
for most, but *not all* slots in my classes. This meant that the (setf
(lisp-value x)...) trick wouldn't quite work for me, so I ended up with
overly large shared-initialize methods that would do the following for
an enumerated list of slots:
   (setf (slot-indirect-object s 'direct-value) (data-domain-object component))
   (setf (client-value s) (lisp-value s)))
... then performing some additional initializatioh and housekeeping for
slots which wouldn't directly map to editable form elements.

This works, but I have a feeling it's too complex. The other problem is
that you end up with too many render-slots :before and :after methods if
you want to place your various form elements just right.

The indirect-value thing is extremely neat, but difficult to use. I'd
like a more direct way of specifying what each interface element really
edits. Also, on a very practical level, my brain revolts when I see
":direct-value (indirect-value...)".

The third thing is validation. I've been thinking about how to implement
it -- and I've been thinking of using additional slot attributes for the
validator list (or validator tree) [see AMOP page 87, section
3.5.2]. That would allow us to inherit them properly, and if we could
specify that certain validators run before others (e.g. you'd want to
trim whitespace before verifying bank account number correctness), then
we would be able to sort that list (tree).

The important thing about validation is that I'd really like to see a
framework capable of generating client-side javascript validation code
for some validators. This means that implementing validators as CLOS
methods is out, also because one can't easily order them at will using
method combination facilities.

Overall, what I'm looking for is an API where I'd use a minimal number
of lines of code, but where I'd still get reasonable
flexibility. Quoting Einstein: "Everything should be made as simple as
possible, but not simpler."

--J.