Does anyone like what Microsoft has done to databinding?

[John Bailey]

When I first built a few web pages in ASP .Net 2.0, I thought it was great.
The formview and detailview contorls would automatically layout the controls
for you, the update methods were automatically generated, and the
objectdatasource let you design against a business object through the gui.

Now I am working on my first real web application on 2.0, and I find this
automatic functionality doesn't do much beyond allowing me to generate pages
to update my reference data. And since none of the previous databinding
methodology was left intact, I am having to spend twice as much time working
around the built in code as I previously spent working with the 1.1
databinding.

You now have to bind most controls inside of a formview or details view.
You can't access the underlying object in the objectdatasource (although you
can override the construction of this object), so it is difficult to
interject any specific formating into your interface (like databinding to a
date that might be null, you could previously bind to a method or check the
null method in your binding). These problems can be worked around through
business objects, but this forces you to do formating in these classes
instead of in the interface.

The update methodology seems like a good idea in the formview until you have
a requirement to update multiple tables in a dataset through the same method.
You can only bind the formview to one datamember, and the formviews will
each try to call their update methods separately. The only workaround I have
found is to retrieve the control values yourself (through the findcontrol
method since you no longer have direct access to these from your class) and
to call the update method yourself. This is how I might have done it in 1.1,
but since I have to use the findcontrol method to retrieve the values you no
longer get the benefits of intellisence when writing this code.

It seems like in the pursuit of "creating web sites without code" Microsoft
has removed the abiltiy to actually put code into your web sites.

Has anyone else been running into these or similar issues?

[John Bailey]

Okay, I just figured out how to access the data object, and you have to do it
through the formview or detailview instead of through the objectdatasource.
"John Bailey" wrote:

When I first built a few web pages in ASP .Net 2.0, I thought it was great.
The formview and detailview contorls would automatically layout the controls
for you, the update methods were automatically generated, and the
objectdatasource let you design against a business object through the gui.

Now I am working on my first real web application on 2.0, and I find this
automatic functionality doesn't do much beyond allowing me to generate pages
to update my reference data. And since none of the previous databinding
methodology was left intact, I am having to spend twice as much time working
around the built in code as I previously spent working with the 1.1
databinding.

You now have to bind most controls inside of a formview or details view.
You can't access the underlying object in the objectdatasource (although you
can override the construction of this object), so it is difficult to
interject any specific formating into your interface (like databinding to a
date that might be null, you could previously bind to a method or check the
null method in your binding). These problems can be worked around through
business objects, but this forces you to do formating in these classes
instead of in the interface.

The update methodology seems like a good idea in the formview until you have
a requirement to update multiple tables in a dataset through the same method.
You can only bind the formview to one datamember, and the formviews will
each try to call their update methods separately. The only workaround I have
found is to retrieve the control values yourself (through the findcontrol
method since you no longer have direct access to these from your class) and
to call the update method yourself. This is how I might have done it in 1.1,
but since I have to use the findcontrol method to retrieve the values you no
longer get the benefits of intellisence when writing this code.

It seems like in the pursuit of "creating web sites without code" Microsoft
has removed the abiltiy to actually put code into your web sites.

Has anyone else been running into these or similar issues?

[Mike Salway]

John I agree, it's not very well thought out and doesn't really work very
well with Typed Datasets, which you might imagine would be a rather common
use of the ObjectDatasource. Anyway,can you tell me how you get to the data
object from a detailview?
"John Bailey" wrote:

Okay, I just figured out how to access the data object, and you have to do it
through the formview or detailview instead of through the objectdatasource.
"John Bailey" wrote:

When I first built a few web pages in ASP .Net 2.0, I thought it was great.
The formview and detailview contorls would automatically layout the controls
for you, the update methods were automatically generated, and the
objectdatasource let you design against a business object through the gui.

Now I am working on my first real web application on 2.0, and I find this
automatic functionality doesn't do much beyond allowing me to generate pages
to update my reference data. And since none of the previous databinding
methodology was left intact, I am having to spend twice as much time working
around the built in code as I previously spent working with the 1.1
databinding.

You now have to bind most controls inside of a formview or details view.
You can't access the underlying object in the objectdatasource (although you
can override the construction of this object), so it is difficult to
interject any specific formating into your interface (like databinding to a
date that might be null, you could previously bind to a method or check the
null method in your binding). These problems can be worked around through
business objects, but this forces you to do formating in these classes
instead of in the interface.

The update methodology seems like a good idea in the formview until you have
a requirement to update multiple tables in a dataset through the same method.
You can only bind the formview to one datamember, and the formviews will
each try to call their update methods separately. The only workaround I have
found is to retrieve the control values yourself (through the findcontrol
method since you no longer have direct access to these from your class) and
to call the update method yourself. This is how I might have done it in 1.1,
but since I have to use the findcontrol method to retrieve the values you no
longer get the benefits of intellisence when writing this code.

It seems like in the pursuit of "creating web sites without code" Microsoft
has removed the abiltiy to actually put code into your web sites.

Has anyone else been running into these or similar issues?

[John Bailey]

It seems almost too obvious, but in the Databind method, the DataItem
property of either the FormView or DetailView can be cast to the correct
underlying type. At any time during the databinding, you can cast this (such
as if when you are using a custom function in your databinding).

This method of getting at the data doesn't seem overly well documented.

"Mike Salway" wrote:

John I agree, it's not very well thought out and doesn't really work very
well with Typed Datasets, which you might imagine would be a rather common
use of the ObjectDatasource. Anyway,can you tell me how you get to the data
object from a detailview?
"John Bailey" wrote:

Okay, I just figured out how to access the data object, and you have to do it
through the formview or detailview instead of through the objectdatasource.
"John Bailey" wrote:

When I first built a few web pages in ASP .Net 2.0, I thought it was great.
The formview and detailview contorls would automatically layout the controls
for you, the update methods were automatically generated, and the
objectdatasource let you design against a business object through the gui.

Now I am working on my first real web application on 2.0, and I find this
automatic functionality doesn't do much beyond allowing me to generate pages
to update my reference data. And since none of the previous databinding
methodology was left intact, I am having to spend twice as much time working
around the built in code as I previously spent working with the 1.1
databinding.

You now have to bind most controls inside of a formview or details view.
You can't access the underlying object in the objectdatasource (although you
can override the construction of this object), so it is difficult to
interject any specific formating into your interface (like databinding to a
date that might be null, you could previously bind to a method or check the
null method in your binding). These problems can be worked around through
business objects, but this forces you to do formating in these classes
instead of in the interface.

The update methodology seems like a good idea in the formview until you have
a requirement to update multiple tables in a dataset through the same method.
You can only bind the formview to one datamember, and the formviews will
each try to call their update methods separately. The only workaround I have
found is to retrieve the control values yourself (through the findcontrol
method since you no longer have direct access to these from your class) and
to call the update method yourself. This is how I might have done it in 1.1,
but since I have to use the findcontrol method to retrieve the values you no
longer get the benefits of intellisence when writing this code.

It seems like in the pursuit of "creating web sites without code" Microsoft
has removed the abiltiy to actually put code into your web sites.

Has anyone else been running into these or similar issues?