 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / General / December 2007Controls v HTML
I come from a classic asp background, but have started using ASP.NET about 12 months ago, but I'm still not sure about the pros and cons of using controls v HTML spat out from code as you would in classic asp. I have also been using System.Web.UI.ICallbackEventHandler to send data to the server and back without using controls. What I want to know is the pros and cons of each. To me you never have quite the freedom using a control as you do manipulating html and spitting it out, but it can be quicker using a control for more simple jobs. what are the performance issues? What have other classic asp users found to be best when using asp.net? >I come from a classic asp background, but have started using ASP.NET about >12 months ago, but I'm still not sure about the pros and cons of using >controls v HTML spat out from code as you would in classic asp. I have also >been using System.Web.UI.ICallbackEventHandler to send data to the server >and back without using controls. The advantages of controls like DataGrid and the like is that it's simply faster/easier to get data from your back end onto your front end. The advantages of controls like repeaters and the like is that you can get that 'ideal' separation of presentation on the front (.aspx) end with logic on the back end (.vb/cs files) The disadvantages of the built in web controls...ESPECIALLY in 1.1, was that the HTML, for the most part, sucked. It wasn't very semantic and often invalid. So, I got in the habit of using a lot of stringwriters ala classic ASP. I'm now trying ot break myself of that habit as I move into 2.0 ;o) > What I want to know is the pros and cons of each. To me you never have > quite the freedom using a control as you do manipulating html and spitting > it out, but it can be quicker using a control for more simple jobs. that's pretty much it. Even the 2.0 controls are somewhat limited. Ie, a datagrid is really easy to set up to allow the viewing and editing of content from one table. But once you start getting into manipulating data across tables via joins and the like, then the datagrid becomes rather complex to deal with. > What have other classic asp users found to be best when using asp.net? IMHO, if you are willing to embrace the entire concept of OOP development, then do it, and go with ASP.net. If you prefer the ASP 'lifestyle' then consider migrating to PHP, as that is closer in methedology. -Darrel > >I come from a classic asp background, but have started using ASP.NET > >about 12 months ago, but I'm still not sure about the pros and cons of [quoted text clipped - 16 lines] > > I'm now trying ot break myself of that habit as I move into 2.0 ;o) Same here. But sometimes it just easier to spit out html from script than fiddle with a control for hours and find that you can't get it to do what you want properly. >> What I want to know is the pros and cons of each. To me you never have >> quite the freedom using a control as you do manipulating html and [quoted text clipped - 13 lines] > then do it, and go with ASP.net. If you prefer the ASP 'lifestyle' then > consider migrating to PHP, as that is closer in methedology. I have tried php, I found it messy and cumbersome. There is a lot I like about ASP.NET. The main problem seems to be too many choices and wasting time following the wrong choice for a few hours then changing your approach, I guess this will improve with experience > -Darrel I doubt there are any real performance issues, everything gets spit out to the response output stream anyway, whether you do it "manually" or let a control do it by responding to its Render method from the Page class. I've seen developers coming from a classic ASP (and so did I) environment who just refuse to accept progress and do everything the "old way". I would suggest you change your mindset to the concept of ASP.NET controls - and even consider writing some of your own CustomControls along the way. If you run into a situation where you just absolutely cannot figure out how to make the ASP.NET Controls on the Toolbox do what you need, you can always fall back to building strings of HTML with a StringBuilder and attaching the output HTML to a placeholder or HtmlGeneric("div") control's InnerHTML property. Peter  SignatureRecursion: see Recursion site: http://www.eggheadcafe.com unBlog: http://petesbloggerama.blogspot.com BlogMetaFinder: http://www.blogmetafinder.com > I come from a classic asp background, but have started using ASP.NET about > 12 months ago, but I'm still not sure about the pros and cons of using [quoted text clipped - 9 lines] > > What have other classic asp users found to be best when using asp.net? Yes I am trying to use controls where I can , but spit out html when it needs that bit extra. I have also been using System.Web.UI.ICallbackEventHandler to send data back and forward to the server manually, this works very well, there no reload at all, even Ajax gives a flicker here and there but using System.Web.UI.ICallbackEventHandler there is absolutely no reload, but I have found bugs such as you can not use the "i" as a variable in your loops, it also dose not like functions that return Boolean values. I don't seem to find much documentation on this approach or have I found anyone else that uses it, I wonder if there is not any other bugs or problems with it. >I doubt there are any real performance issues, everything gets spit out to > the response output stream anyway, whether you do it "manually" or let a [quoted text clipped - 35 lines] >> >> What have other classic asp users found to be best when using asp.net? The answer really depends on what your career is. If you are a professional developer, and plan to remain one, embrace and master object-oriented programming, learn how to employ the power of OOP and good object-oriented design and architecture patterns and practices, and expect to take a good long time doing so. In the long run, you'll be much better off, write software that is powerful, secure, easy to maintain and extend, and get much more done in much less time. If on the other hand, you are a hobbyist, it is entirely up to you whether you want to go to all that trouble. SignatureHTH, Kevin Spencer Microsoft MVP DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net >I come from a classic asp background, but have started using ASP.NET about >12 months ago, but I'm still not sure about the pros and cons of using [quoted text clipped - 9 lines] > > What have other classic asp users found to be best when using asp.net? > The answer really depends on what your career is. If you are a professional > developer, and plan to remain one, embrace and master object-oriented [quoted text clipped - 30 lines] > > - Show quoted text - I am inclined to agree with much of what has been said about embracing ASP.NET I have never used ASP but one thing has stood out for me in using ASP.NET is that it remains just as important to know HTML thoroughly. Microsoft did not try to hide HTML from the developer with ASP.NET rather they introduced a powerful set of tools for server-side programming that communicates with the client in a W3C compliant fashion but still supports traditional HTML in the source pages. Web server controls, such as labels, hyperlinks and images are embedded inside traditional tags but enable programmatic control of content where needed. The two technologies complement one another very well. As for migrating from ASP, even though I lack experience it seems obvious to me that it is best left behind altogether and not to try and "adapt" the new technology to the old, which will only obscure the advantages of the newer methodologies. OOP is not the same as using controls. I am a big believer in OOP. But I'm not sure that using controls is superior to spitting out html. My query is not ASP v ASP.NET it is Controls v spitting out html >> The answer really depends on what your career is. If you are a >> professional [quoted text clipped - 55 lines] > and "adapt" the new technology to the old, which will only obscure the > advantages of the newer methodologies. -Easier to reuse Your next best option to reuse code that spits out dynamic HTML would be to create a subscript. If you were to create a subscript that does what the GridView control does, it would have more parameters than would be worth dealing with. -OOP benefits What Kevin Spencer means is that you work with controls programmatically in an OOP fashion. A control gives you events, methods, and properties for interacting with it to make your code more organized. A control is really an object, so using a control is using OOP. -IDE integration You can work with controls graphically at design time, whether they are user controls or server controls (assuming the server control code has appropriate attributes and a ControlDesigner). One who works primarily with ASP.net may take controls for granted, but programmers of more procedural languages who understand ASP.net controls sometimes envy you. http://php.net/dotnet (that's for the PHP programmers who haven't discovered the value of those RAD frameworks for PHP) -Michael Placentra II > OOP is not the same as using controls. > > I am a big believer in OOP. But I'm not sure that using controls is superior > to spitting out html. My query is not ASP v ASP.NET it is Controls v > spitting out html > -Easier to reuse > Your next best option to reuse code that spits out dynamic HTML > would be to create a subscript. If you were to create a subscript that > does what the GridView control does, it would have more parameters > than would be worth dealing with. yes I agree that using controls in some circumstances is a good thing, but in many more complex cases it seems easier to use html. Using the System.Web.UI.ICallbackEventHandler you can talk to the server from client script and any html element can not do as any asp.net control. > -OOP benefits > What Kevin Spencer means is that you work with controls > programmatically in an OOP fashion. A control gives you events, > methods, and properties for interacting with it to make your code more > organized. A control is really an object, so using a control is using > OOP. for that matter a html elements is a object, What my point was, was that not using asp.net controls is not to say that you are not using OOP. the making of classes and creating instances of them is OOP. > -IDE integration > You can work with controls graphically at design time, whether [quoted text clipped - 11 lines] > > -Michael Placentra II As for controls I think as I have stated above, they are good for many occasions but can not be manipulated to the extent as you can with spitting out html One thing I would like to know is more about the pros and cons of using System.Web.UI.ICallbackEventHandler to manually talk to the server from JavaScript >> OOP is not the same as using controls. >> >> I am a big believer in OOP. But I'm not sure that using controls is >> superior >> to spitting out html. My query is not ASP v ASP.NET it is Controls v >> spitting out html > yes I agree that using controls in some circumstances is a good thing, but > in many more complex cases it seems easier to use html. Using the > System.Web.UI.ICallbackEventHandler you can talk to the server from client > script and any html element can not do as any asp.net control. Are you saying that you can't manipulate the resulting HTML of controls with JavaScript? You can retrieve the client ID from a server control before it is outputted and inject it into your JavaScript, and you would be able to work with that if you have some AJAXing to do. Microsoft has an ASP.net AJAX framework ( http://asp.net/ajax/ ). This really should cover most of your AJAX needs. I don't understand how or why you want to compare controls with manual AJAX, because the controls (other than Atlas controls or ASP.net AJAX controls or others that do what you're talking about doing) don't replace your AJAX code. You can create controls that use ICallbackEventHandler, and you can manipulate the resulting code from controls with manual AJAX, but other than that I don't see the point in this comparison. > > -OOP benefits > > What Kevin Spencer means is that you work with controls [quoted text clipped - 3 lines] > > OOP. > for that matter a html elements is a object, When you manipulate an HTML element (with runat="server") as an object in your ASP.net code, it has become an (HTML) control anyway, so I agree that HTML elements can be objects on the server side. But what you're talking about is not utilizing the features of a control, but rather generating the HTML yourself. OOP goes with controls because a control is a class (look at a server controls tutorial). HTML elements become an HtmlGenericControl. When you create a .ascx user control, the class is created for you. When you type <asp:Literal ... />, the instance of the control is created for you. You are also using OOP when you work with them from your server code, I.E. Literal1.Text = ... > What my point was, was that not using asp.net controls is not to say that > you are not using OOP. the making of classes and creating instances of them > is OOP. People don't (shouldn't) just use OOP because it makes you cool to be using it, it's good because it forces programmers to follow some rules of a project, allows new design patterns, and keeps your code more organized, among other benefits. Whether or not you can say you are using OOP is not the issue. The reason OOP is worth pointing out here is because you get to use it on the server when you use controls. You aren't benefiting from saying that you are using HTML therefore DOM therefore OOP, because that's not doing you any good on the server side. It helps you a little in JavaScript, but using controls isn't going to take that away from you. > As for controls I think as I have stated above, they are good for many > occasions but can not be manipulated to the extent as you can with spitting > out html If you are the author of the control, you can manipulate the HTML quite a bit. I can see what you mean if you want to create a section of HTML that contains a large amount of unrelated things, but in that case you should consider dividing it into more specific functions and creating multiple controls. > One thing I would like to know is more about the pros and cons of using > System.Web.UI.ICallbackEventHandler to manually talk to the server from > JavaScript As opposed to the lower level AJAX JavaScript things? Well, it saves you a lot of time because you don't have to write more code for each browsers' differences. It's more cumbersome than using an ASP.net AJAX framework UpdatePanel control if all you're doing is updating a table, though. Good luck with everything, -Michael Placentra II >> yes I agree that using controls in some circumstances is a good thing, >> but [quoted text clipped - 7 lines] > control before it is outputted and inject it into your JavaScript, and > you would be able to work with that if you have some AJAXing to do. It would be easier to just spit out html > Microsoft has an ASP.net AJAX framework ( http://asp.net/ajax/ ). This > really should cover most of your AJAX needs. I don't understand how or [quoted text clipped - 4 lines] > manipulate the resulting code from controls with manual AJAX, but > other than that I don't see the point in this comparison. Because you can have more control of what you are doing with manual callbacks. for instance when you click on a button you may want to make more controls on the fly, that in return have events, than in return create more controls on the fly that also have events. I tried to do this and found than after asking for advice over and over on this group the best advice I got was to spit out html to do it. From there I was able to use JavaScript events to do manual callbacks. using asp.net controls I was only able to attach events to the controls made on the fly after they were loaded and their events would only fire the second time they were clicked. >> > -OOP benefits >> > What Kevin Spencer means is that you work with controls [quoted text clipped - 15 lines] > when you work with them from your server code, I.E. Literal1.Text > = ... Each html element is a object with methods and properties there is little difference there. but I think we are getting off topic, My point is that controls don't always do as you want, sometimes there are very quick and do the job well, some times you spend so much time fiddling with they to get what you want, I find it better to create what you want by spitting html. I tend to design my database well so that each table or group of tables represents a object and following the relation ships of the database I can navigate though my objects to get what data I need. For example a customer object would represent a customer table in the DB. Each instance of the object would be a record of that table, that customer record can in turn call a invoice object that would represent a linked invoice table. This I used to do in Classic ASP using COM+. To think that OOP is something new to Classic ASP developers is not so, although not all asp developers may take such a approach. To me this is the real Idea of OOP is to make each entity a Object with properties and methods and collections. Properties usually relate to the fields of the table the object represents, methods usually change the the data and collections hold child objects that represent child table records. >> What my point was, was that not using asp.net controls is not to say that >> you are not using OOP. the making of classes and creating instances of [quoted text clipped - 11 lines] > side. It helps you a little in JavaScript, but using controls isn't > going to take that away from you. See above >> As for controls I think as I have stated above, they are good for many >> occasions but can not be manipulated to the extent as you can with [quoted text clipped - 6 lines] > case you should consider dividing it into more specific functions and > creating multiple controls. How the data is presented is just that presentation, using the asp.net controls to connect strait to the database is fine, but to really follow OOP principles I refer to my rant above, knowing the entities in your solution and representing them as objects usually with a normalized relational database as a backend is the real objecting of OOP and how you present the data to the front end is not so important. Using a object to present data is not what I would call OOP, I would call that using objects but not OOP. >> One thing I would like to know is more about the pros and cons of using >> System.Web.UI.ICallbackEventHandler to manually talk to the server from [quoted text clipped - 3 lines] > you a lot of time because you don't have to write more code for each > browsers' differences. I atgree there It's more cumbersome than using an ASP.net AJAX > framework UpdatePanel control if all you're doing is updating a table, > though. Here I disagree, it really isn't so much to do, and making a web site Ajax enabled is a bit of a hassle also. I like to use manual callbacks but what I am worried about is some unknown bugs or limitations as I can find so little info on the concept > Good luck with everything, > -Michael Placentra II "[Writing manual callbacks] really isn't so much to do, and making a web site Ajax enabled is a bit of a hassle also. I like to use manual callbacks but what I am worried about is some unknown bugs or limitations as I can find so little info on the concept" I would not bother writing a callback for updating a table (refreshing from a data source or inserting with a FormView) if I can do that with pure drag-n-drop and property editing. Those opportunities to get something done very quickly are the reasons I choose to use ASP.net when I do. When you can already recognize those instances where manual callbacks are necessary, there shouldn't be an issue of Controls v HTML. I'm not advocating using controls in all cases, but I'm trying to describe why controls are useful so you can determine for yourself when they apply to your situation. Your original post and title say that you want information on when to use controls versus when to use directly code-generated HTML with manual callbacks, accounting for performance and similar crossover experiences. You seem to have that already, would you like answers to any more related questions? -Michael Placentra II <snip> > Each html element is a object with methods and properties there is little > difference there. but I think we are getting off topic, My point is that [quoted text clipped - 14 lines] > object represents, methods usually change the the data and collections > hold child objects that represent child table records. <snip> First, you don't seem to understand the difference between pseudo-object-oriented programming technology and true object-oriented programming technology, and the difference is significant. For example, true OOP employs inheritance, which is a powerful tool for obtaining code maintainability and reusability. True OOP also includes encapsulation, which enables objects to fully control access to their members. There are many other aspects of OOP, the .Net platform, and managed code and languages that make it extremely powerful and productivity-oriented. In addition, there is more to ASP.Net than the programming platform it is written on. ASP.Net has a structure that is very powerful and enhances productivity immensely when it is fully-leveraged. This structure, and the power of OOP come at a cost. It is not something one can easily or quickly master. It requires an up-front investment of time in study and practice. Such abstractions as the Provider Pattern and various other patterns and practices can, over time, enable a developer to perform twice the work in half the time, to produce solid, reusable, easily-maintainable software that requires much less maintenance, and is much more reliable than software written using classic ASP and COM. These claims are not matters of speculation. They are supported by a large volume of work which has been done by many developers using the technology over a number of years, including my own. I have used ASP.Net since it first emerged, in fact, since it was in its' initial version beta. And from my own experience, it took me years to fully realize and leverage its' power. That is not something which can be done by reading some Getting Started articles, Quick Starts, and tutorials. That said, a developer has to make a living. One has to produce something to make a living. The art of programming entails a constant process of compromise, between what can potentially be accomplished with unlimited time and resources, and what can actually be done with limited time and resources. I have never been able to create the perfect software, nor to take advantage of every possible benefit available in a technology in doing so, although I have learned to work as much more and sleep as much less as I possibly can. The "fish or cut bait" moment looms ominously in every project. Most projects, and the prospect of learning many new technologies often reminds me of an elephant that needs to be eaten. To think about eating the entire elephant is highly likely to prevent one from taking the first bite. But perfection is not something to be attained; it is something to be approached. Regardless of whether or not it is impossible to eat an elephant, it is certainly possible to begin to eat one. The process of eating is simply an iterative process of taking one bite at a time. Taking a single bite of anything is a trivial task. In conclusion, my aim is not to discourage. The question here, of whether to use Controls, or to simply output HTML, is not an ultimate issue. It may be a pragmatic issue for the time being, depending on one's circumstances. In other words, it is a decision to be made for the present situation, and need not have any influence on future decisions. Each bite is taken in the time frame of that bite. Each development decision is made in the time frame of that project. A developer's technique evolves over time, as the developer learns and practices the art. So, if it seems inconvenient to use any or all of the ASP.Net suite of tools and technologies (in this case), if one feels that it is necessary to forego the employment of some seemingly intimidating (at the moment) process in the interest of getting the current job done, this is what one must decide. That decision may be for the best at any given time, and as a matter of practical experience, it is a decision which we all must continue to make for just about any project, for the length of our careers. SignatureHTH, Kevin Spencer Microsoft MVP DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net > <snip> >> Each html element is a object with methods and properties there is little [quoted text clipped - 25 lines] > many other aspects of OOP, the .Net platform, and managed code and > languages that make it extremely powerful and productivity-oriented. I have been developing with OOP for quite a long time, I am familiar with inherited abstract and polymorphous. I am familer with OOP in java ASP.NET and C++ > In addition, there is more to ASP.Net than the programming platform it is > written on. ASP.Net has a structure that is very powerful and enhances [quoted text clipped - 6 lines] > that requires much less maintenance, and is much more reliable than > software written using classic ASP and COM. It would seem to be new to you, but OOP is been around for longer than Dot.Net and is not the relient on using controls as you seem to state in your first post. > These claims are not matters of speculation. They are supported by a large > volume of work which has been done by many developers using the technology [quoted text clipped - 22 lines] > eating is simply an iterative process of taking one bite at a time. Taking > a single bite of anything is a trivial task. Well put > In conclusion, my aim is not to discourage. The question here, of whether > to use Controls, or to simply output HTML, is not an ultimate issue. It [quoted text clipped - 13 lines] > continue to make for just about any project, for the length of our > careers. I hardly see controls as intimidating, but clumsy, like many attempts at making things easier, they make themselves less flexible. <snip> > I hardly see controls as intimidating, but clumsy, like many attempts at > making things easier, they make themselves less flexible. <snip> Whatever your perception of ASP.Net Controls is, it is due to your unfamiliarity with them, and with your unfamiliarity with the ASP.Net programming paradigm. When used correctly, ASP.Net Controls do whatever you want them to do, and very well. Remember that ASP.Net Controls are not confined to the built-in set of WebControls and HtmlControls that comes with the Framework, nor are they limited to those plus User Controls. In fact, the ASP.Net platform is designed with the idea in mind that you can and will create custom Controls when needed. HTML elements in a web page are not necessarily unrelated to one another, especially when they are interactive. They are more like parts that can be combined to perform various tasks, much like the various combinations of carpentry construction materials are combined to build various types of buildings, and rooms in buildings. A server-side web application takes this a step further, in that there are also "parts" on the server that provide business logic, and "parts" that provide a user interface in the form of an HTML document. These business logic and UI logic parts comprise the actual application, while the HTML document, with the sum of its parts, comprises a UI that communicates transparently with the actual application on the server. Remember that your original question was with regards to whether or not it was better to employ Controls, or just "spit out HTML." Well, that is exactly what Controls do. However, they are object-oriented, encapsulated, and modular, which makes them superior to any procedural and/or non-modular way of creating the various fragments of HTML markup that make up a document. In essence, System.Web.UI.Page is a Control that represents an HTML document. It modelled after the HTML document object model, in that, like an HTML document, it is a container for other Controls, just as an HTML document is a container for other HTML elements. The ASP.Net object model leverages the organizational and modular characteristic of the HTML document object model to provide a similar server-side set of objects that are self-contained and self-rendering. Since the HTML document object model is not simply raw text, but a set of encapsulated elements with various properties and functionality, it is best to create server-side objects that do not treat the HTML in the page as raw text, but as a set of encapsulated elements with various properties and functionality. Yes, it is true that it is raw text that is interpreted by the browser to render these elements, but in fact, even the browser simply parses the text and builds an in-memory object hierarchy to work with. Once the raw text has been parsed, it is ignored by the browser. ASP.Net hides the raw text from the developer, giving the developer instead an object model that closely resembles the resultant client-side model. SignatureHTH, Kevin Spencer Microsoft MVP DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net > <snip> >> I hardly see controls as intimidating, but clumsy, like many attempts at [quoted text clipped - 5 lines] > programming paradigm. When used correctly, ASP.Net Controls do whatever > you want them to do, and very well. no they don't, I think the tasks you are doing may be very basic. In some occasions you may not even know the amount of data, number of fields, data types you will need to display, controls can not handle this well and present the data formatted correctly on the fly. Some times condition statements may be needed to decide when to display, make a calculation or separate the data from one column to 2. Controls can not handle this well. IOn these cases it is far more productive to use html <snip> >> Whatever your perception of ASP.Net Controls is, it is due to your >> unfamiliarity with them, and with your unfamiliarity with the ASP.Net >> programming paradigm. When used correctly, ASP.Net Controls do whatever >> you want them to do, and very well. > > no they don't, I think the tasks you are doing may be very basic. <snip> I've been doing ASP.Net since the first beta version came out, and I've done just about everything with ASP.Net that can be done with it, except for Ajax. I've built a large number of web sites with it, Controls that interact with SWFs that interact with Web Services that I've built, HttpHandlers for a variety of purposes, member- and role-based portals that have database back-ends, database interfaces, Controls that render images and charts, Controls that use XSLT to create HTML from serialized sets of custom classes, Controls that render JavaScript, so much stuff that I don't remember some of it. Over the years, I've learned to use Controls more, not less, by experience and research. I have a large personal library of custom Controls that I have previously built, and employ in projects that come up. That said, you don't have to believe me. The information I've provided was for your benefit, not mine. Someday it may be useful to you, if not today. SignatureHTH, Kevin Spencer Microsoft MVP DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net > <snip> >>> Whatever your perception of ASP.Net Controls is, it is due to your [quoted text clipped - 21 lines] > That said, you don't have to believe me. The information I've provided was > for your benefit, not mine. Someday it may be useful to you, if not today. I believe you are very capable, but I don't agree that controls are as flexible as spitting out html. You did not comment on the scenarios I put forward, remembering that the ability to do something is not the point, it is if it is practice to do so. "In some occasions you may not even know the amount of data, number of fields, data types you will need to display, controls can not handle this well and present the data formatted correctly on the fly. Some times condition statements may be needed to decide when to display, make a calculation or separate the data from one column to 2. Controls can not handle this well. In these cases it is far more productive to use html" > ... You [Kevin Spencer] did not comment... > "In some occasions you may not even know the amount of data, number of [quoted text clipped - 3 lines] > calculation or separate the data from one column to 2. Controls can not > handle this well. In these cases it is far more productive to use html" /ThatsIT.net.au/, I'm not convinced that you realize what a control is. You can do (just about) anything you can do in your regular code in a control, unless your regular code is extremely messy and it would not worth getting your variables and data into the control. Again, I'm not advocating the use of controls in all situations; but I feel that you are making some control out there feel really bad about itself. Here's a short, quick example (that I haven't tested) of how a server control can work. It should be clear that you can do any sort of logic with this. Of course, this does not demonstrate every possible thing a control can do. You can even add JavaScript includes into the <head> of the document and things like that. In fact, controls can handle their postback, so you can put form elements in there (or paginate the data in the below example, as is the case with GridView and several other controls) and even do AJAX things. Please don't criticize my failure to use a NameSpace, validate public properties, etc. This is just a short, easy to read example. ------------------------------------------------- Imports System.ComponentModel <Description("Demonstrates that a control can do logic."), _ ToolboxData("<{0}:Example runat=server></{0}:Example>")> _ Public Class ExampleControl : Inherits Control Public ShowAnonymous As Boolean = True Public Data As DataTable Public MaxColItems As Int32 = 50 Protected Overrides Sub Render(ByVal writer As HtmlTextWriter) writer.Write("<div style='float:left;clear:none'>") For i As Int32 = 0 To Data.Rows.Count If i = MaxColItems Then writer.Write("</div><div style='float:left;clear:none'>") If Data.Rows(i).Item("is_anonymous") = "yep" Then If ShowAnonymous Then writer.Write(Data.Rows(i).Item("name")) End If Else writer.Write(Data.Rows(i).Item("name")) End If writer.Write("<br />") End If Next writer.Write("</div>") End Sub End Class ------------------------------------------------- -Michael Placentra II >> ... You [Kevin Spencer] did not comment... >> "In some occasions you may not even know the amount of data, number of [quoted text clipped - 10 lines] > not advocating the use of controls in all situations; but I feel that > you are making some control out there feel really bad about itself. i think we agree, There is a place for both, while controls may be abkle to be manipulated, sometimes it is more bother than it is worth > Here's a short, quick example (that I haven't tested) of how a server > control can work. It should be clear that you can do any sort of logic [quoted text clipped - 39 lines] > End Sub > End Class well this is pretty much spitting out html > ------------------------------------------------- > > -Michael Placentra II > i think we agree, There is a place for both, while controls may be abkle to > be manipulated, sometimes it is more bother than it is worth There are certainly wrong ways to use controls, but any time you need to code your display logic in a way that you can create more instances, creating a control is the best option. > > {code example} > well this is pretty much spitting out html Yep. That's the point in any control (except for some managers): handling the display logic and outputting a result. Essentially, it's just taking your regular code for "spitting out" HTML and making an object out of it, using some ASP.net declarative syntax if you are making a .ascx user control. I felt the need to show you that example to explain that controls do exactly the same thing but in a more organized fashion. -Michael Placentra II >> i think we agree, There is a place for both, while controls may be abkle >> to [quoted text clipped - 16 lines] > > -Michael Placentra II I think I will give controls a rethink > >> i think we agree, There is a place for both, while controls may be abkle > >> to [quoted text clipped - 20 lines] > > - Show quoted text - I agree with you 100% ThatsIT.net.au. Controls don't give you a good control over HTML output. One time I wanted to create a web page simulating a spreadsheet using dynamic forms (growing and reducing forms). I had to go through the worst time in my programming carrer trying to figure it out. I was able to do it very easily in classic asp without wasting any time. It's amazing how some posters in the newsgroups emphatically claim that .net languages are easier to learn than classic ASP. The fact is that in classic ASP you definitely have much better control over HTML output than .net controls -- provided you know what you are doing :-) ---- Most of the .net advocates actually are afraid of HTML -- for some reason -- and they rely heavily on controls. I for that matter never e v e r had problems handling HTML formatting with classic ASP. And I had pretty good idea how my HTML output would look like. If we are really concerned about reusability, it can be accomplished with ASP as well. There is lot of emphasis on OOP but I fail to understand the outdated concept of server-side controls in this day and age, when a client side code should really be the way go. >> >> i think we agree, There is a place for both, while controls may be >> >> abkle [quoted text clipped - 37 lines] > never e v e r had problems handling HTML formatting with classic ASP. > And I had pretty good idea how my HTML output would look like. Yes you have complete control by spitting out html, I some times get the idea those that limit themselves to controls have trouble with html. If you know your html well anything is possible, no matter how well controls are made they can not think of everything > If we are really concerned about reusability, it can be accomplished > with ASP as well. There is lot of emphasis on OOP but I fail to > understand the outdated concept of server-side controls in this day > and age, when a client side code should really be the way go. > Yes you have complete control by spitting out html, I some times get the > idea those that limit themselves to controls have trouble with html. If you > know your html well anything is possible, no matter how well controls are > made they can not think of everything I would be interested to know of some specific situations in which controls /should/ be able to make something easier but cannot. I'm actually more of a PHP guy than one of ASP or ASP.net, so I normally program web applications in a half-procedural, half-object-oriented way that requires "spitting out" HTML directly from PHP (controls, event-driven processing, etc not available without additional frameworks, although I use a framework that doesn't have those things anyway). I don't find ASP.net controls hindering of control of HTML at all. Let's look at some situations. Say one wants to get some data from an XML file, any sort of database, or something that one has created a custom provider for. One has some elaborate plan for presenting the data to the user, perhaps it's a photo album with a lot of features and one wants to display photos in a grid. Someone who isn't familiar with controls may immediately drag 'n' drop a GridView control out of their Visual Studio toolbox, and then have trouble getting the thumbnails to display in rows as well as columns, side by side and above one another. With custom code it could probably be done, but as someone who isn't familiar to controls, one would not want to bother with that. This is a result of stepping one (or more) controls too far. The GridView control will handle getting the data (if using an additional provider control), iteration, and output. It will also cover organization of the data, and can take care of pagination and sorting. But in the situation of a photo album, one only benefits from it's ability to get the data and iterate for you. One can get this functionality with the Repeater control, and do the output oneself. In this case, ASP.net is not outputting anything for them; it takes care of the basics: getting the data and giving each record of data to them with which one can do what they like. Further embracing the theory of controls, one can use custom code to make use of the GridView's sorting and pagination features if they are willing to deal with some debugging that may be needed because it is their first time doing such a thing. In another instance, one is in a centralization kind of mood and they want to create an RSS button control. All they want to do is create a control that outputs a simple image/link that links to the RSS feed whose name (a unique identifier) is specified in one of the control's properties. This is just for speculative reasons...maybe they have many feeds on their website and syndication buttons are all over, and the names of the RSS feeds are stored in a database with their locations. This would be done in a user control (.ascx) by creating a HyperLink control (utilizing it's ImageUrl property to put an image in it) and setting its NavigateUrl property from code-behind, simply getting the appropriate RSS feed location from the database. However, since you say that you like more direct control over your HTML, that is completely possible with a control, which is why I bring this example up. What someone like you could do is create a server control (a class like my example in my previous post) that outputs the HTML directly. This could be done with a .ascx control file also, but with little or no advantage. Of course, there are instances in which a control should not be used in the first place, which may be what you're talking about. However, it is taken by other USENET posters that you realize that this is obvious and not the purpose of controls anyway. One such case could be an RSS feed. Creating an RSS feed control would imply that it is meant to be placed on a web form (.aspx), although that is once again "stepping too far". Web form files have many extra features that could be problematic in an RSS feed, which is simply XML. Therefore, it would be illogical for an RSS-feed-writing tool to be a control. In this case, one should make a class that does the feed writing, so it can be used in a Generic Handler file (.ashx). This allows very direct control over the entire process of outputting the page, eliminating all of the things that ASP.net can do when it assumes the output is HTML for a browser such as pushing xHTML conformance. Being too paranoid of ASP.net's control over one's output can be a problem when trying to develop with ASP.net, because as a RAD platform, it tries to do things for you and make your life easier. Although it is /possible/ for automatically sticking the alt attribute in image tags or something like that to cause a problem for you, it's a very uncommon situation relative to how many times an Image control is used by ASP.net developers. ASP.net's features can't account for every little possibility, but it does a good job of making more things possible with it's extendability. If ASP.net can't do magic for your assignment, either you're doing it wrong or you should just do it the good old way of "spitting out HTML" from the same file, code, subscript that gets the data and is part of the page. Since there are so many situations in which controls are useful, there shouldn't be much reason to complain about the few things they can't help you with. -Michael Placentra II >> Yes you have complete control by spitting out html, I some times get the >> idea those that limit themselves to controls have trouble with html. If [quoted text clipped - 4 lines] > I would be interested to know of some specific situations in which > controls /should/ be able to make something easier but cannot. Nested tables where the linking key needs to be retuned by a function. Lists of data where depending on the data and calculation returned from a function the data need's to be constructed differently > Nested tables where the linking key needs to be retuned by a function. This problem has been encountered before, and solved. MSDN describes the solution. It looks like a long read, but after understanding the concept you won't need to refer to their guide. I'm sure you'll see where you can incorporate your function here. http://msdn.microsoft.com/en-us/library/aa992038.aspx > Lists of data where depending on the data and calculation returned from a > function the data need's to be constructed differently I really can't speculate well without further details, but I think I would create a control for each construction of data and insert that control at runtime after the calculation is made on the page. You could say that in some situations controls take more planning, but in the end the code is shorter and it also takes less time if one has some experience planning complicated situations with controls. -Michael Placentra II >> Nested tables where the linking key needs to be retuned by a function. > [quoted text clipped - 4 lines] > > http://msdn.microsoft.com/en-us/library/aa992038.aspx this link simple shows how to nest gridviews. did you understand the problem? >> Lists of data where depending on the data and calculation returned from >> a [quoted text clipped - 3 lines] > would create a control for each construction of data and insert that > control at runtime after the calculation is made on the page. This solution is not a easier is it? > You could say that in some situations controls take more planning, but > in the end the code is shorter and it also takes less time if one has > some experience planning complicated situations with controls. You have not show this, in fact I would say you have shown the opposite. A tailor made solution will always be as better fit that a one size fits all solution. Having said that using controls have their place but can not do everything needed > -Michael Placentra II >> http://msdn.microsoft.com/en-us/library/aa992038.aspx > this link simple shows how to nest gridviews. did you understand the > problem? Controls are tools for presentation logic, not data abstraction. The SqlDataSource control may not be able to cover all of your data needs, but that's why there is the ObjectDataSource control. One could also bind a data source to the display control through regular page code. Nesting GridView controls is the solution to the challenge you described, since you must have been talking about the process of displaying the data rather than loading it. Otherwise you would have been barking up the wrong tree. >>> Lists of data where depending on the data and calculation returned from a >>> function the data need's to be constructed differently >> I really can't speculate well without further details, but I think I >> would create a control for each construction of data and insert that >> control at runtime after the calculation is made on the page. > This solution is not a easier is it? If you are (rightly) considering using controls as a solution in the first place, then it is easier (or with other benefits) in the end. You might consider controls if you need to display data in this way in more than one place, the solution is needed in Web Parts, or it needs to be manipulated at design-time graphically (i.e. by a layout designer on the team). At the very least it will help you by improving scalability (returning to the previous reasons or others). If you are creating a piece of one-time presentation logic whose hardships have nothing to do with the goals of controls, or if there are no hardships to speak of, then you are once again barking up the wrong tree. >> You could say that in some situations controls take more planning, but >> in the end the code is shorter and it also takes less time if one has >> some experience planning complicated situations with controls. > You have not show this, in fact I would say you have shown the opposite. What I have expressed, I have backed up. It may seem like a lot to you because I have had to explain the details (the entire basics of controls in ASP.net) to you, while you have not had to explain the traditional (if I may call them that) procedures you would use because we all already know the details of iterating through a set of records from a database, outputting each <tr> element with its <td>s, etc. Controls are a fundamental part of the .net framework, and they are not so complicated to use as they may seem at first. > ...using controls have their place but can not do everything > needed Yes. This is something I have pointed out before: there are wrong ways to use controls; they won't do everything you need, otherwise ASP.net development wouldn't include programming. I still think you don't understand the proper uses of controls. However, I am starting to get a sense that I am being trolled, so please elaborate on your future points rather than stating them vaguely and then complaining to me when I optimistically assume that you meant what makes sense. -Mike Placentra II >>> http://msdn.microsoft.com/en-us/library/aa992038.aspx >> this link simple shows how to nest gridviews. did you understand the [quoted text clipped - 44 lines] > Controls are a fundamental part of the .net framework, and they are > not so complicated to use as they may seem at first. No I cant agree with you. What at first seems an easier way can often end up being a hindrance than a help as the solution needs more complicated features Merely saying something is possible is not the same as saying that it is easier and more efficient. All that has been said has not convinced me that controls are capable of providing a better solution in all situations. Although they are very handy for more simple ones. This discussion has done more to confirm my belief than dismiss it >> ...using controls have their place but can not do everything >> needed [quoted text clipped - 8 lines] > > -Mike Placentra II
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.