I apologize as I know this topic has been discussed in previous threads, pretty much all of which I have read today

But I wasnt able to tell what the final resolution was to this. Will the Entity and EntityCollection classes work with ObjectDataSource or do I need to write a wrapper class around them to get it to work. I am running LLBLGen Pro v1.0.2005.1 Final (Oct 27th). Any sample code you can post would be appreciated.

Also, if the entity & entity collection classes arent bindable to ObjectDataSource is there a next beta release of LLBLGen where it does work that I can try out instead.

Please let me know as I am working on a project where I dont have a lot of time to experiment as I am already running behind.

Thanks.

For now, you have to write a wrapper class. This doesn't have to be a bad thing, the new asp.net setup for databinding is that the site developer writes the binding code as every scenario is different.

ObjectDataSource has one big disadvantage: it creates a new object on postback and saves the changed data in that object. This is bad if you use changetracking, like LLBLGen Pro does. v2.0 of llblgen pro will have an LLBLGenProDataSource but till then, you've roll your own I'm afraid.

Thanks again for the prompt response. Couple questions:

1. What is the timeline for the beta release of LLBLGen Pro v2.0?

2. Will LLBLGenProDataSource be modelled after the ObjectDataSource?

3. Will the LLBLGenProDataSource utilize any caching and also handle concurrency issues resulting from multiple users updating same rows?

4. When you say

This doesn't have to be a bad thing, the new asp.net setup for databinding is that the site developer writes the binding code as every scenario is different.

Would the new LLBLGenProDataSource control not support declarative data-binding?

Hi,

I'm also trying to do the same thing. I can get close but not quite.

Goal: To read, update and delete using the GridView.

I created a simple wrapper class like so:

Imports OW.MainData.EntityClasses

Namespace OW.GVWrappers
      Public Class GridViewWrappers
          Public Class Client
                   Public Function GetClient(ByVal ClientID As Int16) As ClientsEntity
               Return New ClientsEntity(ClientID)
            End Function

            Public Sub InsertOrUpdateClient(ByVal client As ClientsEntity)
                client.Save()
            End Sub

            Public Sub DeleteClient(ByVal client As ClientsEntity)
                client.Delete()
            End Sub
        End Class
    End Class
End Namespace

And my GridView and ObjectDataSource like so:

    <asp:GridView ID="ClientGridView" runat="server" AutoGenerateColumns="False" DataKeyNames="ClientId"
        DataSourceID="ClientObjectDataSource">
        <Columns>
            <asp:CommandField ShowEditButton="True" />
            <asp:BoundField DataField="Company" HeaderText="Company" SortExpression="Company" />
            <asp:BoundField DataField="City" HeaderText="City" SortExpression="City" />
        </Columns>
    </asp:GridView>
    <asp:ObjectDataSource ID="ClientObjectDataSource" runat="server" DataObjectTypeName="OW.MainData.EntityClasses.ClientsEntity"
        SelectMethod="GetClient" TypeName="OW.GVWrappers.GridViewWrappers+Client" UpdateMethod="InsertOrUpdateClient">
        <SelectParameters>
            <asp:Parameter DefaultValue="2210" Name="ClientID" Type="Int16" />
        </SelectParameters>
    </asp:ObjectDataSource>

This reads the data without any issue, but the update always fails with: "The field 'ClientId' is read-only and can't be changed." I've tried with a couple different entities different ways but haven't been successful in getting it to work.

The interesting thing is that I can put in an invalid method name for the UpdateMethod and it still fails with the same error. So it's not getting as far as the wrapper class. It appears that somehow the object is attempting to update earlier than expected. Further up on this post the same thing was mentioned. How do I get around this?

Or, if I can't get around this, what direction should I head to be able to use a gridview or datagrid today. (v2.0 sounds exciting but I need to move forward with this now).

Many thanks in advance,

Scott

Be sure you store the object bound the first time somewhere (session, viewstate) so you can UPDATE the non-PK fields with new data and then save the entity.

