Is there a document anywhere that explains in detail exactly what services are expected from a component used as a DataSource? The question arises because there are always issues in working with DataSets, IEnumerable<T> collections don't provide enough info, and I'm not sure what might be required of DataTables/DataViews. Some data sources are simply better than others, so we're considering creating a new ObjectDataSource, maybe deriving from the powerful ExtendedDataSource from Manuel Abadia. The goal is to get the best design-time experience possible by giving the RadControls designer components everything they can use.
The following questions are mostly variations on the same concept. Feel free to post one response to combine some concepts:
- What happens when we we request a schema refresh of a data source, whether DataSet, DataTable, DataView, SqlDataSource, ObjectDataSource, etc.?
- When a GridTableView, master or detail, make a request for schema to a data source, what information is sent to the source? For example, is there a "SchemaOnly" flag to differentiate the request from a data request?
- Is a request made of the data source for a row set of zero rows, just to get the schema?
- Certain values are required to make the best use of the designers, like field name and data type. What else is required? With an object data source we can't always bind the data source itself to fields, like a SqlDataSource for example. I'm wondering exactly what it is that the RadGrid would extract from a SqlDataSource that we need to provide elsewhere?
Of course declarative definition of control details is preferred because it's easy, but rather than trying to get the designer to be so friendly, do more advanced developers switch to defining GridTableViews and other components in Page_Load, NeedDataSource, etc?
Rather than relying on a single data source at design-time, I know we can change the datasource at run-time in the DetailTableDataBind event. And since we can't "mix" column definitions defined at run-time with those defined at design-time, we really need to do this one way or the other. Are there any comments about "one you get away from declarative code you'll never go back", or "once you've tried doing this manually you'll want to stick with declarative"?
I'm just looking for the best approach to Rapid Application Development (Rad tools, right? ;) ), and I don't care if it means beefing up design-time components, or going in the other direction and using the designer purely for look and feel and leaving all schema/data access to code.
Thanks for your time!
The following questions are mostly variations on the same concept. Feel free to post one response to combine some concepts:
- What happens when we we request a schema refresh of a data source, whether DataSet, DataTable, DataView, SqlDataSource, ObjectDataSource, etc.?
- When a GridTableView, master or detail, make a request for schema to a data source, what information is sent to the source? For example, is there a "SchemaOnly" flag to differentiate the request from a data request?
- Is a request made of the data source for a row set of zero rows, just to get the schema?
- Certain values are required to make the best use of the designers, like field name and data type. What else is required? With an object data source we can't always bind the data source itself to fields, like a SqlDataSource for example. I'm wondering exactly what it is that the RadGrid would extract from a SqlDataSource that we need to provide elsewhere?
Of course declarative definition of control details is preferred because it's easy, but rather than trying to get the designer to be so friendly, do more advanced developers switch to defining GridTableViews and other components in Page_Load, NeedDataSource, etc?
Rather than relying on a single data source at design-time, I know we can change the datasource at run-time in the DetailTableDataBind event. And since we can't "mix" column definitions defined at run-time with those defined at design-time, we really need to do this one way or the other. Are there any comments about "one you get away from declarative code you'll never go back", or "once you've tried doing this manually you'll want to stick with declarative"?
I'm just looking for the best approach to Rapid Application Development (Rad tools, right? ;) ), and I don't care if it means beefing up design-time components, or going in the other direction and using the designer purely for look and feel and leaving all schema/data access to code.
Thanks for your time!
1 Answer, 1 is accepted
0
Hi Tony,
RadGrid, as in fact MS's GridView, communicate with DataSource controls by using the DataSourceView class instance which the DataSource control supplies. In this way a grid control is decoupled from the data source to which is bound and does not depend on a specific implementation of the data source.
RadGrid does not make any "SchemaOnly" calls but rather the data schema is retrieved from the supplied data.
I suggest you review the .NET framework's source code and documentation about implementation details of DataSource controls.
Best regards,
Rosen
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
RadGrid, as in fact MS's GridView, communicate with DataSource controls by using the DataSourceView class instance which the DataSource control supplies. In this way a grid control is decoupled from the data source to which is bound and does not depend on a specific implementation of the data source.
RadGrid does not make any "SchemaOnly" calls but rather the data schema is retrieved from the supplied data.
I suggest you review the .NET framework's source code and documentation about implementation details of DataSource controls.
Best regards,
Rosen
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.