Views & widgets - a discussion of solution

[Mackram]

So based on Lesile's suggestion the issue of Views & widgets seems to
be one of immediate need so I took a quick (or maybe too quick) look
on the form and code for these two entires and there are a few things
I am not sure I understand.

Mainly my question resides on why a view is not simply an abstraction
of a set of composite widgets? My understanding is that views are
singletons at the current implementation while if they were simply
made up of widgets then they themselves would no longer be
singeltons.

So before I embark on this task I would like to know why the choice to
build views separate from widgets? Are there any set of
functionalities that result from the current design decision and are
they needed to be preserved?

Thanks for the help and looking forward to this.

[Saikat Chakrabarti]

Hi Mackram,

It's great that you are trying to solve this problem. I started on a
solution a while back, but ran out of time to actually refactor the
Weblocks code base. My code is here:
http://bitbucket.org/saikat/weblocks-saikat/ (it seems you have
already found it though) and there is some previous discussion about
it here: http://groups.google.com/group/weblocks/browse_thread/thread/b4a835d9510d9285/012d70112241f587#012d70112241f587
. But basically, the views being singletons thing is pretty much
acknowledged as a problem (someone should correct me if I am wrong),
and what you are suggesting - making views a mapping between models
and widgets - is pretty much the solution I was trying to implement.
If you want any help getting through my new code or want to just
bounce ideas about the view refactor, please contact me - I still
don't have time ta actually get the code to something fully unit
tested and stable, but I would love for someone to follow through with
it. Below is an E-mail I wrote to Leslie a while back on the current
state of the code in my branch:

> I just pushed the changes I had made so far to
> http://bitbucket.org/saikat/weblocks-saikat/. Basically the state of
> the code right now can largely be gleened from the asd file. My plan
> of action was:
>
> 1) Go through and get all the widgets working again with the new view
> code. I started this and was in the middle of refactoring dataform.
> I was going to change things to make a form widget that is essentially
> what quickform was, having a "dataseq" widget that just displays a
> view's data in a list, and dataform would use these two widgets. You
> can see the beginnings of these in data-editor.lisp. Essentially, I
> want to move all the display code that used to be in views up to the
> widget layer, and this class structure made a bit more sense to me
> than how it is currently.
>
> 2) As I am refactoring widgets, I would add on features to the views
> that seem necessary.
>
> 3) Do a comparison of features between views and views-old to see
> which ones should get ported over after getting all the widgets to
> work.
>
> I have made the basic view classes and was working on refactoring the
> widgets (currently working on the form widgets). If you want, I can give you admin access on my repository if
> you want to just keep it as the fork for this refactor.

Thanks for doing this =).

-Saikat

[Leslie P. Polzer]

On Jul 5, 11:22 pm, Mackram <mack...@gmail.com> wrote:

> Mainly my question resides on why a view is not simply an abstraction
> of a set of composite widgets? My understanding is that views are
> singletons at the current implementation while if they were simply
> made up of widgets then they themselves would no longer be
> singeltons.
> So before I embark on this task I would like to know why the choice to
> build views separate from widgets?

It was part of the original design decision to base view stuff on
singletons for performance reasons.

Now there's agreement that this keeps us from doing important
things with views so we need to change it.

Most people here also don't think that the performance penalty
will be serious.

> Are there any set of functionalities that result from the current
> design decision and are they needed to be preserved?

Not related to the singleton design: we definitely want to keep the
view DSL, i.e. everything behind the DEFVIEW macro. The mechanism
behind it may change but we still want to be able to define our views
declaratively after the rewrite.

[Jan Rychter]

Mackram <mac...@gmail.com> writes:

There were several discussions on the subject -- please take a look at
the list archives. Here's an additional collection of loose thoughts
that I gathered from some private E-mail exchanges:

I would suggest thinking about views in weblocks as something similar to
database views -- stateless mappings from your data model to
presentations.

Presentations should be widgets with an additional API for storing and
retrieving data.

IMO views should *NOT* be widgets. We should keep their stateless nature
and not mix in any rendering code. Instead, we should have a form object
that would use a view to a) get a list of necessary presentation
widgets, b) create and manage those presentation widgets, c) tell the
view to update presentations based on data model, d) tell the
view to update the model based on presentations and e) handle the
validation loop (asking the user to correct errors).

