Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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