VS2005 minor peeves

[Larry Charlton]

I've begun trying to create some basic applications and controls and am left
wondering if Microsoft rushed this to market, is just anti-web standards, or
just wants it to be hard to create great sites. For instance:

When I create a template or region editing control. Why doesn't the region
or template pick up the attributes of the container I'm editing (and
preferably staying in the flow of the page)? Why does this matter? Well, if
I apply CSS to the template container, when I'm editing the template/region
I'm SOL for getting that applied to what I'm editing. The result is I either
duplicate a lot of look and feel throughout the CSS just to get design time
to work or I write and maintain two different CSS's, hoping they don't
diverge. Also ever notice that if you use CSS to make a region a particular
size that at design time you get a default size editing region/template? I'm
sure there's a hack somewhere to fix this, but it for some reason eludes me.

Were skins a last minute idea to a) allow developers to quickly turn out
horribly bloated sites b) a patch so that the developers never had to talk to
the web guys about what decent stylable content looks like? I can see a
purpose for skins, but just barely and certainly not as a replacement for
allowing you to apply styles to various aspects of a control. While I was
frustrated styling a default form, I've seen that if you like one look and
don't want to add anything fancy it's possible to get a basic FormView styled
via CSS. What does that mean? You end up editing and re-writing the
autogenerated form, not once but THREE times (and that means debugging and
maintenance just jumped three times as well). Also note that you can't see
them overlaid so you probabbly end up building something that lets you flip
between view and other modes to ensure the form is solid). Flexible, but I'm
not sure it's a leap forward in code reduction or RAD. What about editing in
a datagrid? Well look at the samples, you either end up setting a lot of
properties or you get a jumpy editing experience (see like every demo on the
web) while switching between edit and view mode. And for both of these, is
it me or why exactly did they opt not to apply max character widths to fields
that were added either dynamically or converted to a template based on what's
in the datasource they pulled the field from? That's one more edit I have to
keep in sync and is totally manual (or I end up writing more validation
logic, see problem below, and notifying the user late that gee, he just typed
too much stuff, in 14 fields...)

Have you ever wondered why they view error validation like a student fresh
out of college? What's the likelyhood that you will have exactly one thing
thats worth checking for a bit of input? (At least assuming you want your
site to actually function in the real world). Why didn't they provide basic
validation functionality that went into a validation component (so you could
declaratively combine a required field and a range field for instance) sort
of a composite validation. Sure you can write a control to do what you want,
but you have to build the infrastructure if you want to plug multiple error
checks together depending on the control. Think I'm making it up? Look at
every example from Microsoft (even the ones specifically on validation).

Ever try to inherit a Button control? what's missing in the property pane?
Oh gee, the TEXT field! Just go back and override it? Nope, it's not
overrideable in that control for some reason.

While I'm sure it's possible to create semi decent sites using pure CSS with
the default Forview and Gridview (and probably other controls) and get a
decent design and runtime experience, it at least to me seems FAR harder and
more obscure than coding a CSS site in ASP (bam, there went 6+ years), but
should the design experience affect the finished site in any way? Other than
possibly making it easier to make the site cooler or faster? Shouldn't it
facilitate making lighter faster pages instead of promoting bloat? (Which
incidentally means more debugging and maintenance down the road).

Don't get me wrong, I love VS2005, but at least some of the beauty, speed
and ease of use appear at best skin deep.

Slighly disgruntled,

Larry

[DKode]

my biggest gripe with ASP.NET 2.0 is the fact that it does NOT generate
strict html code when a page is rendered. I was really hoping that this
would be fixed in 2.0, but I guess not.

I am a big fan of CSS based design, but until microsoft gets on the
boat, it makes it very difficult to use full CSS.

[Scott Allen]

On 15 Feb 2006 05:23:10 -0800, "DKode" <dk****@gmail.com> wrote:

my biggest gripe with ASP.NET 2.0 is the fact that it does NOT generate
strict html code when a page is rendered. I was really hoping that this
would be fixed in 2.0, but I guess not.

I am a big fan of CSS based design, but until microsoft gets on the
boat, it makes it very difficult to use full CSS.

Can you provide a specific example? Perhaps it is an issue that
someone will know how to solve, or at the least we can see if it is a
known bug.

--
Scott
http://www.OdeToCode.com/blogs/scott/

[Scott Allen]

Hi Larry:

I had a couple thoughts about your post. I can't speak to all of your
peeves - just a few, but I snipped the post and am just addressing
areas where I think I can be helpful - hope you don't mind.

