[Seaside] tables

Avi Bryant avi at beta4.com
Sat Mar 22 08:48:01 CET 2003


On 22 Mar 2003, Cees de Groot wrote:

> Another solution I pursued around a year ago (totally not
> seaside-related, but I think I could integrate it), for more complex
> tables, is to describe the table with metadata and then hand it a
> collection. This is useful for somewhat larger tables, e.g. for
> on-screen reports.
<snip>
> Browsing further, I also see a couple of more heavy-weight components -
> a TableView (one of our - failed - UI experiments is to stick with
> strict MVC, we're now combining VC into 'Component'...). It displays a
> TableModel which holds stuff like the collection to display, heading
> labels, and does neat things like alternating the background colors for
> the rows and putting up/down arrows near the column headings so you can
> re-sort the table on every column;

So you know, this sounds almost identical to Seaside's TableReport.

> An unrelated example is that at the moment, we're changing the UI to be
> comprised of what we call 'Browsers', high-level components that control
> a logically related set of domain objects - in our ISP setting, we have
> a customer browser (actually a Party browser), a domain browser, a
> finance browser, etcetera. All objects displayed need to be able to spit
> out a link (with caption) to a browser that will open on them; the idea
> is that we use these links all over the place, and when you switch
> browsers (moving from one 'logical domain' in the application to another
> by following these links), a 'breadcrumbs' trail is built up on top.
> Without help of the domain objects, this'd be undoable.

Yeah, I'm also a fan of that approach.  I think you can do a lot with each
object being able to hand you view/edit/create/row/link components for
itself.  If you pushed this far enough, you could probably end up with a
decent answer to "naked objects" for the web.

Avi



More information about the Seaside mailing list