I'm getting into ASP.NET (C# - I know it doesn't matter for this particular question, but full disclosure and all that), and while I love that the asp:-style controls save me a lot of tedious HTML-crafting, I am often frustrated with certain behaviors. I encountered one last night when working with Master Pages: my <asp:BulletedList ID="nav">, when converted into HTML, became <ul id="ct100_nav">.
There are other issues--I noticed that when you auto-populate a DataGrid, it adds attributes to the resulting table that I don't necessarily want there.
I know that there is a certain amount of "convention over configuration" that you have to accept when you rely on a framework to take over some of your tedious duties, but the "conventions" in these cases aren't so much any established conventions, but rather unnecessary extras. I know why the ID adds the prefix, but I should be able to tweak and turn things like this off, especially since, as a bit of a web standards evangelist, I don't duplicated HTML id's in a single page anyway.
So the question here is for those ASP.NET devs more seasoned than I: in your experiences in developing and deploying apps, how do you leverage these controls? Do you find yourself resorting back to hard-coded HTML? Do you use a blend? I don't want to design my HTML around idiosyncratic quirks in these controls, but, if possible, I'd like to leverage them when possible.
What's a boy to do?
Personally,
I think the standard ASP.NET controls are fine for inhouse stuff - quick and dirty is good in that scenario. But, I once worked with a web developer who was also a designer and he refused to use the ASP.NET controls and only code in HTML and add runat="server" tags when needed. This was more because he wanted to know exactly how his HTML was going to be rendered, and at the time anyway, some of the ASP.NET controls wouldn't render to standards compliance.
I sit somewhere in the middle - use HTML where appropriate and not when not. You can sort of best of both worlds with the CSS control Adapters
I'm actually quite relieved to see some opinions here agreeing with my own: ASP.NET as a template language is very poor.
I'd just like to rebut a couple of the pro points made here (flamesuit on!):
Dave Ward mentions ID collisions - this is true, but my how badly handled. I would have preferred to see nodes referenced by xpath or deep css selectors than by making the ID effectively useless except by deferring to ASP.NET internals like clientID - it just makes writing CSS and JS that much harder pointlessly.
Rob Cooper talks about how the controls are a replacement for HTML so it's all fine (paraphrasing, forgive me Rob) - well it's not fine, because they took an existing and well understood language and said "no, you have to do things our way now", and their way is very poorly implemented. e.g. asp:panel renders a table in one browser and a div in another! Without documentation or execution, the markup for a login control (and many others) isn't predictable. How are you going to get a designer to write CSS against that?
Espo writes about how controls give you the benefits of abstraction if the platform changes the html - well this is clearly circular (It's only changing because the platform is changing, and wouldn't need to if I just had my own HTML there instead) and actually creates a problem. If the control is going to change with updates again how is my CSS supposed to cope with that?
Apologists will say "yes but you can change this in the config" or talk about overriding controls and custom controls. Well why should I have to? The css friendly controls package meant to fix some of these problems is anything but with it's unsemantic markup and it doesn't address the ID issue.
It's impossible to implement MVC (the abstract concept, not the 3.5 implementation) out of the box with webform apps becuase these controls so tightly bind the view and control. There's a barrier of entry for the traditional web designer now because he has to get involved with server side code to implement what used to be the separate domains of CSS and JS. I sympathise with these people.
I do strongly agree with Kiwi's point that controls allow for some very rapid development for apps of a certain profile, and I accept that for whatever reason some programmers find HTML unpleasant, and further that the advantages the other parts of ASP.NET give you, which requires these controls, may be worth the price.
However, I resent the loss of control, I feel the model of dealing with things like classes, styles and scripting on the codebehind is a wrongheaded step backwards, and I further feel that there are better models for templating (implementation of microformats and xslt for this platform) although replacing controls with these is non-trivial.
I think ASP.NET could learn a lot from related tech in LAMP and rails world, until then I hope to work with 3.5 MVC where I can.
(sorry that was so long </rant>)
The short answer is that you should never use an asp:... version of a standard HTML control unless you have a really good reason.
Junior developers often get suckered into using those controls because they're covered in most ASP.NET books, so it's assumed that they must be better. They're not. At this point, after 8 years of daily ASP.NET development, I can only think of 2 or 3 cases where it actually makes sense to use an asp:... INPUT control over a standard HTML one.
As for the ID's on server-controls: You can find the actually ID that is going to be written to the browser by accessing ClientID. That way you can combine server-side og client-side scripting and still dont have to hardcode _id="ct100_nav"_
I always try to use the included controls instead of "hacking" HTML, because if there is an update or some improvement later on, all my code will still work by just replacing the framework and I don't have to change any HTML.
Hope this helps
#Brian,
Yup! You can pretty much control all the behaviour.. Consider looking into creating Custom Controls (there are three types). I recently gave an overview of them in my question here.
I would strongly recommend checking them out, has help me no end :)
I too am on my adventure into ASP.NET and have also had similar frustrations.. However, you soon get used to it. You just need to remember, the reason you dont have the tedious HTML crafting is because the ASP.NET controls do it all for you.
To some extent you can control/tweak these things, even if it means inheriting the control and tweaking the HTML output from there.
I have had to do that in the past, where certain controls were not passing W3C validation by default by putting some extra markup here and there, so I simply overrode and edited as necessary (a fix that too literally a couple of minutes)..
I would say learn about how the controls system works.. Then knock a few together yourself, this has really helped me grok whats going on under the hood, so if I ever get any problems, I have an idea where to go.
The HTML renders with those sort of IDs because its ASP.NET's way of preventing ID collisions. Each container control, such as a Master page or Wizard control, will prepend an "ID_" on its childrens' IDs.
In the case of your bullet list, the ListView provides a nice middle ground. You can still bind it to a datasource, but it gives you much tighter control over the rendered HTML. Scott Gu has a nice intro to the ListView here:
http://weblogs.asp.net/scottgu/archive/2007/08/10/the-asp-listview-control-part-1-building-a-product-listing-page-with-clean-css-ui.aspx
If the ID's prefix added by ASP.NET is an issue for you to access them later using JS or something... you have the .ClientID property server side.
If the overhead added by ASP.NET you should consider ASP.NET MVC (still preview) where you have full control over the emitted html.
I'm moving to MVC because I don't like all that stuffs added too....
I think most of the answers here take a designer's point of view. On a small-to-medium project it might seem like an overhead to synchronize code and CSS/HTML and make them standards-compliant and clean. A designer's way to do that is to have full control over rendered HTML. But there's many ways to have that full control in ASP.NET. And for me, having the required HTML in the aspx/ascx file is the most non-scalable and dirty way to do it. If you want to style controls through CSS, you can always set a class server-side through the CssClass property. If you want to access them through JS, you can emit the JS with right IDs server-side again. The only disadvantage that this provides is that a dev and a designer have to work together closely. On any large project this is unavoidable anyway. But the advantages ASP.NET provides far outnumber these difficulties.
Still, if you want standards-compliant HTML, skinning support and other goodies to control rendered markup, you can always use thrid-party controls.
As Dave Ward has already mentioned, "it's ASP.NET's way of preventing ID collisions."
A very good example of this is if you're attempting to put a control inside of a custom control, then use that custom control in a repeater, so that custom control's HTML would be output multiple times for the page.
As others have mentioned, if you need to access the controls for javascript, use the ClientScript property which will give you access to a ClientScriptManager and register your scripts to the page this way. Be sure when writing your scripts to use the ClientID property on the control you're trying to reference instead of just typing in the control's ID.
If you want that much control over the rendered HTML, look into ASP.NET MVC instead.
Related
I've just read an interesting article about how Microsoft seems to be moving towards a REST interface + client-side javascript-based MVVM development for web applications.
Although I technically understand the basic difference between the two models, I am utterly confused regarding its implications about how I write web applications and most importantly how to transition gracefully to this new model.
So, for someone moving from traditional ASP.NET MVC to WebApi + KO, the following questions arise:
Is there a way to have unobtrusive or near-unobtrusive (i.e. minimal code) validation using MVC + KO?
How does one go about unit testing his UI code?
Does browser compatibility suffer with KO?
Is there anything else someone has to consider when moving from one model to the other?
You see Microsoft starting to push this "single page web app" thing partly because it can provide a better user experience but largely because it makes it much much easier to migrate your web app to being a Windows 8 native application.
Re: unobtrusive javascript for validation… I would say that if you're using Knockout, you're UI and your scripts are going to be so tightly coupled even just for basic stuff that unobtrusiveness is really not a valid goal. You can do validation in Knockout (see https://github.com/ericmbarnard/Knockout-Validation#readme for example) but it's not unobtrusive by the same definition as ASP.NET MVC
Re: unit testing... take a look at https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit
Re: browser compat... I'm not aware of any compatibility issues with any modern browsers unless you have crazy users who have disabled JavaScript
I found this to be a really nice discussion of the pros and cons of trying to be "unobtrusive" with a Knockout site.
Traditionally I'm very much in favour of keeping Javascript as unobtrusive as possible, and with my Knockout expressions I try to keep them as minimal and tidy as possible by shifting any heavy lifting into functions on my view model and creating custom bindings which encapsulate DOM logic - but I'm firmly of the opinion that the declarative approach itself (such as the default of using the data-bind attribute), when used sensibly, is the way to go.
Perhaps it's because my introduction to Knockout is a web application "port" of a WPF application I worked on, and the Knockout bindings of my site are becoming surprisingly close to their XAML equivalents as I learn more about how to leverage Knockout gracefully. I just love being able to eyeball markup and see at a glance the real business logic around how a view is evaluated, rather than the specifics of how jQuery or whatever physically builds it in response to some click event wired up in a big soul destroying Javascript file.
When I revisit some of my traditional MVC sites which leverage lots of procedural jQuery to hook things up, I think, yeah the markup is tidy, but going back to it after 6 months even I have difficulty understanding what my intention was with all those jQuery selectors, callbacks, and DOM traversals. I think I would only apply the Knockout bindings themselves dynamically if I had to, i.e. if there was a situation where my binding logic was itself dynamic - but that could probably be accomplished differently with dynamic templates anyway.
That's my 2 cents on the unobtrusive aspect of your question, and if your experience moving to MVVM Javascript is anything like mine has been over the last few months, you won't look back.
I have searched for this topic, and can't find anything that answers my needs, so I am assuming I may be looking at this the wrong way. Keep in mind, I was a classic ASP developer for 13 years, so I am used to having control over all of my code.
I have many forms on my sites for updating data: Customer information, Supplier information, Product information, User information, etc., etc. I used a library I wrote which made it easy to simply build a form, set the values, and it created the update script automatically. However, in ASP.Net, it just doesn't seem this is the way to do it.
ASP.Net, seems to have wizards. Personally, I don't like that approach. I like full control. I don't even like the ASP.Net validation controls...
Option 1: Build classes with update methods. Build a standard ASP.Net form, which will update the data through the class?
Option 2: Use the annoying GridViews, DataAdapters, wizards, etc., etc.
Option 3: Standard form, with AJAX, calling a WebMethod with the class to update data.
Which approach is most standard now (or most practical)? Which one has the best control as well as security? I don't like wizards, and I like to know exactly what's going on, so when something "doesn't go on", I can figure out why without going through a wizard. I want to be efficient with creating forms, so I can create them quickly but still have the flexibility to customize and control what's going on from user interface, to validation, to security.
It sounds like you want something like ASP.NET MVC instead of WebForms. It gives you much more fine-tuned control over the HTML content you produce, but at the same time it has some very flexible and powerful features that make it easy to perform common tasks.
You should look at things like FormView and DetailsView. They work with data source controls like the SqlDataSource control to automatically generate the SQL to interact with the database. No code involved.
If you already have a ASP Classic library, can you not just port that to a .Net library and continue using it. If you have code that works and you are happy with it no need to throw it away just because it might not be exactly the "correct path"
I was once asked in an interview "What is the reason for using C# code inline in an aspx page". I couldn't answer, so I'm curious. Why would you do that instead of using code behind? Is there a technical reason?
For ASP .NET WebForms
It is not a generally recommended practice to write inline code because WebForms make heavy use of “controls” that generate HTML output and presentation logic is expected to be handled by them. For example, to iterate over a data array you would rather use asp:Repeater than foreach loop. Using a loop in this case would smell bad and remind of classic ASP days when markup and code were mixed like a spaghetti. I can only think of using Response.Write inline to output debug messages.
For ASP .NET MVC
It's a totally different situation here. Because MVC discourages using “controls” in favor of clean, hand-coded HTML markup, inline code is the preferred way of generating HTML for model views. Of course, it also depends on what exactly you are doing in the inline code. My rule of thumb is use inline code when all data needed to render the view is made readily available by the controller. Inline code should only contain presentation logic, such as showing or hiding a field based on condition, getting a string from resources, enumerating over an array in the model, etc. You should never talk with the database from the view—this is what controller is for.
Some people don't feel comfortable using inline code in ASP .NET MVC because they have learned that “inline code is bad” when programming WebForms. This is a misconception, and my answer to it is inline code is only bad when it does something other than presentation logic. In WebForms this logic is handled by controls, in MVC—by the inline code, so there is no real problem here.
I'd answer with the stereotypical "it depends"..
I would write inline C# (and frequently do) if it's a pure View concern.
It's a common pattern with MVC applications to do complex display-related stuff by using simple C# in your views..
If the code in question strictly relates to rendering the data onto the page inline C# may very well be the simplest and easiest solution (unless you use WebForms where nothing is simple). If the code is not strictly related to rendering data I'd seperate the rendering part from the processing part and only use the rendering code in the view.
I am just learning C# ASP.NET, when I create a project in visual studio, the login controls and CreateWizard is standard. Do many ADVANCED programmers use these things or do they just build from scratch? If you dont use this as your login method, how are you sure that you will take all the correct security measures of being hacked, sql injection etc etc.? I feel like its easy to use the login controls and createwizard, i couldnt see why anyone else would not use it?
Sometimes it can take more effort to learn how to use these prebuilt controls at the start, but with them you gain the advantage of using proven industry standards, built in validation, etc.
Often a custom solution can overlook possible bugs. The built in controls have likely be more throughly tested then any testing that could be done to any custom controls that are created, with known bugs being well documented and likely already found within the community.
These controls should not be thought of as closed solutions as a lot of these controls are built to be easily extended by the use of the provider patterns (such as the Membership Provider), theming and templates, allowing for custom functionality when needed.
In all my recent projects, I've just created both pages from scratch.
Part of it is that I want more control over how my pages look, and part of it is my mentality where I often find it easier to just do something my way rather than refreshing myself on how those controls work.
By default, ASP.NET pages raise an exception if fields are submitted with HTML codes. However, even this is not an issue. Just make sure you run any user-entered text through HttpUtility.HtmlEncode() whenever you display it on a page.
I am in the process of building a large asp.net Mvc project and have a question regarding the default rendering engine opposed to the MVC Spark engine in the context for designers.
I am all in favour of reducing my tag soup and can see that the spark engine is neat, very neat and I for one would welcome it. However does anyone have an experience/opinions on whether their design team has embraced it or been opposed against it?
My designer team has yet to develop using the Mvc framework so they are either going to have to learn the default or spark engine.
Can anyone comment?
You're design team should not need to have any knowledge of the view engine at all. They should only need to know about the final product from the view engine (i.e. the HTML, CSS and Javascript that is output).
Your designers can make templates from plain old HTML and CSS, without ever seeing a single line of rendering engine code. You just have to tell them the places in the template you are going to inject the content.
The whole point of CSS/HTML templates is to provide separation between the designer and the developer. This allows these templates to be farmed-out to a design shop. You don't want the design shop to have to mess with your development code.
The designer will also be providing you with a set of text styles: h1, h2, h3, p ,etc. You will be able to plug those styles in wherever you need them in the templating code of the rendering engine to achieve the desired effects. If you wish, you can let the designer dictate some rules about the layout and use of these styles, but it's still your job to write the code that renders the output into the designer template.
So to be clear, the designer's job is to create an HTML/CSS template for you (with sample content and styling so that both of you can adequately see the layout). Your job is to incorporate the CSS/HTML the designer provides you into the view engine code.
Spark is just an HTML-ified version of C# (or VB). All other things being equal, Spark would be easier for a designer, because it changes all of the <% { %> things to HTML equivalents. But that assumes that the designers will be writing the template code for the view engine, which they won't be.
I know this question is considered 'answered', but let me answer from a 'designer' (we call it Front-end Developer) perspective.
We have a back-end (C#) team and a front-end (HTML/CSS/Javascript) team that works on .NET MVC Applications. Spark is a much more natural way to do HTML Views. Sparks adds a natural way to do ifs and loops by adding 'if' and 'each' statements as attributes of the HTML element instead of loops outside HTML tags in <% %> tags. Partials are also called from an intuitive manner. <dashboard /> will include the partial "_dashboard.spark".
Spark makes all View markup look like HTML, which I think is very important for Maintainability. It also forces good MVC habits by keeping as much logic as possible out of the View markup. The design team and create the HTML markup and the developers can then add the little bit of logic to get the content generation going.
With Spark, we have minimized the issue of ugly code and have kept front-end and back-end work separate, yet still fluid and maintainable.
I don't think designer like use Spark.
It too complicate to use and mix some logic, variable definition.
Designer should not know any programming language.
I prefer use Velocity View Engine (VTL), this is simply to use and can force programmer to separate logic from front end.