Originally I was looking for practical use of ASP.NET Routing functionality in .NET 3.5 SP1, and ended up to think that Dynamic Data uses it. For routing part, it looks almost simple, so I sort of decided to hack it.
During generating masterinfos, I quickly noticed that DynamicData depends on LinqDataSource control, which we don't have yet. Fortunately, LinqDataSource seemed a good candidate for dogfooding Linq to SQL effort that we are trying to implement with DBLinq project (as written in my previous post). So I started to hack it.
And now here is a screenshot of working example of our LinqDataSource :)
It is from very simple use of GridView and LinqDataSource, which
depends on SQL Server database that Pablo's sample creates (see my
previous post for the details).
LinqDataSource-test.zip
It's working here, but it is possible only with my private branch of System.Data.Linq. Also I had to hack DataContext .ctor(string, MappingSource) which is not implemented in DBLinq (there is a discussion on how to implement connectionString support - see this thread in the DBLinq mailing list archive). The change is: : http://monoport.com/37676
This time it is a sshot from Windows as I am running this sample to connect to local SQL Server, but it is not difficult to get it working with other DB engines. For example, SQLite version of the sample would work if you 1) remove "dbo." from every table attribute in the sample code DataClasses1.designer.cs, 2) change connection string for SQLite DB, and 3) change my hack to instantiate SqliteConnection (must be done through reflection; we don't reference Mono.Data.Sqlite types from System.Data.Linq).
Anyways. The whole effort (DBLinq, DBLinq integration and LinqDataSource) is in early stage. We need more code. Especially LinqDataSource is nothing but hack yet ;)
During generating masterinfos, I quickly noticed that DynamicData depends on LinqDataSource control, which we don't have yet. Fortunately, LinqDataSource seemed a good candidate for dogfooding Linq to SQL effort that we are trying to implement with DBLinq project (as written in my previous post). So I started to hack it.
And now here is a screenshot of working example of our LinqDataSource :)
It is from very simple use of GridView and LinqDataSource, which
depends on SQL Server database that Pablo's sample creates (see my
previous post for the details).LinqDataSource-test.zip
It's working here, but it is possible only with my private branch of System.Data.Linq. Also I had to hack DataContext .ctor(string, MappingSource) which is not implemented in DBLinq (there is a discussion on how to implement connectionString support - see this thread in the DBLinq mailing list archive). The change is: : http://monoport.com/37676
This time it is a sshot from Windows as I am running this sample to connect to local SQL Server, but it is not difficult to get it working with other DB engines. For example, SQLite version of the sample would work if you 1) remove "dbo." from every table attribute in the sample code DataClasses1.designer.cs, 2) change connection string for SQLite DB, and 3) change my hack to instantiate SqliteConnection (must be done through reflection; we don't reference Mono.Data.Sqlite types from System.Data.Linq).
Anyways. The whole effort (DBLinq, DBLinq integration and LinqDataSource) is in early stage. We need more code. Especially LinqDataSource is nothing but hack yet ;)
Leave a comment