Otis,

I have to admit that I don't fully grasp the concept. I understand session and viewstate of course, but not how I'm supposed to create the wrapper class.

I created a new instance of the ClientEntity and set it in a session variable, then I returned the session variable. But I'm sure I'm heading down a completely wrong direction. I don't have an opportunity to even use my Update method of the wrapper class because the exception is thrown before it even gets that far. The issue is that the ObjectDataSource appears to be trying to update the Entity before the wrapper function is even called.

In the gridview RowUpdating I'm able to do things before the exception is thrown but I doubt that is the direction I should head.

I'll include the full exception stack trace below.

Sorry for asking for so much, but if there a FAQ somewhere or could you give me a bit more for a code example for me to run with please?

Thanks,

Scott

[ORMFieldIsReadonlyException: The field 'ClientId' is read-only and can't be changed.] System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object component, Object value) +324 System.Web.UI.WebControls.ObjectDataSourceView.BuildDataObject(Type dataObjectType, IDictionary inputParameters) +223 System.Web.UI.WebControls.ObjectDataSourceView.ExecuteUpdate(IDictionary keys, IDictionary values, IDictionary oldValues) +1147 System.Web.UI.DataSourceView.Update(IDictionary keys, IDictionary values, IDictionary oldValues, DataSourceViewOperationCallback callback) +78 System.Web.UI.WebControls.GridView.HandleUpdate(GridViewRow row, Int32 rowIndex, Boolean causesValidation) +1228 System.Web.UI.WebControls.GridView.HandleEvent(EventArgs e, Boolean causesValidation, String validationGroup) +853 System.Web.UI.WebControls.GridView.OnBubbleEvent(Object source, EventArgs e) +88 System.Web.UI.Control.RaiseBubbleEvent(Object source, EventArgs args) +35 System.Web.UI.WebControls.GridViewRow.OnBubbleEvent(Object source, EventArgs e) +117 System.Web.UI.Control.RaiseBubbleEvent(Object source, EventArgs args) +35 System.Web.UI.WebControls.LinkButton.OnCommand(CommandEventArgs e) +86 System.Web.UI.WebControls.LinkButton.RaisePostBackEvent(String eventArgument) +155 System.Web.UI.WebControls.LinkButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +7 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +11 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +172 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +4921

I think the exception is thrown by the fact the objectdatasource tries to set the identity field (PK), is that correct (is that field the PK and an identity field?)

The think you experience is the main gripe with Objectdatasource and the reason why all O/R mapper vendors and other data access solution providers have to write their own datasource object. I can't help you further with teh objectdatasource, I will give you 5 links to a tutorial how to write your own datasource object, which doesn't take a lot of effort, but which could help you in the meantime till LLBLGenProDataSource is ready: (written by one of the ASP.NET team members)

http://www.nikhilk.net/DataSourceControlBasics.aspx http://www.nikhilk.net/DataSourceControlParameters.aspx http://www.nikhilk.net/DataSourceControlsAsync.aspx http://www.nikhilk.net/DataSourceControlsCache.aspx http://www.nikhilk.net/DataSourceControlsDesignTime.aspx

Thank you! Yes, the ClientId is the primary field. The info you gave was what I needed to get a working solution.

Thanks again!

Scott

Otis wrote:

I think the exception is thrown by the fact the objectdatasource tries to set the identity field (PK), is that correct (is that field the PK and an identity field?)

The think you experience is the main gripe with Objectdatasource and the reason why all O/R mapper vendors and other data access solution providers have to write their own datasource object. I can't help you further with teh objectdatasource, I will give you 5 links to a tutorial how to write your own datasource object, which doesn't take a lot of effort, but which could help you in the meantime till LLBLGenProDataSource is ready: (written by one of the ASP.NET team members)

I'm bumping into this as well. ObjectDataSource doesn't behave as I would have expected it to behave, and the workarounds seem rather painful. I think I'm going to just deal with my view/edit/update/delete stuff in the interface in a more manual way and wait for 2.0. Am I correct in that 2.0 with an LLBLgen-compatible ObjectDataSource will be available in March?

Otis, I think it would be a good idea to deal with ASP.NET issues in a more structured way, both in the documentation and the forums. I would suggest that a separate ASP.NET forum area would be helpful to folks who are looking for guidance in this area, and the documentation needs to identify the key issues and stumbling blocks that folks using ASP.NET with LLBLgen are going to run into.

briansp wrote:

Otis wrote:

I think the exception is thrown by the fact the objectdatasource tries to set the identity field (PK), is that correct (is that field the PK and an identity field?)

The think you experience is the main gripe with Objectdatasource and the reason why all O/R mapper vendors and other data access solution providers have to write their own datasource object. I can't help you further with teh objectdatasource, I will give you 5 links to a tutorial how to write your own datasource object, which doesn't take a lot of effort, but which could help you in the meantime till LLBLGenProDataSource is ready: (written by one of the ASP.NET team members)

I'm bumping into this as well. ObjectDataSource doesn't behave as I would have expected it to behave, and the workarounds seem rather painful. I think I'm going to just deal with my view/edit/update/delete stuff in the interface in a more manual way and wait for 2.0. Am I correct in that 2.0 with an LLBLgen-compatible ObjectDataSource will be available in March?

it will at least be april as the deadline we have is 31 march (and perhaps a little later even).

V2 will have 2 controls: LLBLGenProDataSource for selfservicing and LLBLGenProDataSource2 for adapter. These controls come with a designer where you can select: entity collection, typedlist or typed view and the appropriate information like which type and for adapter, which adapter etc.

You can then also select serverside paging yes/no, max number of items to return, if you want duplicates to show up or not, and you can specify in code a filter and/or sorter. Also can you specify where to store the data: viewstate or session. I also wanted to add a cache option, but I couldn't get it to work, and looking into the shipped controls with .NET, they all use internal classes for cache management (Way to go, MS! really lovely to not open up these kind of classes), so I dropped that for now.

I've spend 7 days now fighting with DataSourceControl and it finally works in code, the designer still bugs, so I have to find a way to fix that. The docs on this are simply not there, so everything is done through reverse engineering, trial/error etc, you know the usual road of frustration when it comes to databinding with ms stuff.

I haven't done any postback update/delete stuff yet, as the designer has to work first. Also the weird way of how data is formatted when it comes back to the control when an update/delete has to be executed can be a showstopper for 2-way databinding, but I'll see how that evolves.

EITHER way, .NET 1.x databinding simply still works: you can bind an entity collection to a grid without a problem.

Otis, I think it would be a good idea to deal with ASP.NET issues in a more structured way, both in the documentation and the forums. I would suggest that a separate ASP.NET forum area would be helpful to folks who are looking for guidance in this area, and the documentation needs to identify the key issues and stumbling blocks that folks using ASP.NET with LLBLgen are going to run into.

LLBLGen Pro related problems can be posted in the usual forums, I don't think we need a separate ASP.NET forum, as this forum isn't meant for asp.net related problems but for llblgen pro related problems, and you can have problems with winforms, remoting, webservices, windows services etc. as well, and I don't think we need separate forums for those subjcets as well. The main thing is that the more forums you get, teh more confused people will be where to post what.

I have to say that design time databinding support is 'nice' but it's not something which is a core aspect of a data-access oriented framework. I do understand that supporting design time databinding can help a lot, and that's also why I go through this frustrating task to add it to the framework, but I can only do as much as what's possible and logical for the framework. I mean: a true design time application designer would be great too, but in the end you can't avoid programming. Like setting up the datasourcecontrol can be done in a designer, but it's absurd to specify a filter there too because it would make the filter end up in the layout formatting (HTML), and IN TEXT, which is 1) not compile time checked and 2) not maintainable because it's not in the place where you would expect it. So it would make you write code anyway.

I hope to have some working designer today so I can finalize it tomorrow and move on, as it otherwise begins to become a true nightmare.

Otis wrote:

it will at least be april as the deadline we have is 31 march (and perhaps a little later even).

V2 will have 2 controls: LLBLGenProDataSource for selfservicing and LLBLGenProDataSource2 for adapter. These controls come with a designer where you can select: entity collection, typedlist or typed view and the appropriate information like which type and for adapter, which adapter etc.

I would be very happy to "preview" this if it is stable/featured enough to be useful. I don't care about design-time stuff.

Otis wrote:

LLBLGen Pro related problems can be posted in the usual forums, I don't think we need a separate ASP.NET forum, as this forum isn't meant for asp.net related problems but for llblgen pro related problems, and you can have problems with winforms, remoting, webservices, windows services etc. as well, and I don't think we need separate forums for those subjcets as well. The main thing is that the more forums you get, teh more confused people will be where to post what.

Fair enough. It would be useful to have at least in the docs some gentle reminders about state management and some suggestions on how to deal with common issues. I'm sure there are enough folks here using ASP.NET that we could contribute this.

Otis wrote:

I hope to have some working designer today so I can finalize it tomorrow and move on, as it otherwise begins to become a true nightmare.

Thanks for being so responsive.

V2 will have 2 controls: LLBLGenProDataSource for selfservicing and LLBLGenProDataSource2 for adapter. These controls come with a designer where you can select: entity collection, typedlist or typed view and the appropriate information like which type and for adapter, which adapter etc.

You can then also select serverside paging yes/no, max number of items to return, if you want duplicates to show up or not, and you can specify in code a filter and/or sorter. Also can you specify where to store the data: viewstate or session.

Say, how about teasing us with a screenshot of this?

I, for one, know I would appreciate a little more creativity in the naming of the classes.

I can't determine the difference between LLBLGenProDataSource and LLBLGenProDataSource2 simply by looking at them.

Is 2 a later version, a second class citizen or what

Maybe LLBLGenProDataSourceSelf and LLBLGenProDataSourceAdapter.

With autocompletion, I don't mind long class names. Heck, for that matter Adapter would sort first!

Hopefully this feedback is early enough to be considered.

JimHugh wrote:

I, for one, know I would appreciate a little more creativity in the naming of the classes.

I can't determine the difference between LLBLGenProDataSource and LLBLGenProDataSource2 simply by looking at them.

Is 2 a later version, a second class citizen or what

Maybe LLBLGenProDataSourceSelf and LLBLGenProDataSourceAdapter.

With autocompletion, I don't mind long class names. Heck, for that matter Adapter would sort first!

Hopefully this feedback is early enough to be considered.

First there was selfservicing, though the classes weren't suffixed with 'Self' or something. Then after 2 releases, adapter was added. A problem arised, because naming the new classes specific for adapter with a suffix of 'Adapter' would be weird. So '2' was added. Also weird, but less 'locked' into the paradigm.

I keep that naming scheme everywhere. If there are 2 variants, the one with the 2 is for adapter. If there's just 1, the class is shared among both template groups. So that's also why I keep the '2' suffix for the datasources.

When the 2 are in the toolbox, you have the two enlisted and the description of the names says which is for selfservicing and which is for adapter.

I know, would 'adapter' have been designed into the code right from the start, things would have been different of course. But then the code base architecture would have been different as well. That's the downside of agile development: the things you add after you released a version will have such a high impact (likely) on the existing code base you will need a lot of refactoring and even then: you can't break existing apps.

It's way easier to simply drag/n/drop the datasource on the webform than to type it out by hand. What I wanted, and what failed was to get a name in the toolbox like 'LLBLGenProDataSource for Adapter'... This apparently isn't that easy. The HTML controls have a space in their description, but nowhere could I find any hint how to achieve that.