----- Original Message ----- From: "Gregg Irwin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 29, 2002 5:53 AM Subject: [REBOL] Re: Version 0.1 of a grid style
> 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 > > > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
