ASP.NET V2.0 Formview - what am I missing?

DublinWriter

I've begun to look at doing some smallish projects in ASP.NET V2.0 with VB.net code-behinds.

The one thing that struck me as being a headache is the need for separate edit, insert and view templates in the formview component.

Forgive me if I sound a little stupid, but traditionally when I've designed a form in any of the previous languages/IDE's I've worked with, I only design the one template; field-controls would have had their editable property set by the state of their respective dataset.

It seems like complete lunacy that I have to design the same form three times using a formview control, or am I missing something?

Evil Phil

I hazard a guess and say its to do with Http being Stateless and the HTML controls that are rendered on the client not being flexible enough to have an the kind of editable properties you're mentioned. Asp.net Server controls are rendered as standard HTML controls on the client. You're item/insert/edit templates tell Asp.net what controls to render with your data for the current user behaviour. Generally I put these things together in the mark up myself though as using the IDE to do it is very clunky.

I would say however that I've found the templates to be very powerful. For standard edit/insert/view it might seem like overkill but if you want to do something *funky* then they really come into their own.

Just as a matter of interst what IDE's have you used traditionaly (besides Delphi ) and what kind of development were you doing?

mewso

I'm not sure why you are using a form view though. A form view is specifically designed for templated output wheras a details view for example can work without any templates and will deride the insert/update stuff itself. You can still create template fields but only for the fields you need to change a bit.

The form view is there if you want complete control rather than using the gridview/detailsview combo.

DublinWriter

musician wrote: »

The form view is there if you want complete control rather than using the gridview/detailsview combo.

That's hellish to make someone doing data-entry all day long input via a gridview when there are over 40 fields to edit/input.

DublinWriter

Evil Phil wrote: »

You're item/insert/edit templates tell Asp.net what controls to render with your data for the current user behaviour. Generally I put these things together in the mark up myself though as using the IDE to do it is very clunky.

Yes, I find more experienced ASP.NET V2 programmers cutting to the chase and designing forms directly in HTML.

Evil Phil wrote: »

I would say however that I've found the templates to be very powerful. For standard edit/insert/view it might seem like overkill but if you want to do something *funky* then they really come into their own.

I don't want to do anything *funky*, I want to write a boring old transactional system without having to design each form three times. The whole template approach certainly scuppers the use of VS as a RAD tool.

Evil Phil wrote: »

Just as a matter of interst what IDE's have you used traditionaly (besides Delphi ) and what kind of development were you doing?

Well with Delphi I use Intraweb. It's about as easy as easy can be. It's just like designing traditional Windows applications. The engine takes care of on the fly HTML rendering and Java script coding. Data aware controls are editable based on the state (browsing, editing, inserting) of the underlying dataset.

Apps compile down to a single .EXE that is also it's own self-contained web server. It will also work in conjuction with IIS and Apache if you want to use a 3rd party web server.

In fact, there was a version of Intraweb for VS 2002, but this was discontinued when ASP 2 came out. Big mistake I think.

I've also worked with PeopleSoft 8. It works in a similar way to the above, you define your forms using the PeopleTools IDE and the PeopleSoft app-engine/middleware generates all the necessary HTML code.

Although I've no direct experience with ColdFusion, I believe it worked in a similar fashion to all of the above.

I'm really surprised that in this day and age MS haven't jumped on the RAD train with VS 2005.

mewso

DublinWriter wrote: »

That's hellish to make someone doing data-entry all day long input via a gridview when there are over 40 fields to edit/input.

I would never make someone enter data in a gridview. Thats why I said Gridview/DetailsView combo. The details view is intended for data entry or is more appropriate anyway. I prefer in general to use a proper fieldset css form for data entry and I have been looking at creating a custom detailsview css friendly adapter to ouput a fieldset and label/input elements. My main point is the details view will automatically create isert/edit controls for you and you hand pick the fields you want to make template fields and customise. You can drop a detailsview on a page, create a datasource with update and insert statements and enable editing and inseting on on the details view and thats it.

These days I hardly use anything other than a repeater because it gives me complete control to ensure I am outputting standards compliant html. i.e. a table with a proper thead (which a gridview does not include although with the css friendly adapter it will) etc. I also hate inline javascript so I don't want to let asp.net do it. People seem to mistakenly think a formview gives you total control which it doesn't. It always wraps whatever you put into it in a table.

Evil Phil

What exactly are you trying to do? I would seem to me that if the formview is turning into a headache then maybe there's a better way. Have you consider scraping the databound approach?

BostonB

DublinWriter wrote: »

That's hellish to make someone doing data-entry all day long input via a gridview when there are over 40 fields to edit/input.

That seems like a lot of 40 fields to have on one form. For a usability POV I wouldn't be a fan of that. That said we've one form that must have almost 30 fields in it.

