<asp:DetailsView ID="ctrlAddProject" runat="server" CssClass="addProject" GridLines="None" DefaultMode="Insert" DataSourceID="dsProjects" AutoGenerateRows="False">
<Fields>
   <asp:BoundField InsertVisible="False" DataField="ProjectID" ReadOnly="True" />
   <asp:BoundField HeaderText="Name" DataField="Name" />
   <asp:BoundField InsertVisible="False" DataField="CreateDate" ReadOnly="True" />
   <asp:BoundField HeaderText="Description" DataField="Description" />
   <asp:BoundField InsertVisible="False" DataField="SecurityActionID" ReadOnly="True" />
   <asp:CommandField ShowInsertButton="True" />
</Fields>
</asp:DetailsView>

The original unaltered ASP.NET control produced the following html (Note, there are only two data rows; Name and Description; and one row for the Insert/Cancel buttons)

<table class="addProject" cellspacing="0" border="0" id="ctl00_ContentPlaceHolder1_AnalysisPlan1_ctrlAddProject" style="border-collapse:collapse;">
    <tr>
        <td>Name</td>
        <td><input name="ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl02" type="text" title="Name" /></td>
    </tr>
    <tr>
<td>Description</td>
        <td><input name="ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl04" type="text" title="Description" /></td>
    </tr>
    <tr>
<td colspan="2"><a href="javascript:__doPostBack('ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl06','')">Insert</a> <a href="javascript:__doPostBack('ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject','Cancel$-1')">Cancel</a></td>
    </tr>
</table>

After configuring the CSS friendly control adapter...(Note the hidden rows are generating markup in this version - the effect of which is to have a bunch of unwanted text input boxes littered around)

<div class="AspNet-DetailsView">
    <div class="AspNet-DetailsView-Header">
    </div>
    <div class="AspNet-DetailsView-Data">
    <ul>
        <li>
            <span class="AspNet-DetailsView-Name">&nbsp;</span><span class="AspNet-DetailsView-Value"><input name="ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl01" type="text" /></span>
</li>
<li class="AspNet-DetailsView-Even">
            <span class="AspNet-DetailsView-Name">Name</span><span class="AspNet-DetailsView-Value"><input name="ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl02" type="text" title="Name" /></span>
        </li>
        <li>
            <span class="AspNet-DetailsView-Name">&nbsp;</span><span class="AspNet-DetailsView-Value"><input name="ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl03" type="text" /></span>
        </li>
        <li class="AspNet-DetailsView-Even">
            <span class="AspNet-DetailsView-Name">Description</span><span class="AspNet-DetailsView-Value"><input name="ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl04" type="text" title="Description" /></span>
        </li>
        <li>
            <span class="AspNet-DetailsView-Name">&nbsp;</span><span class="AspNet-DetailsView-Value"><input name="ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl05" type="text" /></span>
        </li>
        <li class="AspNet-DetailsView-Even">
            <span class="AspNet-DetailsView-Name"><a href="javascript:__doPostBack('ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject$ctl06','')">Insert</a> <a href="javascript:__doPostBack('ctl00$ContentPlaceHolder1$AnalysisPlan1$ctrlAddProject','Cancel$-1')">Cancel</a></span>
        </li>
    </ul>
    </div>
    <div class="AspNet-DetailsView-Footer">

    </div>
</div>

On my second point; the CSS version is bigger than the table version because;
1) The unwanted rows are being rendered (hopefully this will be fixed in the next release)
2) A Header and a Footer div are being rendered.  There's nothing in them so this needs to be optimised away.
3) Overuse of span's and class attributes.  A better version of a row above might look like

      <li>        
        <label for="name">Name:</label>
        <input type="text" id="name" />
      </li>

Better because it uses tags with semantic meaning (label instead of span), and less markup because it should be possible to write a CSS rule that selects the label and the textbox by position rather than having to litter the whole markup with class attributes.  Something akin to this might do the job:

.AspNet-DetailsView li label
{
   */ label styling here */
}

.AspNet-DetailsView li input.text
{
   */ text box styling here */
}

The beauty of the new extenders is that individuals can fix their own markup....but it would be nice if the out-of-the-box versions rendered:
a) semantic markup where possible rather than the more generic divs and spans
b) the minimum markup needed to do the job and use css rules as they are supposed to be used
as a good example to all.

Great idea guys and it will be sweet when the examples are 'tight'

Brian.

For those interested in simulating the original problem having to do with InsertVisible... go to DetailsViewExample.aspx and alter the DetailsView so it looks like this:

Run the page.  Only the ZIP code line should show up because the other bound fields are explicitly marked with InsertVisible="False". That's the problem with the current implementation of the DetailsViewAdapter.  I'm working on a fix...

Brian, here is a quick fix for the rows showing up that have been marked as visible.

Open up the DetailsViewAdapter.cs file and add this if statement after the foreach statement.

Rows that are marked as visible=false, the HeaderText value is "&nbsp;"  So if it is not "&nbsp;"   then it must be marked as visible.

Cool, TPS.  Thanks for contributing that.

I ended up with a slightly different "if" expression:

if ((!ControlAsDetailsView.AutoGenerateRows) &&
    ((row.RowState & DataControlRowState.Insert) == DataControlRowState.Insert) &&
    (!ControlAsDetailsView.Fields[row.RowIndex].InsertVisible))
{
    continue;
}

I put this just inside the "foreach" statement you referred to (above).  What do you think of this alternative?

