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

Version 0.1 of a grid style

 [1/14] from: brett::codeconscious::com at: 26-Mar-2002 23:50


I've been playing around with trying to make a general grid style for REBOL/View. It is an early version, there are imporant things missing like scroll bars and a convienient means to save data. But it looks promising - I reckon anyway :^) Have a look at: do http://www.codeconscious.com/rebsite/face-grid-demo.r Regards, Brett. --- Website: http://www.codeconscious.com Rebsite: http://www.codeconscious.com/index.r

 [2/14] from: gscottjones:mchsi at: 26-Mar-2002 10:41


From: "Brett Handley"
> I've been playing around with trying to make > a general grid style for REBOL/View. It is an
<<quoted lines omitted: 4>>
> Have a look at: > do http://www.codeconscious.com/rebsite/face-grid-demo.r
... I think it is looking great! What "blows me away" is how you and others are figuring out how to write your own styles. When I looked at the source on face-grid.r, it is not obvious at all how one figures out how to write this kind of stuff. Again, I wish I had more time to work with it and get it figured out. :( Brett, keep up the good work! --Scott Jones

 [3/14] from: riusa:email:it at: 26-Mar-2002 23:00


Hi! Can someone tell me where I can find detailed information about View List ? thanks! -- Prendi GRATIS l'email universale che... risparmia: http://www.email.it/f Sponsor: Gratis per te il software per inviare e ricevere SMS direttamente dal tuo PC Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=278&d=26-3

 [4/14] from: brett:codeconscious at: 27-Mar-2002 8:24


> I think it is looking great! What "blows me away" is how you and others
are Thanks!
> figuring out how to write your own styles. When I looked at the source on > face-grid.r, it is not obvious at all how one figures out how to write
this
> kind of stuff. Again, I wish I had more time to work with it and get it > figured out.
Well the code in there now was not obvious to me either. I set out to write something much less flexible and it evolved when I discovered I was writing duplicate functionality in parts. Much of that evolution was to do with opportunities Rebol offered rather than the plan in my head. Learning for me has been lots of reading of the RT styles and my attempt to get to the "fundamentals" of REBOL's "view of the world". Yep you're right - it takes time. Brett.

 [5/14] from: greggirwin:mindspring at: 26-Mar-2002 11:11


Hi Brett, << I've been playing around with trying to make a general grid style for REBOL/View. It is an early version, there are imporant things missing like scroll bars and a convienient means to save data. But it looks promising - I reckon anyway :^) >> It looks most excellent!! I'll have to dig through it a bit when I have some time, to see how it works its magic. The facet approach reads very well. I can already envision the use of rules, in place of specific cell addresses (e.g. even? row, odd? col, or a callback function that checks against the data source for dynamic facets). --Gregg

 [6/14] from: brett:codeconscious at: 28-Mar-2002 8:38


Hi Gregg, thanks :^) I've got a new version uploaded with some name changes and a bit tidier ? code.
> The facet approach reads very well. I can already envision the use of
rules,
> in place of specific cell addresses (e.g. even? row, odd? col, or a
callback
> function that checks against the data source for dynamic facets).
Its there (I think) In the first version it was called "create-cell" in this version it is called - "cell-facets". Thats how the orange/yellow board is produced. ;^) Brett.

 [7/14] from: greggirwin:mindspring at: 27-Mar-2002 15:46


Hi Brett, << Its there (I think) In the first version it was called "create-cell" in this version it is called - "cell-facets". Thats how the orange/yellow board is produced. ;^) >> Yes indeed! I get ahead of myself thinking about when scrolling is added and you dynamically generate just the visible portion of the grid, or the grid is tied to a data source and you update the appearance of the grid as the data changes. Like I said, *way* ahead... :) --Gregg

 [8/14] from: brett:codeconscious at: 28-Mar-2002 20:46


Hi Gregg,
> Yes indeed! I get ahead of myself thinking about when > scrolling is
added and you dynamically generate just > the visible portion of the grid, or the grid is tied > to a data source and you update the appearance of the > grid as the data changes. > Like I said, *way* ahead... :) 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 ;^) BTW a scrolling grid (no smart logic sorry): Rebsite / Code. C. / Grids / LibCat http://www.codeconscious.com/rebsite/library-catalog2.r The grid so far has given me ideas and has raised a few issues: *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. *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 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! *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? *The functionality should be seperable so that a given script only needs a grid smart enough for its purpose. Interesting excerice. Brett.

 [9/14] from: petr:krenzelok:trz:cz at: 28-Mar-2002 12:40


