tightly coupled with backend, we could use some interface definition for backend, so that any backend will do

[GoogleCodeExporter]

I created a Zend Framework based backend, where each row spans multiple records.

It took some time to figure out the required format of the responses.

I also think the Add button is silly.

I just add an empty row, so that you can start adding immediately. This could 
be optional.

Original issue reported on code.google.com by mcl...@spaceweb.nl on 7 Jun 2011 at 10:42

[GoogleCodeExporter]

What was involved with this? You mean just the data abstraction part? I plan on 
abstracting out the mysql so that any backend functions can be wrapped. 

Or am I missing what you mean all together?

Original comment by Seancla...@gmail.com on 5 Jul 2011 at 4:48

[GoogleCodeExporter]

No, you are getting the point. The mysql should be abstracted out. What I mean 
is indeed that we should know what the backend gets as input and what the grid 
expects back from the backend. If you carefully document that, we can use our 
own backends.

Original comment by mcl...@spaceweb.nl on 5 Jul 2011 at 7:41

[GoogleCodeExporter]

I also agree with documenting the formats of all the channels so that other 
backend's can be created. I have a rather odd situation were I am using a 
columnar style DB that doesn't have a normal SQL style interface and knowing 
what your frontend requires would make it easier to correctly intercept the 
data flows and return the expected structures to your application.

Also including a sample SQL file with your code would also make it easier to 
run your demo and understand the requirements of your codebase.

Original comment by james.m....@gmail.com on 7 Jul 2011 at 11:43

[GoogleCodeExporter]

To  note here: in the ajax.php file in my example.  If you just echo "<pre>"; 
var_dump($grid->data); before you echo the JSON. You can see the array 
structure right there.

The hard part about this is that I'm trying to keep all the logic for sorting, 
searching, and all that out of the way so that you never have to worry about it.

But if you wanna see the data, dumping that variable is exactly what you would 
need to feed it.

As for SQL example, your right, I Should include a sample and I will with the 
next release for sure.

Original comment by Seancla...@gmail.com on 11 Jul 2011 at 4:49

[GoogleCodeExporter]

I would just like to add a few thoughts. 

Your component can be quickly found with Google if we look for a js DataGrid 
based on jQuery. It somehow deserves to become a popular component.

However, if we look into the code, we find design flaws. If we look for 
documentation, we find examples. We can inspect the code (that is how I found 
what data structures were requires by the client grid). We would like to have 
clear and accurate documentation. It should be as easy as possible to use your 
component and it should be easy to extend it. That will make it realy popular.

It would be nice for example (this is just an idea) to create an extension 
point where you process the field types. If you would create separate scripts 
for each editable field type and have them register themselves with the Grid, 
the Grid could inspect the array of field processors to see if one matches a 
detected column type from the table header. This way, you cannot only easily 
extend it yourself, but others will be able to extend it whithout touching the 
core.

The same could apply to theming, except that only one theme can be registered 
at a time.

Again, I understand you do a lot of work for this Grid and these are just a few 
thoughts.

Original comment by mcl...@spaceweb.nl on 11 Jul 2011 at 6:09

[GoogleCodeExporter]

I agree with that I need to make a "developer" guide, so that you guys can be 
aware of the main data() object, and the JSON export of all the data, along 
with all the methods use.  Its just tough to make time because I'm doing bug 
fixes and development. It's like cleaning your own room when your a maid. But 
it will get done, if nothing else, i'll hire someone to do it.

I also agree with point 2, and wish i had read this before the recent 1.8 
release.  I will compartmentalize the functions a bit better so people can hook 
into different areas. And yea the editTypes are getting long, so making those 
an object with extendable methods is the right way to go.

Thanks for you input, look for these updates soon.

Original comment by Seancla...@gmail.com on 20 Jul 2011 at 3:21

• Changed state: Accepted

[GoogleCodeExporter]

I'll handle this one.

Original comment by Seancla...@gmail.com on 29 Jul 2011 at 4:24