Integrating GWT 2.1 Cell Widgets and Pectin Validation

[Mirco]

Hi,

Has any of you took a look at how integrating GWT-Pectin with the new
Cell Widgets library that'll be released in GWT 2.1.

I've been looking into it but I'm not sure how to proceed because of
the Cell's design, which is based on the Flyweight pattern. A Cell is
not a graphical object (it is not a UIObject's children), but rather
is a template for building the graphical element. Therefore you can't
count on any of the HasValue or similar GWT interfaces, which absence
makes it difficult to integrate GWT-Pecting's validation to these
elements. I'm considering creating a PectinCell to make the glue, but
this won't be easy, it requires a considerable work, and I'm not even
convinced it will even work... so before getting myself stuck I'd
better ask :)

Is there any work going on in the direction of integrating validation
with the new GWT Cells? Any thoughts or idea to try out?

Cheers,
Mirco

[Andrew Pietsch]

Howdy

I've briefly used the CellTable but since the fly weights just generate raw html strings (as I understand it) I don't think there's a practical way to use pectins validation DSL with them.   You could probably still use the validators themselves since they just operate on a value and push their results into a collector.  But how you'd display the results in the view might be a bit tricky.  As a side note I've been chatting with Stephen Haberman (of Bindgen) and I've been looking into how we could use it to move pectins validations out of forms, but it's still very early days and it's quite a complex topic...

