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