Re: Skins

I don't view skins as a CSS replacement. Skin files and the ASP.NET
2.0 Theme infrastructure make it easier to maintain a consistent and
flexible presentation based on CSS. I can drop different .css files
into different theme folders and the runtime automatically injects the
correct css links into my webforms for the selected theme. This
approach lends itself to easily personalizing a site.

I think there will always be some difficulty applying styles to the
complex ASP.NET 2.0 controls, because a control like GridView is at a
much higher level of abstraction than the HTML it renders. It's like
trying to control the native machine language opcodes generated at JIT
time from C# or VB.NET - those opcodes should be opaque to a
developer.

Nevertheless, perhaps Microsoft could do a better job in allowing
developers and designers to style the more complex controls (and
perhaps the Expression suite will address this problem).

In the meantime, skins can do a pretty job of enforcing a CSS design.
A .skin file with the following:

<asp:GridView CssClass="gridview" runat="server"
<AlternatingRowStyle CssClass="gvAlternatingrow"/>
<FooterStyle CssClass="gvFooter"/>
<HeaderStyle CssClass="gvHeader"/>
...
</asp:GridView>

... goes a long way towards consistency and maintainability, and all
the good stuff is still tucked away in a .css file.

Re: Jumpy GridView editing

You might try the MaintainScrollPositionOnPostBack property. Jumpiness
is unfortunately always been a part of the web. AJAX / Atlas can
alleviate the problem to some extent, but smart clients will always be
better at data input and editing.

Re: Validation

I imagine this is a case of time and priorities at MS, though I'm not
sure what specific problem(s) you are driving at. Have you added two
different validator types on a form and asked them to validate the
same control ID?

P.S.

I think you'll find some good tips about developing to standards in
this document:

Building ASP.NET 2.0 Web Sites Using Web Standards
http://msdn.microsoft.com/asp.net/co...pnetusstan.asp

--
Scott
http://www.OdeToCode.com/blogs/scott/

[Larry Charlton]

Hi Scott,

Opinions and insights always welcomed even if you disagree.

Re: Skins

