At my current job we have a CMS system that is .NET/SQL Server based. While customizing a couple of the modules for some internal use, I was a little surprised to see that instead of having APIs that returned data via your typical result set that was bound to a DataGrid/DataList/Repeater control, that the APIs returned an XML node/collection, that was then passed to an XSLT transformation and rendered on the page that way.
What are the benefits to using a model like this?
Using XSLT transformations would enable you to use a different layout and formatting than the standard .Net grid controls. Some people don't approve of using the .Net grids because they can include more HTML than necessary, and because if not managed carefully, they can bloat ViewState.
There was a recent discussion here about the .Net grids being bloatware (but developers use them anyway).
The outputted pages can be of any type, like html, php, etc.
By setting up the datasource and xml that the page merely transforms, you have also instantly created a simple 'web service' that can be consumed by other software. For example, it would be trivial to turn that grid into an rss feed or write a program to scrape that data periodically and send a more pressing alert.
The XSLT method is very MVC, unit-testing, separate-concerns friendly where ASP.NET controls well... aren't.
caveat: I reject the assumption that MS can write better html/css/js than I can. ASP.NET controls are clunky abominations.
Related
I'm getting ready to be responsible for leading the development of a small ASP.net MVC application. This is my first time creating an MVC application, so I am excited!
I've carefully read over the documentation and I feel like I have the general idea of how MVC works. However, if I understand correctly, server controls (like GridView, for instance) are not part of MVC.
My question is: Why? At my development shop, I'm so used to using controls like GridView and the MS Chart Controls that I'm almost at a complete loss as to developing without them. It seems almost like starting over.
Why are the server controls unavailable? How does Microsoft expect me to work without them? What are the alternatives?
My question is: Why?
Because most of them depend on things like ViewState and the Postback models which are part of the classic WebForms model and no longer exist in ASP.NET MVC. Those server side controls rely on events that will perform postbacks to the server persisting their state in hidden fields (ViewState). In ASP.NET MVC you no longer work with events such as Button1_Click. In ASP.NET MVC you work with a Model, a Controller and View. The Controller is responsible for receiving user requests, querying the Model, translating the results into a view model and passing this view model to the View whose responsibility is to display it under some form.
In ASP.NET MVC there are HTML helpers that could be used to generate some reusable HTML fragments between views. You may take a look for example at the Telerik ASP.NET MVC suite of such helpers. They call them controls but they have nothing to do with classic WebForms server side controls. They are just HTML helpers.
Basically classic WebForms are a leaky abstraction of the web. What Microsoft did back in the time when they designed this framework was to bring existing Windows developer skills to the web which was getting more and more momentum. But since the web was still a new technology that most developers weren't yet familiar with, they created this abstraction to hide away the way that the www works. Those developers were accustomed to drag and dropping controls on their Windows Forms, double clicking on buttons that was generating some code for them in which they put their data access logic and so on. This model was transposed to web application development thanks to WebForms. The HTTP protocol was successfully hidden behind this abstraction called WebForms. For example you don't need to know HTML, nor Javascript, not even CSS in order to create a website using WebForms which is really great because the framework abstracts all those things for you. Unfortunately by doing so it prevents you from easily utilizing the full power of lower level web technologies which some people might need when developing web applications.
What ASP.NET MVC does is basically remove this leaky abstraction and bring the www to the developers the way it was intended to be by its creators. ASP.NET MVC is not mature enough compared to classic WebForms so you cannot expect to find the same range of available controls and widgets but things are slowly shifting.
I would recommend you start here with ASP.NET MVC: http://asp.net/mvc. Go ahead, watch the videos, play around with the samples and see if ASP.NET MVC is for you or not. And of course if you encounter some specific difficulty or question don't hesitate to come back here and ask it.
I'm so used to using controls like GridView and the MS Chart Controls that I'm almost at a complete loss as to developing without them. It seems almost like starting over.
In this case, starting over is good.
I've gone through a similar journey. If straight HTML scares you, try working with the System.Web.UI.HtmlControls namespace. This will allow you access to standard HTML controls, but you'll still have the comfort of turning them into server controls if you need to (either by specifying the runat="server" attribute, or by converting them into equivalent ASP.NET controls.
In addition to Darin's answer, there's another problem with ASP.NET: you're bound to Microsoft's view of the web. That GridView you love? It's generating bad HTML. The Paging controls it provides? Even worse. Even if you know very little about HTML compliance, nested tables should give you the chills. In a way, everyone who uses a GridView is lucky that legacy web supported by Microsoft (and to a lesser degree, Google and Mozilla) came from such a god awful starting point.
Finally, to summarize: my suggestion is that you try to rewrite your pages or develop new web applications (as best as you can) using HtmlControls only. You'll probably have to learn some JavaScript/jQuery, and might have to venture into the world of AJAX to make your controls operate the way you want them to.
Use this as a stepping stone into the world of MVC. You won't use the same technologies (and may drop a lot of JavaScript/jQuery), but it will help you change the way you think about web development in much smaller, and perhaps easier-to-absorb chunks.
Ultimately, however much you like your ASP.NET controls, you'll have a much greater degree of freedom, and you'll also be developing websites that make use of newer technologies, which will provide added value to your websites.
At the core of this is Model View Controller (MVC) which promotes decoupling. The idea is that you feed your View (web page) a Model with all the data that it needs to be rendered. Server controls are tightly coupled. There is no concept of state in MVC or 'should' be no concept anyways.
That's kind of the point of MVC. It takes away the high level of UI abstraction that server controls provided and leaves you with html and javascript. (It also adds some really cool model binding features)
I am new to MVC and have found using Partial Views to be similar in creating small, reusable UI elements that do not fit into the _Layout. For example, sliders, slideshows, navigation, featured sections although you can use #section for this I find partial views to be more beneficial. This concept enables me to create reusable libraries that I can switch out easily and use in other projects. To me this is similar to controls, although there is a debate both for and against this analogy.
I'm feeling a bit lost with my question about HTML5 code generation, and despite having put some efforts into my research I don't really feel much wiser.
I use VS2010 for the creation of ASP.NET pages, and I do know that there is an (unofficial) "Web Standards Update" for VS2010 SP1. Using this update I can change the settings of the "Target Schema for Validation" in the ASPX editor window to HTML5. The new elements / tags and semantics are then available via Intellisense, and I can nicely code away manually using all the fancy new stuff.
What I don't understand is how to get something like the ASP.NET controls to generate HTML5 code (where it makes sense). Is this at all possible or am I completely going in the wrong direction here? I would have expected that I do not have to "hand code" HTML5 as long as I use the existing controls (which tend to generate a lot of JavaScript in the background when the page is delivered to the client's browser).
Thanks in advance for a clarifying answer
G.
Some controls generate slightly different dialects of HTML based on the particular User-Agent. However, not all of them know about HTML 5 yet, and there's no specific property to enable HTML 5 generation, just as there isn't a property to enable other dialects of HTML.
If you want to generate HTML 5, you can do one of three things:
Create a new control that overrides the existing one, and either use it directly or replace the original with it everywhere in your app with tag mapping
Create a control adapter and modify the control's output as it's generated
Create a custom control
The controls you are referring in ASP.NET are what is commonly known as "webforms". They are basically server side controls that generates the javascript code needed to postback the data to the server, mantain the state of the controls between postbacks, and stuff like that. As you said, those controls generate too much code and a excessive number of roundtrips to the server, so it is not very recommended to use webforms.
HTML5 is mainly client side, so it has very little to do with the webforms server controls. It's a different approach than the old ASP.NET webforms. Because of this, ASP.NET is including on its newer versions the MVC framework, the razor engine, JQuery and another javascriprt libraries. MVC includes some helper classes and templates that helps you generating the client code, and many other features to support HTML5 enabled webs. So, I would recommend to start reading about it.
Anyway, now that jquery is fully integrated in Visual Studio, javascript coding is not so difficult.
In my application, I have a situation wherein the users will need to have the flexibility to customize the UI to a certain extent. The following are some of the customizations that is being discussed now...
Change Label text associated with the with Use Input controls
Mark a control as Mandatory/Read only/Hidden
Assign a regular expression for the text box
Are there any recommended design patterns for my situation? Seems like I need to store all these in a database and worried about the performance impact if I have to read every element from the database for every page.
Thanks,
Harsha
I would look at some of the open-source CMS or portal systems written in ASP.NET and see how they are doing UI customization (if they are).
Phil Haack has some insight at the following article:
Scripting ASP.NET MVC Views Stored In The Database
http://haacked.com/archive/2009/04/22/scripted-db-views.aspx
Apparently it's not an easy thing to do in ASP.NET. It's easier to do in ASP.NET MVC, because the markup is cleaner and you can control it with jQuery.
The overall concept you are going for is not easy to have system wide, however the specifics you stated are fairly easy.
You'd have to setup some fields in a database for those values and then on the page load set those values on the page load. Pretty trivial from a 'how to'. Which your question shows that you 'get'.
Now unless you are using an Access Database :-), I don't think you have to worry about the performance hit. But if truly concerned, put some caching logic on those values so you only have to hit the database once. Though, be aware this will store the values in memory on the server, so if you are working with a very minimal hardware this could be an issue as well.
I'm struggling with a few in-house developers that are creating some web apps in VS 2008 using C#.
It appears that the native tools and components in VS 2008 are not being nice about creating Web Standard code.
For example, the navigation component creates items in its own table structure.
Is there anyway to make a web project from Visual Studio create nice, clean, browser friendly code?
You can use CSS Friendly Control Adapters to alter the output of the current ASP.NET controls. It's easy to set up and you don't have to change any existing source code.
If you're bound to ASP.NET WinForms, you could create you own set of controls or use 3rd party controls. There is also a XHTML configuration setting you could set to Strict, so that the controls try to render more valid core.
When you really want to write nice, clean, browser friendly code, you could take a look at ASP.NET MVC. ASP.NET MVC gives you complete control of the output, but that means you have to do all the things WinForms currently does for you, yourself...
Certainly. If a component doesn't produce markup you like, then you don't use it. It's just that simple.
Having said that, be sure to check out Visual Studio 2010 beta 1 to see if your issues have been addressed. If they haven't, then you get to complain about them in a way that might get them fixed.
VS 2008 web projects don't do anything web-standards-unfriendly. The standard ASP.NET controls (like the menu control you mentioned)? That's another story -- some use a mess of tables and javascript to do their thing.
The good news? You can use what you want of ASP.NET without having to use those controls if you don't want to.
Go MVC !!! you will have complete controle over your UI
My two cents: machine-generated code is almost never as standards-compliant as the code I write by hand, especially when you get into fancy widgets and whatnot. The obvious trade off is that writing code by hand can be tedious and time-consuming.
We've come a long ways since the dark ages of code-junk that frontpage or dreamweaver used to spit out, but even still...
In the end, your code is only ever as good as your programmers.
The Web Projects themselves are simply containers for the code that you create and a mechanism for managing and building the compiled project.
Based on my experience, the controls generated by VS comply to web standards ... that being said, browsers differ on which standards they do or do not enforce and how they enforce them. For the most part, you have a high level of control of the HTML that is output from your page. The table structure generted by the navigation control id valid HTML - you may be wanting to avoid the use of tables in which case, that particular control might not be for you.
For the most part, when you have a complex control you will need to take what you get - the HTML that is generated may not be intuitive to you and your team but that is often the price paid for the time savings gained by using a pre-built control, particularly one that is intended to service the needs of a wide variety of uses. (The same can be said for most code/script libraries you use/buy/find)
Many controls offer templating that provides you with the ability to define a template for how the resultant HTML is generated.
If you want cleaner markup, you have a few options:
a) Check out the CSS Friendly control adapters from codeplex. They help alot with certain controls.
b) Avoid the more complex server controls. There is very little one can't do nearly as effectively with a repeater and some user controls that one can't do with most any databound control for instance.
c) Try ASP.NET MVC. No neato server controls to do UI lifting, but it will let you make very, very clean UIs.
I have an ASP.NET web site dedicated to reporting on PBX extension stats. It comprises many report pages, with HTML generated almost purely by code-behind (setting a Label control's Text property instead of using Response.Write), using un-parameterised string literal SQL queries that populate By Reference DataTable parameters.
Maintenance pages at least comprise DataGrids and detail forms, but use the same DAL, on e thing for which can be said is that it supports multiple DB servers, with sub-classes each overriding these access methods with their own string literal queries.
What do I need to consider cleaning up this mess? I've already made an almost obvious decision to use a third party reporting solution, and move the queries to stored procs in their respective DB languages, narrowing the diversity of the different DAL classes, and to separate CSS out to shared files, as lots of it is very hidden in C# files!
For your back-end design, I suggest having a class to represent each main table of your database (i.e. a Report class and a User class, for example). Anything that's not an event handler should go in the back-end class files / namespace.
For your GUI, looks like you're on the right track using ASP.NET controls instead of just streaming your data out to the user. However, you may consider objectifying the areas of the page. For example, one of my favorite tricks is to open semitransparent "popup" panels when requiring user input or a something like the Information Bar when displaying a short message.
Consider AJAX and the AJAX Control Toolkit. It's easy to implement (especially in the case of a rewrite) and provides great flexibility. Specifically, I've found Accordions - sometimes even nested within other Accordions - are excellent at organizing overabundances of information.
Edit:
Note that if you were to use AJAX, you basically can't even consider using response.write anymore.
As far as having too much content on the screen, remember Panels have a "Scrollbar" property and DIVs don't without some heavy changes.
Also, I tend to separate my code files by Namespace; but the popular trend is to do so by Class. This is a better option if you have many Developers or if it's likely several classes within a namespace will be checked out or simultaneously modified by different people.
I would consider ditching any custom written DAL and use one of:
iBATIS.NET
NHibernate
SubSonic
You might even end up dropping sprocs entirely.
If you're daring you could try the redesign using Microsoft's MVC implementation.
Whatever approach you take, make sure you write unit tests prior to refactoring any code, verify the tests pass before and after refactoring.