[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