I don't view skins as a CSS replacement. Skin files and the ASP.NET
2.0 Theme infrastructure make it easier to maintain a consistent and
flexible presentation based on CSS. I can drop different .css files
into different theme folders and the runtime automatically injects the
correct css links into my webforms for the selected theme. This
approach lends itself to easily personalizing a site.
I agree and there are definitely cases where can skins can make some things
much better/easier/consistent. But from an HTML perspective, why didn't they
realize that for some things (such as grids and forms) that they are made up
of consituent bits (for instance prompts). I'll have to admit after taking a
closer look at the grid view, it has most of what I want (the ability to
style each of the pieces) and while I don't see it immediately I believe it's
possible to style individual cells if needed (such as formatting negative
numbers red). I shouldn't have lumped it in with FormView which was giving
me grief. My complaints with it are: How do you change the width of the
prompt (especially if the input on the right has lengths indicating the
amount of data to be entered), or worse, if you have multiple controls (say a
text box and a lookup button). How do you quickly right align or left align
them (ok left's easy :)). How do you control the font used for prompts
independantly from the data? The answer is you have to rewrite what it
generates (3 times). Would it have been difficult to use a label (or if
they're worried about downstream browsers) a div, span, anything but NOTHING!
I think there will always be some difficulty applying styles to the
complex ASP.NET 2.0 controls, because a control like GridView is at a
much higher level of abstraction than the HTML it renders. It's like
trying to control the native machine language opcodes generated at JIT
time from C# or VB.NET - those opcodes should be opaque to a
developer. I respectfully disagree. I think abstracting it actually makes it easy to
create stylable content because they controll 100% of those little opcodes.
It just requires thought and planning. They can actually generate many
different html sequences based on values chosen for a control. (Just look at
third party controls). For a simple example consider a generic input widget
(not included). It might have the following properties: A required
indicator, a label/prompt, an input region, and an error indicator. This is
just a for instance based on many many web forms I've seen. One thing they
could control is changing an <input> tag to a <div> tag if the control was
read-only or in View mode. In fact if you think about it for many forms they
could have collapsed three templates into a single template while still
leaving the ability to create the other specialized templates. Based on the
applications and sites I've seen this would account for 95+% of the web forms
out there while reducing the work required to build and maintain that form by
a factor of 3! Recognizing the purpose of a form and building the
appropriate tool is important.
... goes a long way towards consistency and maintainability, and all
the good stuff is still tucked away in a .css file. totally agree (that's what made me peek at the gridview again) Thanks! :)
Re: Jumpy GridView editing

You might try the MaintainScrollPositionOnPostBack property. Jumpiness
is unfortunately always been a part of the web. AJAX / Atlas can
alleviate the problem to some extent, but smart clients will always be
better at data input and editing. The jumpy I was refering to is that when you switch from view to edit mode,
unless you spend a great deal of time and effort the grid will resize.
Update Cancel is a different width that Edit Delete. As far as I can tell
the only way to determine how wide to make the colum with the command buttons
is to run the app, save the HTML to a file and then start fiddling with colum
width while editing. (or if you're width is in the CSS, refreshing the page
and clicking retry every time. Next the view version of each column is
almost always a different width than the control. The solution is to set
both the item width and the control width for each column. Why exactly a
sane person would want both of those widths eludes me, but I'm sure there
might be an occasion.
Re: Validation

I imagine this is a case of time and priorities at MS, though I'm not
sure what specific problem(s) you are driving at. Have you added two
different validator types on a form and asked them to validate the
same control ID? You can certainly do that if you want for instance two !! after a control
with two errors and it will work fine. I would prefer what most web forms do
and just have a single ! indicating an error even if there are 12 errors
(that's what the summary is for).
I think you'll find some good tips about developing to standards in
this document:

Building ASP.NET 2.0 Web Sites Using Web Standards
http://msdn.microsoft.com/asp.net/co...pnetusstan.asp

Thanks, always looking for good reading (well most of the time, swamped in
all the reading between SQL 2005 (or is that the SQL 2005 suite?) and the
ASP.net stuff. I'll definitely give it a read though.

Larry

[Larry Charlton]

I'm not sure if this is what he's refering to, but try this.

In a form place the following:
<asp:Panel ID="Panel1" CssClass="panel" runat="server">
<asp:Panel ID="Panel2" CssClass="filter" runat="server">
</asp:Panel>
<asp:Panel ID="Panel3" CssClass="list" runat="server">
</asp:Panel>
<asp:Panel ID="Panel4" CssClass="form" runat="server">
</asp:Panel>
</asp:Panel>

A panel with three panels in it.

add a styleSheetTheme to web.config

in the stylesheet put:
..panel
{
width: 40.8em;
border: solid 1px gray;
}

..filter
{
float: left;
border: solid 1px blue;
width: 10em;
height: 30em;
}

..list
{
float: left;
border: solid 1px red;
width: 10em;
height: 30em;
}

..form
{
height: 30em;
width: 19.8em;
float: right;
border: solid 1px green;
}

Simple a panel that has three side by side panels inside it, ... well at run
time ... At design time you have three stacked exactly the same size panels
(note that the css says they're side by side and two left ones are narrower
than the right one) and the sizes aren't even in the ball park for the css.

Now paste this into the form:
<div class="panel">
<div class="filter"> </div>
<div class="list"> </div>
<div class="form"> </div>
</div>
That actually works at design time, but for some reason the built in
controls seem to ignore at least portions of the classes they belong to at
runtime.

[Peter Blum]

You wrote:
Have you ever wondered why they view error validation like a student fresh
out of college? What's the likelyhood that you will have exactly one thing
thats worth checking for a bit of input? (At least assuming you want your
site to actually function in the real world). Why didn't they provide basic
validation functionality that went into a validation component (so you could
declaratively combine a required field and a range field for instance) sort
of a composite validation. Sure you can write a control to do what you
want,
but you have to build the infrastructure if you want to plug multiple error
checks together depending on the control. Think I'm making it up? Look at
every example from Microsoft (even the ones specifically on validation).

I realize that you are presenting a case for improvements of VS. But you
also may be interested in solutions that are available to you.

Long ago, I realized the problem you are presenting and wrote a replacement
for the ASP.NET Validators. Professional Validation And More
(http://www.peterblum.com/vam/home.aspx) addresses far more issues than what
you've raised. There is plenty more Microsoft can do to give you a full
validation system.
For example, one of my 25 validators, the MultiConditionValidator, lets you
construct a boolean expression out of other validators, which will handle
your required field + range example.

--- Peter Blum
www.PeterBlum.com
Email: PL****@PeterBlum.com
Creator of "Professional Validation And More" at
http://www.peterblum.com/vam/home.aspx

"Larry Charlton" <La***********@discussions.microsoft.com> wrote in message
news:32**********************************@microsof t.com...

I've begun trying to create some basic applications and controls and am
left
wondering if Microsoft rushed this to market, is just anti-web standards,
or
just wants it to be hard to create great sites. For instance:

When I create a template or region editing control. Why doesn't the
region
or template pick up the attributes of the container I'm editing (and
preferably staying in the flow of the page)? Why does this matter? Well,
if
I apply CSS to the template container, when I'm editing the
template/region
I'm SOL for getting that applied to what I'm editing. The result is I
either
duplicate a lot of look and feel throughout the CSS just to get design
time
to work or I write and maintain two different CSS's, hoping they don't
diverge. Also ever notice that if you use CSS to make a region a
particular
size that at design time you get a default size editing region/template?
I'm
sure there's a hack somewhere to fix this, but it for some reason eludes
me.

Were skins a last minute idea to a) allow developers to quickly turn out
horribly bloated sites b) a patch so that the developers never had to talk
to
the web guys about what decent stylable content looks like? I can see a
purpose for skins, but just barely and certainly not as a replacement for
allowing you to apply styles to various aspects of a control. While I was
frustrated styling a default form, I've seen that if you like one look and
don't want to add anything fancy it's possible to get a basic FormView
styled
via CSS. What does that mean? You end up editing and re-writing the
autogenerated form, not once but THREE times (and that means debugging and
maintenance just jumped three times as well). Also note that you can't
see
them overlaid so you probabbly end up building something that lets you
flip
between view and other modes to ensure the form is solid). Flexible, but
I'm
not sure it's a leap forward in code reduction or RAD. What about editing
in
a datagrid? Well look at the samples, you either end up setting a lot of
properties or you get a jumpy editing experience (see like every demo on
the
web) while switching between edit and view mode. And for both of these,
is
it me or why exactly did they opt not to apply max character widths to
fields
that were added either dynamically or converted to a template based on
what's
in the datasource they pulled the field from? That's one more edit I have
to
keep in sync and is totally manual (or I end up writing more validation
logic, see problem below, and notifying the user late that gee, he just
typed
too much stuff, in 14 fields...)

Have you ever wondered why they view error validation like a student fresh
out of college? What's the likelyhood that you will have exactly one
thing
thats worth checking for a bit of input? (At least assuming you want your
site to actually function in the real world). Why didn't they provide
basic
validation functionality that went into a validation component (so you
could
declaratively combine a required field and a range field for instance)
sort
of a composite validation. Sure you can write a control to do what you
want,
but you have to build the infrastructure if you want to plug multiple
error
checks together depending on the control. Think I'm making it up? Look
at
every example from Microsoft (even the ones specifically on validation).

Ever try to inherit a Button control? what's missing in the property
pane?
Oh gee, the TEXT field! Just go back and override it? Nope, it's not
overrideable in that control for some reason.

While I'm sure it's possible to create semi decent sites using pure CSS
with
the default Forview and Gridview (and probably other controls) and get a
decent design and runtime experience, it at least to me seems FAR harder
and
more obscure than coding a CSS site in ASP (bam, there went 6+ years), but
should the design experience affect the finished site in any way? Other
than
possibly making it easier to make the site cooler or faster? Shouldn't it
facilitate making lighter faster pages instead of promoting bloat? (Which
incidentally means more debugging and maintenance down the road).

Don't get me wrong, I love VS2005, but at least some of the beauty, speed
and ease of use appear at best skin deep.

Slighly disgruntled,

Larry

[Larry Charlton]

Nice thanks!

[Scott Allen]

On Wed, 15 Feb 2006 17:45:07 -0800, "Larry Charlton"
<La***********@discussions.microsoft.com> wrote:

Simple a panel that has three side by side panels inside it, ... well at run
time ... At design time you have three stacked exactly the same size panels
(note that the css says they're side by side and two left ones are narrower
than the right one) and the sizes aren't even in the ball park for the css.

Yes - seems to be a designer flaw, or a flaw in the "designer" html
that the Panel control renders.

Honestly, I quit using the designer years ago. The designer is better
in VS2005 (but so is the source view, because I can drag and drop from
the toolbox, so I'm still sticking with source view). Hopefully
they'll keep improving the desginer.

I see a bug entry that is pretty close to this:
http://lab.msdn.microsoft.com/produc...9-e04c8bf1cec5

--
Scott
http://www.OdeToCode.com/blogs/scott/

[anti_interactive]

http://anti-interactive.org/