I only use a databound grid for list view for returning results of a search etc. But then when I go into a specific record to edit/view I put a dataset of the record into the session, and grab if from there, only binding some of the dropdown lists etc, which don't change for different users. Like I said I'm new to .Net and a bit of a hacker so don't really know what I'm doing. So this could the wrong approach. I don't use a form template (what is that?) I just design my own aspx form, and use it for edit, view, update, I just send in a parameter to say which "mode" the form should be in. So theres only one form. We also use XML forms but I'm not as fond of that.

DublinWriter

Evil Phil wrote: »

Have you consider scraping the databound approach?

And doing what exactly?

As for using the detailsview - forget it. It seems like a great little tool for drilling into grids on the fly, but I really can't see how anyone would use it to design a good looking data entry form.

I'm still quite astonished at how clunky is it to use formview to design data entry forms. Sure, it's great for knocking out forms for tables with up to half-a-dozen fields, but it seems like a complete pig to work with. It certainly isn't WYSIWUG or RAD.

stevenmu

The gridview can actually be customised to make some very useable forms, to the point that you wouldn't realise it's a gridview at all. I've seen some great examples out there, will try to find some.

But really I'm kind of wondering why you want to use any of the form controls. From what you've described, why not just drop your textboxes and other controls straight onto the page and enable/disable as needed?

DublinWriter

stevenmu wrote: »

But really I'm kind of wondering why you want to use any of the form controls. From what you've described, why not just drop your textboxes and other controls straight onto the page and enable/disable as needed?

How would I bind them to the datasource?

Evil Phil

stevenmu wrote: »

But really I'm kind of wondering why you want to use any of the form controls. From what you've described, why not just drop your textboxes and other controls straight onto the page and enable/disable as needed?

Which is what you can do instead of using a databound control, to answer your earlier question. As for binding your controls to the datasource: Surely it wouldn't take to long to write that yourself? Try overriding DataBind() on your page object. Or better still, write your own control.

Asp.net and Visual Studio might have limited drag-drop capabilities when designing your forms but that would be inkeeping with modern web development. Most design is achieved with HTML/CSS rather than draging and droping elements.

I'm wouldn't consider myself I fan boy of any particular technology by you're highly critical of VS/Asp.net development for somebody who seems to have very little experience of them.

BostonB

DublinWriter wrote: »

How would I bind them to the datasource?

I do something like this. Not sure if its correct. But it works for me.

Dim DsLookUp As DataSet = Application.Item("lookups")
Bibbletxt.DataSource = DsLookUp
Bibbletxt.DataMember = "PRODUCT"
Bibbletxt.DataTextField = "DESCRIPTION"
Bibbletxt.DataValueField = "ID"
Bibbletxt.DataBind()

DublinWriter

Evil Phil wrote: »

Try overriding DataBind() on your page object. Or better still, write your own control.
...
I'm wouldn't consider myself I fan boy of any particular technology by you're highly critical of VS/Asp.net development for somebody who seems to have very little experience of them.

I suppose coming from a Delphi/Intraweb platform I was being royally spoiled.

I could design web apps just like I was designing win32/winforms apps.

I'm getting more of an handle on ASP .NET V2.0, but it still seems quite kludgey and HTML-centric.

You're right about over-riding databind, etc. I'm starting to put in a lot of code-behind routines as the two-way data-binding in ASP .NET V2.0 gives you a lot of control over what comes down from the DB, but not what goes back up.

For example, Oracle doesn't have a boolean field-type. Most people implement booleans in Oracle as Char(1) and populate it with 'Y' or 'N'. The default ASP checkbox doesn't like that one bit (no pun intended) so I have to write helper functions called within the ASP directives and hook into the dataset's updating event to make sure correct values get written back.

With all the code-behinds I'm writing, I'll probably end up ditching the formview component completely.

Evil Phil

Personally outside of simple binding of tabular data I find the repeater control is the best of the databound controls. I also try to keep the datasets out of the code behind and put a business object layer in between the code behind and the datasets. That way the only things I'm binding to are collections of classes, and most of my code is in those classes. Generics are really handy for this. And when you combine them with reflection they become really powerful. I've actually been meaning to write an article about it for some time now, maybe I should get up off my lazy ass and do so

Don't give up on .Net. Its brilliant, you just have to get used to how things are done in the .net world.

DublinWriter

Evil Phil wrote: »

I also try to keep the datasets out of the code behind and put a business object layer in between the code behind and the datasets. That way the only things I'm binding to are collections of classes, and most of my code is in those classes.

True, you could be exposing your app to allsorts of SQL-injection nastiness otherwise.

It's a pretty capable technology alright, but it's still very much at the HTML nuts-and-bolts stage. They could have built on the existing core and made something a little more RAD.

Kinda reminds me of that Dilbert cartoon circa 2000 where a web-designer goes into shock and has to be resuscitated. When the doctor arrives, he says the problem occurred because the designer was "exposed to raw HTML".