While we're there, we might as well do some renaming and refactoring --
I find the current dataform/quickform/datalist/dataseq/datagrid
confusing. But perhaps it's just me.

When I tried to list the things views should know or do I came up with
this:

-- maintain configuration of presentation widgets, parsers and
validators so that the entire form-processing machine may be
constructed,

-- maintain mappings between the data model (possibly multiple objects
and multiple classes) and presentation widgets (one direction goes
through parsers, the other one I do not know)

-- perform view-level validation (normally delegate validation to
presentations, it's their job, but you also want to have view-level
validators, see the :satisfies for views in weblocks)

Also:

I would say anything that can be called "part of a mapping" and is
stateless belongs in the view. Also, anything you might want to inherit
in your derived view definitions. The widget handles state and
rendering.

Hope this helps.

--J.

[Leslie P. Polzer]

Thanks for your important comments Jan.

It shows that you have given a lot more thought to views compared to
me.

Only a small comment:

> While we're there, we might as well do some renaming and refactoring --
> I find the current dataform/quickform/datalist/dataseq/datagrid
> confusing. But perhaps it's just me.

It's confusing but not necessarily inappropriate.

Suggestions welcome as always.

Leslie

[Saikat Chakrabarti]

> There were several discussions on the subject -- please take a look at
> the list archives. Here's an additional collection of loose thoughts
> that I gathered from some private E-mail exchanges:
>
> I would suggest thinking about views in weblocks as something similar to
> database views -- stateless mappings from your data model to
> presentations.
>
> Presentations should be widgets with an additional API for storing and
> retrieving data.

The implementation I have currently has views, view fields, and
presentations. Views keep track of the data object the view is mapped
to and whether or not the view's data can be persisted. View fields
are widgets that have state, and they use presentations (which are
stateless) to render themselves. This is a bit different from what
Jan is describing, I think (though I think if I substitute what he is
calling presentation for what I am calling view fields, it is almost
the same), but there is discussion about this design in the thread I
pasted earlier.

>
> IMO views should *NOT* be widgets. We should keep their stateless nature
> and not mix in any rendering code. Instead, we should have a form object
> that would use a view to a) get a list of necessary presentation
> widgets, b) create and manage those presentation widgets, c) tell the
> view to update presentations based on data model, d) tell the
> view to update the model based on presentations and e) handle the
> validation loop (asking the user to correct errors).

There is still some validation done at the view level with my current
implementation, though no rendering. Though I see Jan mentions that
below. Otherwise I agree with all that.

>
> While we're there, we might as well do some renaming and refactoring --
> I find the current dataform/quickform/datalist/dataseq/datagrid
> confusing. But perhaps it's just me.

I agree. I started refactoring at least the whole form widget class
hierarchy to have an underlying form class that is essentially like a
quickform, and building the thing that dataform is supposed to be on
top of that (always seemed weird to me to have the larger class -
dataform - be the base class for quickform).

[Leslie P. Polzer]

Saikat Chakrabarti wrote:

> I agree. I started refactoring at least the whole form widget class
> hierarchy to have an underlying form class that is essentially like a
> quickform, and building the thing that dataform is supposed to be on
> top of that (always seemed weird to me to have the larger class -
> dataform - be the base class for quickform).

To elaborate on my position regarding forms (my earlier comments
were mostly about the table widget hierarchy):

The current dataform is too rigid and bloated indeed.

There are many types of forms so it would make sense to have
a lean base class. Not necessarily quickform though.

[Jan Rychter]

"Leslie P. Polzer" <leslie...@gmx.net> writes:
> Thanks for your important comments Jan.
>
> It shows that you have given a lot more thought to views compared to
> me.

I don't know about that -- but fact is I've been doing quite a bit of
thinking about those things. I'm sorry I couldn't quite find the time to
actually implement the code :-( It doesn't look as though I will be able
to anytime soon.

My ramblings aren't necessarily right and consistent -- I just wanted to
drop them in hoping they might be useful to someone actually doing the
work.

--J.