Cool, sounds like it's in pretty good shape. I'm going to see if I can
get some time to look at the source some time soon.
Thanks,
Jack
Tin wrote:
Jack,
The only "issue" I can think of right now is that the current edit
isn't committed when a column gets resized/moved. There is also the
"rerenderOnResize" option on a column definition that currently
triggers a complete rerender. There's a lot of things I'd like to add
to it though. The first item on my list is to add a simple datasource
and a Model/Controller to demonstrate how this all works together.
On Mar 12, 6:43 pm, Jack Killpatrick <j...@ihwy.com> wrote:
Hmm, this is really, er, slick ;-) ... I'm glad you wrote this extra
info up, it caught my eye. Do you by chance have a known-issues list
(outside of what would come from maybe making it a plugin or something)?
Looks like a great contrib.
Thanks,
Jack
Tin wrote:
One more point.
While this may not be immediately obvious from what you see in the
examples and in the code, the key use of the grid is in MVC
applications where the grid is wired to respond to events in the
Model. In our application we have spreadsheet component of a Gantt
chart, and the Model is a "filtered" view of the tasks (rows) in the
original datasource. Suppose you collapse or expand a parent task or
enter some text in a Quick Filter textbox. The Model then
recalculates which rows are now visible, compares that with what was
visible before and fires two events - onRowCountChanged &
onRowsChanged. The latter one tells all subscribed Views, such as the
grid, that the rows in specific positions changed. The grid then only
has to invalidate/remove those rows and call grid.renderViewport() to
make sure that whatever is in the viewport is visible. The
onRowCountChanged event triggers the recalculation of the virtual
canvas - grid.resizeCanvas(). Together, this pattern makes for an
incredibly efficient, flexible and, most importantly, scalable
implementation.
I hope this helps explain some of the design elements behind
SlickGrid.
+Michael
On Mar 9, 6:58 pm, Tin <michael.leib...@gmail.com> wrote:
Ricardo,
Not using tables is actually key to making the virtual rendering
aspect of the grid work.
Each row is an absolutely positioned DIV containing DIV cells set to
"float:left".
Rows can then be easily added and removed without triggering cascading
DOM changes. In fact, this is done all the time in SlickGrid - as you
scroll, only the content of the viewport plus a small buffer is
actually rendered, leaving the browser's DOM nice and small.
+Michael
On Mar 9, 5:40 pm, ricardobeat <ricardob...@gmail.com> wrote:
Looks great. I like how the editing works.
One thing: why are you using DIVs instead of a table? That's precisely
the only case where tables should be used, to display tabular data.
It's semantically correct and can offer performance improvements, as
table elements have native properties like their index and direct
access to their children.
cheers,
- ricardo
On Mar 8, 9:31 pm, Tin <michael.leib...@gmail.com> wrote:
Hey All,
I've been working on a grid/spreadsheet control prototype during the
last couple of weeks. Seeing how there doesn't seem to be a lot of
other choices for this sort of thing, I had to write my own. I've put
the project up on Google Code and am looking for experienced
developers who can pick this up and turn it into something that
everybody can use (a jQuery UI grid plugin?).
The project is hosted athttp://code.google.com/p/slickgrid/.
Below is a copy of the project home page.
Looking forward to your feedback!
Michael Leibman
michael.leib...@gmail.com
Principal Engineer
Daptiv Inc.
--------------------------------------------------------------------------- ---------------------------------------
SlickGrid
What it is
Quite simply, SlickGrid is a JavaScript grid/spreadsheet component.
Some highlights:
Virtual scrolling/rendering (hundreds of thousands of rows)
Extremely fast rendering speed
Configurable & customizable
Full keyboard navigation
Resizable/reorderable columns
Custom cell formatters & editors
Support for editing and creating new rows.
"GlobalEditorLock" to manage concurrent edits in cases where multiple
Views on a page can edit the same data.
Why?
This is pretty much a work-in-progress prototype, so I don't feel like
spending a lot of time documenting it at this stage. I do think it is
quite promising though, so I'm putting it up for everybody to see and
play with. In its current form, it satisfies nearly all of the
requirements for the project I am working on where I am utilizing it
in an MVC application, so I'm not sure how much time I can afford on
turning SlickGrid into something that would work for everybody. If you
are willing to help out - let me know, and I'll add you to the project
so that you can contribute.
Examples
Basic use:http://slickgrid.googlecode.com/svn/trunk/example1-simple.html
Adding some formatting:http://slickgrid.googlecode.com/svn/trunk/example2-formatters.html
Turning it into a spreadsheet:http://slickgrid.googlecode.com/svn/trunk/example3-editing.html
A more comprehensive test page:http://slickgrid.googlecode.com/svn/trunk/grid.html
Documentation
See comments at the top ofhttp://slickgrid.googlecode.com/svn/trunk/slick.grid.js.
