3.1 Roadmap question/feedback

[qooleot]

I have a question about the following two features scheduled for 3.1:




Grid View with Column Locking Example
Column Header Grouping


Those would be really really useful to have, but I would want to use it in cases where I'd make use of both (or I'll just have to pick one and not mention the other exists since the suits will just demand using both features). So my question is if that's going to be possible, and is it based on Condor's code:

http://www.extjs.com/forum/showthread.php?p=374714
http://www.extjs.com/forum/showthread.php?t=76322

and my concern/question arises from:

http://www.extjs.com/forum/showthread.php?p=374714#post374714

[abe.elias]

Yes, you will be able to combine both Group Column headers and Column Locking. As an aside, we currently do not have plans to support "Row Headers" with Column Locking, since the Row Header will be using the Column Locking internally.

We are currently putting the final touches on this functionality internally before committing it to SVN.

We've also recently updated our road map: http://www.extjs.com/products/extjs/roadmap.php to provide some more guidance on the product.

[mankz]

@abe: "Relational Functionality on Stores", this made me curious. Care to elaborate? :)

[abe.elias]

Sure, think about having the ability to bind fields in records to other stores, or fields themselves acting like stores. We are still debating the exact architecture internally, but that should give you an idea on where we are heading with this feature.

[Zyclops]

Sure, think about having the ability to bind fields in records to other stores, or fields themselves acting stores. We are still debating the exact architecture internally, but that should give you an idea on where we are heading with this feature.

One direction I would really like to see ExtJS head in, is the ability to essentially have an ORM layer within javascript.

Stores provide for some of this functionality but don't yet have the concepts of relationships. There are several of functionality I can imagine as a developer i'd want:

In the example Car has many CarParts (many to many).

Store: Car
id
name

Store: CarCarParts (join table)
id
car_id
car_part_id

Store: CarPart
id
name


1. The ability to make changes to the Car and it's CarParts even if they are stored in two separate stores
2. Being able to get a list of Car Parts for particular Car
3. Being able to create the equivalent of a database "view" by creating a view of multiple stores. e.g. you might just want to show Car Name, Car Part Name in a grid.

This functionality in addition to be able to synchronise stores with the server (and resolve conflicts etc) will make ExtJS a very powerful framework.

Will the relationships address any of these issues?

[abe.elias]

@Zyclops

Having a client-side ORM in javascript is a feature we'd like to avoid or look to wrap more powerful/appropriate client-side DB implementations (sqllite/air/gears/HTML5 offline support). Even with these client-side solutions, we can agree that some requirements are better suited for server-side computations - large data sets, indexing, etc.

That said, Ext Stores are getting more powerful. In 2.0, stores were equivalent to a DB "view" on the client side. Now with 3.0 and the introduction of writer support that line is blurred slightly. Look for additional transactional support for stores in an upcoming release to enhance stores even more.

[Zyclops]

More Detailed Example:


Car
id
name
manufacturer_id

CarCarParts
id
car_id
car_part_id

CarPart
id
name

Manufacturer
manufacturer_id


Use cases:

1. Edit Cars and add/edit/delete their car parts form the one form


addRecord(
name: 'Toyota',
car_parts: [
{name: 'Bla'}
]
)

2. Edit / Edit / Delete Manufacturers
3. Get a list of all the cars for a particular manufacturer
e.g.


Ext.each(manufactuter_record.cars, function(car) { console.log(car.name); }

4. Display a grid that has Manufacturer Name, Car Name (in the same grid, i.e. cartesian product)
So this maybe using the idea of the view you mentioned earlier
5. Ability to delete a manufacturer and all it's associated cars

ExtJS is very store centric (which makes a lot of sense in the way we use it at the moment), I imagine a store as being similar to having a relational db table.

> Having a client-side ORM in javascript is a feature we'd like to avoid or look to wrap more powerful/appropriate client-side DB
>implementations (sqllite/air/gears/HTML5 offline support)
The wrapping of the offline support is really important to making complex client side apps, i.e. we don't expect extjs to do sql style queries, but the having helper methods that can connect stores, update through stores etc is very similar to having an ORM layer anyway (even if it's mapping to an in memory store rather than an sql database etc).

The ability to have definable relationships between records (models) would really help in creating these apps, but it would need to cover the following to be a comprehensive solution:
a) crud of records and their nested relationships
b) the ability to create "views" of data and
c) a whole bunch of ways of navigating and searching between records
d) ways of using the (sqlite/air/gears/html 5 offline support) to populate the stores.

We've got a whole bunch of us here that are fascinated by the upcoming store stuff so keep us posted :)