I have just started experimenting with some controllers for handling lists of objects.  I got a very initial EditorListController that uses a factory to create an EditorController for each row which then is displayed in an IsIndexedContainerView widget.  Currently the EditorListController creates and disposes the EditorControllers with reckless abandon but in the future I hope to have it cache and reused them (shouldn't be hard to do).  The EditorControllers can use the normal "FormModel bound to View" approach.  It's not a style that would scale to a large number of rows on screen, you'd need to use something like a `PagedListModel` to limit number of rows being displayed/created.  I'm also not sure if it could be used to build a HTML table structure like the cell widgets (since it's currently all based on widgets and not DOM elements).  The EditorListController currently has a `collectResultsOf(function).reduce(function)` style API so you can easily add business operations to your EditorListController that run on each row controller (e.g. collecting validation results, computing global dirty states etc)  My hope would be to support quite a rich API for the controllers so they support incremental building, models for state such as loading, animation out of the box etc.

Anyway, it's very early days for that and you'd need to see what your requirements are and if you're displaying large numbers of rows (in a scroll pane for example) the cell table stuff would be the way to go.

Cheers

Andrew 

[Stephen Haberman]

> As a side note I've been chatting with Stephen Haberman (of Bindgen)

Speaking of bindgen... :-)

bindgen makes dealing with tables very nice, as it's bindings can be
stateless, meaning you instantiate/declare them once, and then reuse
the binding to get values out of multiple instances.

For example:

EmployeeBinding b = new EmployeeBinding();
CellTable<Employee> t = new CellTable<Employee>();
t.addColumn(BoundColumn.ofString(b.name());
t.addColumn(BoundColumn.ofString(b.address());
t.setData(employees); // I forget exactly what this API call is

When rendering, column1 can use the single binding it was passed to
it to ask "what is this employee's name", then ask "what is the
next employee's name", etc., based on what employee CellTable
hands to it.

Here is the BoundColumn class:

http://github.com/stephenh/gwt-mpv/blob/master/user/src/main/java/org/gwtmpv/widgets/cellview/BoundColumn.java

But the usage example above is really ugly. It needs a pectin quality
DSL. :-)

I haven't used CellTable a lot (yet) either, so this is just a
prototype. It needs a lot of work.

Tangentially, I really wish bindgen wasn't needed, that what it
accomplishes was baked into the language. Closures are close, e.g.:

t.addColumn(BoundColumn.ofString(|e| => e.name))

But doing read/write with closures requires repetition, e.g.:

form.addField(|e| => e.name, |e,newValue| => e.name = newValue)

Which is how Lift does things, AFAIK. It works, but is a lot of extra
typing when just "e.name" should do.

- Stephen

[Johan Rydberg]

This is just from the top of my head, but ..

Shouldn't it be easy to hook up the validation in the ValueUpdater, or
is that too late?

[Mirco]

Guys, let me thank you all for your immediate feedback, really
appreciate it! And thanks Stephen for sharing your code, I'll
definitely check it out.

Though, as I was fearing, integrating validation and a few more
features will take some time...

@Johan: Yes, theoretically you can use the ValueUpdater for running
the validation, though you still got the problem of displaying a
visual feedback in the UI since the ValueUpdater interface does not
reference the value's source (the DOM element...). I believe you need
to hook in the Cell's 'onBrowserEvent' and there carry out the
validation. At least, this was the approach I had in mind for getting
the thing to work...

[Stephen Haberman]

> Has any of you took a look at how integrating GWT-Pectin with the new
> Cell Widgets library that'll be released in GWT 2.1.

I've spent some time today playing with CellTable, and here's my primary
thought wrt using CellTable with pectin-style rich models.

CellTable's differentiating feature is that it flyweight-based Cells
can scale to 1000s of rows.

However:

1. If you have 1000s of rows, will the browser handle 1000s of rows X Ns
of columns pectin model objects taking up memory, doing the various
smart/reactive things they do?

2. If you don't have 1000s of rows, say <100, why bother with
CellTable's different/flyweight-based API? Use regular, pectin
-loving widgets, in a style somewhat like:

http://www.draconianoverlord.com/2010/03/31/gwt-mvp-tables.html

(Ugh, I really need to update that.)

So...I dunno, what do you guys' think about having "more than a few"
rich model objects floating around?

Maybe I'm being too pessimistic; given they're pure JavaScript objects,
and not all hooking up events (somehow leveraging the CellTable's event
dispatching), maybe it would be fine?

Either way, I'd love to see a heavy dose of pectin DSL awesomeness
applied to the CellTable API. :-)

- Stephen

[Andrew Pietsch]

CellTable's differentiating feature is that it flyweight-based Cells
can scale to 1000s of rows.

However:

1. If you have 1000s of rows, will the browser handle 1000s of rows X Ns
  of columns pectin model objects taking up memory, doing the various
  smart/reactive things they do?

I can't imagine pectin being performant in that case.

 

2. If you don't have 1000s of rows, say <100, why bother with
  CellTable's different/flyweight-based API? Use regular, pectin
  -loving widgets, in a style somewhat like:

  http://www.draconianoverlord.com/2010/03/31/gwt-mvp-tables.html

  (Ugh, I really need to update that.)

So...I dunno, what do you guys' think about having "more than a few"
rich model objects floating around?

I've been taking a similar line with the EditorListController stuff, the row controllers (and their models) get recycled so it would just be an issue of how long each row takes to re-render after the row data changes rather than building a whole new row.  I think this should work quite well for lists with pagers and filtering etc (buyer beware (c:)

But if you need lots on screen at once (or in a scroll panel) then I think the flyweight option would be the only way to go.  You might be able to do a page swap type thing with scrolling (a bit like how google maps works with tiles) but that would be non-trivial and would again come down to how fast pectin is at model.setValue(rowDataObject).

 

Either way, I'd love to see a heavy dose of pectin DSL awesomeness
applied to the CellTable API. :-)

I have very reasonable rates (c;

[Mirco]

> 2. If you don't have 1000s of rows, say <100, why bother with
>    CellTable's different/flyweight-based API? Use regular, pectin
>    -loving widgets, in a style somewhat like:

Now that I see all the implications I can definitely relate to that,
and
in our case we would not have needed such a fine-grane solution for
handling tables... we rarely have more than a dozen of rows and,
when we do, they are more presentation data that do not allow on-fly
modifications (therefore, no need to hook a gwt-pectin rich model in
these cases...).

Bottom line, I guess we need a meeting here to see where we should
be heading :)


Thanks again Stephen.

-- Mirco