PDA

View Full Version : Extension Idea: Ext.data.QueryStore



jclawson
22 May 2008, 6:44 AM
So this is only conceptual right now, sorry. I wanted to get feedback on how useful you guys would think this is. It would be incredibly useful for me. Check out my blog post for a little more in depth explanation: ExtJS - QueryStore & Store Query Language (http://www.jasonclawson.com/2008/05/22/extjs-store-query-language/)

Firstly, the way our apps are usually developed is that we have a client data model and a server data model. Our client data model closely mimics that of the server data model. That is, if we have a list of users we have a User store, with user records that have all the fields that the user object on the server has. When we go to save / update we use a Store CRUD proxy to send those records to the server which then saves them.

The issue you run into is when you want to display information in a grid that doesn't mimic your data model. A simple example is turning a userId into a user name. Or displaying parent/child relationships between users. What happens then if you want this grid to be editable so that you can change a username? How do you migrate that data back to its source store? What if this could be done for you, automatically?

Currently I have custom components that do this for me automatically, but they take a bit of time to setup, and link together to get this functionality. What I am proposing is a new component called: QueryStore.

QueryStore is based off of an SQL like query that pulls data from several stores together into a single store. You could do joins, column aliases, where clauses etc. Whenever data changed in your source stores (the from clause) those changes would be migrated to the QueryStore.

Most people probably would just setup another server data provider for these complex grids. I don't think this is a good solution, especially when the data represented in those grids can be changed, or the data can be changed elsewhere in the interface. Changes should be reflected everywhere without having to refresh. And you shouldn't have to do a bunch of custom coding to migrate changes around to different stores.

I know I would find this incredibly useful, anyone else? I would love to tackle this but I am not sure that I will have time. Maybe though....

donssmith
22 May 2008, 11:21 AM
Hi jclawson,

If you haven't done so already you should look at LINQ. It has become very popular these days because of it's powerful SQL like query syntax. .Net 3.5 supports it directly and there are all kinds of extensions coming out like JSLINQ (Javascript LINQ), LINQ to XML, etc... Something to consider.

Thanks,
Don

jclawson
22 May 2008, 11:56 AM
Thats an interesting way to accomplish this. Perhaps it might be easier than creating a lexical parser.

Although I would really like to build upon the work done by TrimQuery (http://trimpath.com/demos/test1/trimpath/query_demo.html). Everyone is familiar with SQL and its very easy to read.

I really don't want to spend a lot of time working on this if no one will use it. This is a very complicated task. I am hoping this thread will gain some more interest. If not, then this project will go on the back burner.

MarcWeil
23 May 2008, 6:08 AM
Am I the only person that thinks placing SQL queries into Javascript is a fundamentally terrible idea from both a security and an architectural standpoint? It was bad enough having PHP pages with embedded SQL queries, but now embedding them in a client-side language? What ever happened to separation of application layers?

Edit: I don't mean to say that something like this wouldn't make our lives a TON easier, because it sounds like it would (especially if it resembles LINQ). I'm just saying that mixing SQL with Javascript (even "backend", so to speak, Javascript) sounds like it violates a lot of basic software architecture principles.

JEBriggs
23 May 2008, 7:23 AM
The issue you run into is when you want to display information in a grid that doesn't mimic your data model.

I addressed this issue in my application by creating an Ext.data.ObjectStore:
http://extjs.com/forum/showthread.php?t=35406

jclawson
23 May 2008, 7:43 AM
Am I the only person that thinks placing SQL queries into Javascript is a fundamentally terrible idea from both a security and an architectural standpoint? It was bad enough having PHP pages with embedded SQL queries, but now embedding them in a client-side language? What ever happened to separation of application layers?

Edit: I don't mean to say that something like this wouldn't make our lives a TON easier, because it sounds like it would (especially if it resembles LINQ). I'm just saying that mixing SQL with Javascript (even "backend", so to speak, Javascript) sounds like it violates a lot of basic software architecture principles.

I think you misunderstand... This isn't server side SQL. This sql NEVER goes to the server. That would, of course, be really stupid. This is only for constructing an Ext.data.Store from existing Ext.data.Stores so that you can more easily mirror the client data model off of your server data model. If you read my blog post I think it will make a little more sense. I often need to create grids that show data from a combination of different stores. Why should I create another data provider for this grid's store? I would rather utilize the data providers I already have and just intelligently join together data from my existing stores into another store this grid can read.

This has the advantage of easily and atuomatically migrating changes across your interface. When you go to save the data it is really easy because your data models are the same.

jclawson
23 May 2008, 7:52 AM
I addressed this issue in my application by creating an Ext.data.ObjectStore:
http://extjs.com/forum/showthread.php?t=35406

This isn't exactly what I am talking about. It looks like your code kindof does what my LinkAdapter does. That is, map a userId to a userName. What I did the other day was have a grid that displays parent and child relationships from nodes in a graph in a grouping grid grouped on the relation type (parent or child)... this is the example in my blog post.

Essentially how I accomplished this is that I have a StoreSynchronizer that syncs the node relationship store with a new store I created. It only syncs those records where the particular parentId or childId equals the open node(sound familiar... this is the where clause). In addition I populate the relationType field with "parent" or "child" (used for grouping). Then I have 2 LinkAdapters that link up parentId to nodeName and childId to nodeName.

The StoreSynchronizer and LinkAdapters migrate changes from all the stores bidirectionally. When I want to save the changes I only have to save the source stores that mimic my server data model. I don't care about the intermediate store as it doesn't represent my server side data model.

Does this make sense?

JEBriggs
23 May 2008, 8:00 AM
Interesting. I'll take a closer look and read your blog when I have a chance.

MarcWeil
23 May 2008, 8:48 AM
I think you misunderstand... This isn't server side SQL. This sql NEVER goes to the server. That would, of course, be really stupid. This is only for constructing an Ext.data.Store from existing Ext.data.Stores so that you can more easily mirror the client data model off of your server data model. If you read my blog post I think it will make a little more sense. I often need to create grids that show data from a combination of different stores. Why should I create another data provider for this grid's store? I would rather utilize the data providers I already have and just intelligently join together data from my existing stores into another store this grid can read.

This has the advantage of easily and atuomatically migrating changes across your interface. When you go to save the data it is really easy because your data models are the same.
Oh wow you're right, I did totally misunderstand. So the objects referred to in the SQL string would actually map to Javascript objects? That sounds REALLY cool!!! I'm very interested in seeing where this goes.

jclawson
23 May 2008, 9:11 AM
Oh wow you're right, I did totally misunderstand. So the objects referred to in the SQL string would actually map to Javascript objects? That sounds REALLY cool!!! I'm very interested in seeing where this goes.

Yes! Exactly!! :D It is a pretty complicated problem especially when you get into the situation where you have cartesian products. I will do some thinking on it... not sure if I am ready to actually commit to developing this :-?