Hey Russ, that looks like it will work for Insert mode.  But what about just plain old view mode when you are looking at a DetailsView.  It seems that you are only accounting for Insert Mode.

I know my solution is short sighted because I don't have enough knowledge to think about rowstate and whether we are in insert mode or not, but now you have me thinking.

My solution does not account for the developer who purposely decides not to have a row HeaderText set.

But your "ControlAsDetailsView.Fields[row.RowIndex].InsertVisible" is what I was really looking for, so how about...

(psuedo code)

if  ( (InsertMode & InsertVisible) || (EditMode & Visible) || (ViewMode & Visible) )

Doesn't that cover all the situations?

I guess you have the following statement include for performance because you would not be making this check if you were auto gening the rows.

((!ControlAsDetailsView.AutoGenerateRows

Thanks for you fast response Russ, I look forward to your response so I can put this bit of the site configuration to bed.

Terrence

Hey Russ, on another note, have you guys:

1.  Come up with anymore themes?  I know we can come up with them, but I'm a data man and making sights look good is not my strong point.

2.  Come up with a Control Adapter for the GridView?

Thanks again for the great tools you guys are coming up with.

Terrence

Hi Terrence, you asked in an earlier post (in this thread) if we ought to further modify the "if" expression to specifically cover the "view" and "edit" cases, beside the "insert" case.  I think the answer is that we don't really need to.  The property InsertVisible is rather unique.  There is no counterpart to it.  There is no EditVisible or ViewVisible property.  So it seems like we really only need to handle InsertVisible when we are in insert mode.  Otherwise, we can ignore it and don't have any other comparable attributes to worry about.  I think the framework (deeper down) handles the case where Visible=false by not trying to do the render at all.  Let me know if you seem to see evidence that that isn't so.

Now, regarding your other ideas:

1. Creating some additional themes is an interesting idea.  Frankly, it would be a great way for some enterprising developer/designer to make some good money.  Someone could start building themes that specifically work with the kit's adapters (together with skins that work when the adapters aren't being used... for old browsers, etc.).  Maybe there is a market for such themes. Meanwhile, I'll keep your suggestion (free additional themes for the kit) in mind but I must admit that there's plenty of work "on the plate" having to do with extending the kit to cover more controls and more control properties (attributes). Ahhhhh, I had making choices like this!
2. Building a GridViewAdapter is already on my radar.  In fact, I've already started the work. I intend to include it in the next rev of the kit.

Please keep providing feedback.  It's very helpful.  Best regards,

Russ, I see what you mean about the InsertVisible.

I now see that the fields are not getting rendered if InsertVisible is false, but the <li> row is getting generated, so if I have 3 hidden fields I get 3 blank rows.

I know you are a busy man, but any idea when the next rev will be coming out?  I love the controls.

Terrence

Hi Terrence,

Hmmmm.  I don't know why you are seeing empty <li> elements in your markup.  The code shown above shouldn't result in that:

if ((!ControlAsDetailsView.AutoGenerateRows) &&
    ((row.RowState & DataControlRowState.Insert) == DataControlRowState.Insert) &&
    (!ControlAsDetailsView.Fields[row.RowIndex].InsertVisible))
{
    continue;
}

This should cause the entire <li>'s generation to be aborted if you are in insert mode but the field is marked as InsertVisible==false.

Did you put this immediately inside the foreach, before the <li> is spit out into the writer?

There is a small problem insofar as the calculation of odd/even rows as a result of potentially skipping some rows because of this new heuristic.  I'll clean that up for the next rev.

And speaking of the next rev, all I can say is that it is definitely happening and won't be too long: a matter of a few weeks or a couple months, at most.  Hang tight.  It's like remodeling a house: you have to rip stuff up a bit before you put it back together into an improved state.  We're not done cleaning up from some of the refactoring, etc.

Sorry Russ, I didn't mean to imply that if we used your new if statement that empty <li> were showing up.

Just scratch what I said in my last post.

By the way, I know this has nothing to do with your great control adapter, but could you tell me if I am loosing my mind on this DetailsView issue.

If you don't include a field from the datasource in the DetailsView, the existing data in that field will be wiped out after you edit that row in the DetailsView when it is bound to an ObjectDataSource.

Example:

Table fields: First, Last, Address, Payrate

Table row values: Bob, Schmo, 123 Main, 125

Edit row in DetailsView

First: Bob changes to Robert

Last: Schmo

Address: 123 Main

Click Update

Table Row values: Robert, Schmo, 123 Main, 0

----------------------------------------

It seems the DetailsView ObjectDataSource is generating a new object, populating the object and sending it back with the MyBizObj.Update.  Which would send the PayRate field back as 0.

Instead it should Get the object from the DB, populate it with the DetailsView fields and send it back to the DB.

This is very easy to Reproduce.

We ended up wiping out lots of data because a form we were giving to a user didn't include 4 or 5 fields of sensitive data.  All of the sensitive data is now gone for the rows that she edited.

Hey Russ, I will post this in some other forums, but could you just check it out yourself.  Dealing with the DetailsView control adapter, you could just remove a field and then update a record. 

Lete me know if you wipe out data as well if you would.

Thanks

I've just got the control adapters and have noticed this code seems to have been added to the latest vers to handle rendering fields not set to visible. This is fine when using Fields ie

ControlAsDetailsView.Fields[row.RowIndex].Visible but if the rows are set to Visible = false then there also needs to be a check for ControlAsDetailsView.Rows[row.RowIndex].Visible

I like the adapter framework and hopefully the next iteration of asp.net controls will render nicer markup like this natively.