Brett Handley wrote:
>Hi Gregg, >
Hi all, I will try separate route, or we can cooperate. I think cell = face is not bad aproach, if you want to have "full control", or if you think of various handlers. Imagine coloring upon some condition, or maybe even pluggable face feel function according to some condition. That way you could create really powerfull combinations ... As for scrolling - it is not needed imo. Take the top-most pane coordinates as the cropping element. Grid doesn't need to scroll, at least vertically. It is data, which are changing, not cells themselves. Just imagine one bigger data matrix, and your visible grid area is only kind of a subface/magnifier, looking at the underlying cache. So - if someone hits arrow key down/up, page up/down, you go to cache to see if you hava data, if not, you call your handler for refilling the cache from data source. I know the aproach is a little bit complicated, but imo the only way of how to create really powerfull grid, able to browse thru tens of thousands of records. I don't want to see another "toy", which blowns up on browsing thousands of rebol block based database ... I want separate data handling layer/api, with ability to hook into SQL or other data sources ... The grid we use here at work is really cool, but it organises data in columnar data arrays = rebol blocks. I don't like it too much. It is that way to have easier handling of column addition/deletion, drag&dropping, and to easily calculate automatic columns width (pixels) adjustment element, according to the longest text (we can't do it in rebol anyway ...). But that's only the question of appropriate set-of-blocks traversing functions ... well, but that's me, my opinions, my requirements :-) Your grid is very inspiring anyway, and I can't promise anything, as I am currently overloaded with tons of work .... Cheers, -pekr-

 [10/14] 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

 [11/14] from: greggirwin:mindspring at: 28-Mar-2002 12:06


Hi Pekr, << I will try separate route, or we can cooperate. I think cell = face is not bad aproach, if you want to have "full control", or if you think of various handlers. Imagine coloring upon some condition, or maybe even pluggable face feel function according to some condition. That way you could create really powerfull combinations ... >> Yes. I really like model LIST uses, with SUPPLY, but demand based with callbacks maybe. << As for scrolling - it is not needed imo. Take the top-most pane coordinates as the cropping element. Grid doesn't need to scroll, at least vertically. It is data, which are changing, not cells themselves. >> Right. The grid face itself doesn't need to scroll, but it needs to give that appearance. In a simple model, like my draw-based grid/tree examples, you could create a DRAW block with coordinates and just CHANGE the data elements with each move. In my simple examples, I was regenerating the entire DRAW block each time, and it was still plenty fast. As a user I really dislike horizontal scrolling, so I would make that a much lower priority if eliminating it would help simplify the design and/or implementation considerably. << I don't want to see another "toy", which blowns up on browsing thousands of rebol block based database >> Yes. In the COM/OCX world, my favorite grid was TrueGrid because it had a very simple callback model (e.g. Update/RequestData (row col)) that virtualized the data from the grid's perspective. The grid was only a display mechanism, it didn't store any data in it, so there was no redundancy (or very little anyway). With most grid controls, you have your data, then you load it all into the grid (so it's now in two places), then the grid operates on it, and finally you read it back out. Now, of course, data bound grids are very popular. --Gregg

 [12/14] from: brett:codeconscious at: 29-Mar-2002 11:04



 [13/14] from: brett:codeconscious at: 29-Mar-2002 11:27


Hi Petr and Gregg, Oops #1 - Sorry for the mistaken post.
> 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.
Oops #2 - An intended reversion. I have a modified user.r to with the upside that things are made convenient for myself and the downside that I don't see what everyone else does. I think I'll revert to a standard user.r since long term that save far more work.
> << *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?
Yes I think that is the answer. My query arose in the context of the case where the grid is dealing with an arbitrary cell face. You don't know what style the user is going to give you and therefore what their behaviours are. But given the other comments in your email and Petr's great comments it is not such a big problem, because maybe we make some contraints that remove the issue. Brett.

 [14/14] from: brett:codeconscious at: 29-Mar-2002 22:41


Side note: Oops #3 - the reversion was *unintended* in my last post. Now on to the real issue. I've been rewriting the grid style. Petr, you mentioned about scrolling implemented via changing data rather than scrolling faces. This is ok if every column is the same width and you don't want to scroll horizontally. If you have different column widths then it might be better to use face scrolling for horizontal scrolling and data scrolling for vertical changes - this would be appropriate for large sets of records. I've been trying to allow different width columns but while I can lay them out I'm at a loss to know how to implement the scrolling and column resizing efficiently. Not to forget resizing of the whole grid. The grid is proving to be a rather complex thing. Looks like there will need to be many different grid styles for different purposes. Brett.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted