[REBOL] Re: Version 0.1 of a grid style
From: greggirwin:mindspring at: 28-Mar-2002 11:53
Hi Brett,
<< I got into analysis paralysis trying to solve that dynamic generation
problem so I decided to write something just to get some movement and,
ahem, to see what issues arose ;^) >>
Good idea. I'm a big believer in "something is better than nothing."
The grid demos on your site are great. The first one doesn't run. I think
it's because it's using DO instead of USE-SCRIPT on %face-grid.r.
<< *The "smarts" for handling faces as they come on / go off "stage"
should handle scrolling of the grid and resizing of rows/columns
perhaps through a cache. >>
Yeah, I've thought about that as well. If you have a slider and they grab it
and drag it, it would be working furiously.
<< *I'd like to see some easy way to plug in controller(s) for handling
data and validation. A problem is creating/handling data events
generically when you don't know what the cell face is that will
show/edit it. I'd like to avoid forcing a special api/behaviour on the
cell faces, but maybe that is the only way. >>
What about a callback/handler function?
<< *What is the priority for attributes between row and column or is there
a nice merge policy?
*My current attibute priority is: more specific = higher priority, but
I wonder if there is cases when you want the reverse or maybe both! >>
As long as it's documented, I don't know that it matters much. I agree with
specificity = priority though. You could have a priority setting or maybe a
block of priorities that sets the order of processing, kind of like the
implicit ordering in an effect block.
<< *Should the attributes of different levels (global,row,cell) be mashed
together to produce a cell face like I'm doing now or implemented as
seperate "layered" faces? Or a combo of this and the last point? >>
I'm sure it will be a tradeoff between infinite flexibility, ease of use,
and reasonable maintainability. :)
<< *The functionality should be seperable so that a given script only
needs a grid smart enough for its purpose. >>
Agreed. Simple, inflexible, display-only grids will account for a large part
of what people need, and so should be very simple to use. Add editing
capability (e.g. Excel) and you cover another good chunk. Being able to
select a range of cells, and copy and paste them, would be a big selling
point I think.
A lot of the COM/OCX based grid controls are so complex now it's scary and
all their flexibility does *not* automatically translate into more usable
interfaces.
--Gregg
