When to use views vs widgets
Saikat Chakrabarti
vs. new widgets vs. new view types. Right now, I am trying to create
a list of objects where I want the list to be unordered with each item
in the list just displaying the object's title and a couple of other
fields next to each other. Is the proper way to do this to just use
the datalist widget and write a view for it, or to create a custom
widget that displays the items the way I want them to be displayed in
render-widget-body? I might want to later add some filtering options
to this list - should this filter be it's own widget that I mixin to
my listing widget? I guess in general, I am still unclear about
when to use views and when to write a custom widget since the render-
widget-body method for widgets is so powerful and it often seems like
I can just do anything I want to in there (in which case, why ever use
a view?). Should I ever be writing new view types?
Additionally, I noticed that if I try to create a view that is any
type other than sequence or table, datalist doesn't seem to work - why
is that? Are there view-type specific implementations of methods in
there that I am missing?
Thanks!
Saikat
Leslie P. Polzer
for just displaying stuff.
Table views are nice though, and especially form views provide
real value because you can specify the form in a pure declarative
manner most of the time and get validation for free.
> Additionally, I noticed that if I try to create a view that is any
> type other than sequence or table, datalist doesn't seem to work - why
> is that? Are there view-type specific implementations of methods in
> there that I am missing?
an object that isn't prepared to take this kind of view (e.g. a data
view for a dataform's form view, non-sequential view for datalist's
view, ...).
Saikat Chakrabarti
sure. You are saying that instead of trying to define a view for the
datalist widget to display the list how I want, it would probably be
easier to just write my own list widget that has a render-widget-body
that does what I want? But doesn't this make the code somewhat
redundant/break the abstraction of views from widgets? Why even have
views as a feature in the language? I see that form views and table
views can add value, but even here, unless I am misunderstanding this,
couldn't the form view or table view just be a form widget and table
widget? In this case, if I wanted to use the free validation
functionality, couldn't I just subclass a form widget (and instead of
the form widget just calling "render-object-view" on a form view in
it's render-widget-body, it would have the code that the form view
normally renders directly in it's render-widget-body method)? I guess
it just isn't very clear to me where to draw the lines of
responsibility of views vs. widgets - like why does the dataform
widget need to use a form view - why not just have it handle rendering
on it's own?.
I guess I have so far thought of widgets handling the "innards" of the
widget itself - keeping track of state and whatnot. The view, on the
other hand, I have thought of as being responsible for determining the
layout of the widget. I'm not sure if that is the proper abstraction,
but if it is, I have one more question: why are datalist and datagrid
separate widgets? Why not just have list and table be different views
that can be used with a general data-viewer widget (I guess that would
be dataseq)? It's probable that for whatever reason this is not
possible (I am still trying to figure out the extent of the power of
views), I am just curious as to why.
My apologies if some of this has been answered elsewhere in the group
- I saw some other threads about views, but much of it was over my
head.
Thanks!
Jan Rychter
> I think I understand what you are saying, but I just want to make
> sure. You are saying that instead of trying to define a view for the
> datalist widget to display the list how I want, it would probably be
> easier to just write my own list widget that has a render-widget-body
> that does what I want? But doesn't this make the code somewhat
> redundant/break the abstraction of views from widgets? Why even have
> views as a feature in the language?
Your comments are spot on.
Views are a good idea, but IMHO in the current implementation they
aren't that useful. I think the problem is that they try to do too
much -- instead of just being a mapping from the data model to widgets,
they also implement some of the widget functionality (like rendering),
some controller functionality (form processing), but they aren't really
first-class citizens.
My idea to fix this is roughly as follows:
1) make presentations be widgets, with an additional presentation
interface,
2) reduce views to maps between data model and presentations,
3) make views usable only from widgets (e.g. you have to use formview or
something similar, you can't just call render-object-view.
That way presentations would be first-class citizens (with dom-ids,
being on the children list, etc) and could participate in flows. Views
could still be stateless data maps, as (I think) they were intended to
be. And they could be instantiated as many times as one wishes. Plus, we
could keep the existing view infrastructure: view combining,
inheritance, scaffolding.
Comments welcome. I began working on this, but progress has been slow so
far.
--J.
Leslie P. Polzer
> My idea to fix this is roughly as follows:
>
> 1) make presentations be widgets, with an additional presentation
> interface,
> 2) reduce views to maps between data model and presentations,
> 3) make views usable only from widgets (e.g. you have to use formview or
> something similar, you can't just call render-object-view.
mixin,
though, since there's a need to merge presentations and parsers in
some
situations (think maximum length on text fields for example).
It doesn't sound like a lot of work, actually.
Could you perhaps publish what you've got so far?
Jan Rychter
> On Feb 17, 12:32 pm, Jan Rychter <j...@rychter.com> wrote:
>
>> My idea to fix this is roughly as follows:
>>
>> 1) make presentations be widgets, with an additional presentation
>> interface,
>> 2) reduce views to maps between data model and presentations,
>> 3) make views usable only from widgets (e.g. you have to use formview or
>> something similar, you can't just call render-object-view.
>
> Very good. We would also need to have something akin to a parser-
> mixin, though, since there's a need to merge presentations and parsers
> in some situations (think maximum length on text fields for example).
You're right about the need, but I'm not sure about the solution. I
don't know what the presentation/parser interface to widgets should look
like yet.
> It doesn't sound like a lot of work, actually.
My estimate is about 3-4 days of work.
> Could you perhaps publish what you've got so far?
I am afraid I don't have much to show yet. Once I do, I'll create a new
topic branch in my tree.
--J.
Maciej Katafiasz
On Feb 20, 11:13 am, Jan Rychter <j...@rychter.com> wrote:
> > It doesn't sound like a lot of work, actually.
>
> My estimate is about 3-4 days of work.
>
> > Could you perhaps publish what you've got so far?
>
> I am afraid I don't have much to show yet. Once I do, I'll create a new
> topic branch in my tree.
in your branches.
Cheers,
Maciej
Saikat Chakrabarti
have something to show for it in the next couple days.
Leslie P. Polzer
> I am currently working on a few things for this. I should hopefully
> have something to show for it in the next couple days.
Very good! I suggest we postpone the merge of your other changes
until later then; the views overhaul is more important.
Jan Rychter
[catching up with a huge backlog]
No, I didn't actually do anything on that front, apart from some
discussions with Saikat. He seems to have a good design planned, so I'll
be waiting for his work.
--J.