ICaramba

ASP.NET 2.0 provides more 'Declarative Programming'

With the release of ASP.NET 2.0, Microsoft has given us some new Webcontrols that allow us to exercise a more 'Declarative' approach to website development.  This is an approach that I use strongly in my current ASP.NET development and have found beneficial in many ways.  In ASP.NET, declarative programming is accomplished through the use of webcontrols.  Many of us already use this technique when we use the suite of existing webcontrols.  Our page incorporates webcontrols and through setting properties and calling methods, accomplishes tasks which would otherwise take much more code.  2.0 gives us some new webcontrols which let us save even more code at the page level.  Remember, Declarative Programming lets the page tell webcontrols 'what' to do and the webcontrols decide 'how' to do it.  In the case of the built-in controls, the code has been done for us, but in the case if custom webcontrols, we're just moving certain code off the page and into a set of controls.

Microsoft's new controls for ASP.NET include the GridView, DetailsView, FormView, and a set of DataSource controls.

The GridView is a new and improved DataGrid and among other things, it has eliminated the need for us to provide underlying code for sorting and paging.  The DataGrid supported this functionality only so far by adding links on the grid and raising some events.  We still had to provide the data rebinding and grid refreshing code.  The GridView now encapsulates this code inside the control's source code.

The DetailsView pivots a single record and displays the fields top-to-bottom with their values next to each field.  The control supports binding and paging just like the GridView.

The FormsView uses templates to create a data-entry form for a record in its datasource.  This controls lets us edit, delete, and insert records from and to a datasource and saves us the time for building a data-entry form normally made up of many labels, textboxes, buttons, etc.

All the above controls fully support multiple templates for even further customization.  From what I've seen, templates have not changed from the way they were handled in the current ASP.NET, both visually and programatically.

Additionally, we've been provided with a small suite of DataSource controls.  The SqlDataSource control for example, let's us declare database information, including connection, retrieval query, and update query in a webcontrol.  This control can then be bound to any of the above-mentioned webcontrols.

With these new controls, I've setup a grid of table data, as well as a data-entry form for its records -- all without a single line of code.  This declarative approach is one I've been using for a while inn my ASP.NET development.  Creating custom webcontrols to house visual elements also allows me to use any object-oriented technique when programming my visual elements.   I've created 'form-view' type controls to do data-entry which all inherit from a class that provides common visual elements for my data-entry forms, like headings and buttons and other things.  If you want to see an Microsoft example of an entire form created with a webcontrol, check out another new Webcontrol ASP.NET 2.0 has called the ChangePassword control.

If you've not yet started to play with Visual Studio .NET 2005 (specifically ASP.NET 2.0), these new webcontrols should really wet your appetite.  Feel free to contact me if you need any help.

posted @ Sunday, November 28, 2004 6:53 PM | Feedback (9) |

Composite Controls vs Rendered Controls

This is in reference to custom webcontrol development.

I have my own preference on this matter and have not been able to get more than that from outside sources.  No book or posting labels either as 'better than the other', though I've come across a couple of papers stating that composite controls are the 'preferred' way.  So let's start with the difference between the two:

Rendered controls are developed by overriding the Render method in the custom control class and writing directly to the rendering engine.  The text you write out is straight HTML and you use the HTML writer provided by this method in order to write it out.  The benefit to this method is there is no extra object instantiation that takes place and writing directly to the rendering engine provides for faster rendering of your control.  Remember, a custom webcontrol always ends up as straight HTML, the only thing the browser understands, so using this method you skip any 'transformation' of other components into HTML.  Now as with anything else, there are drawbacks.  Exposing events during postbacks, while not complicated, is a bit trickier than when using composite controls.  There are a couple of interfaces that need to get implemented (IPostBackDataHandler and IPostBackEventHandler) and it is in their implementation that all the 'handling' for exposed events gets done.  In my opinion, the code is not as clean and straight forward but as I said, it's a give and take.  Applying Style objects to different parts of your control is also not as straight forward.  Remember, you're dealing with regular HTML in the 'drawing' of your control so in a way you're trying to cram object-oriented techniques into a language that does not really accomodate it.  The fact remains that these controls do render faster so you must make the choice depending on what type of control you are creating and will it be one that will have multiple instances on a page, etc.  Personally, I use this method for less complex controls and controls that may be used many times in one page -- custom form field controls are one example of this.

Composite Controls work a bit different.  While the general claim is that they are a bit slower to render than Rendered Controls, I find that their design and development is much more straight forward.  A composite control is essentially a 'container' of one or more other controls.  Child controls are instantiated and setup by overriding the CreateChildControls method of your custom control.  Here the control properties can be set (or mapped to exposed properties of your control).  The child controls are then added to the Controls collection of your custom control.  It is also very normal to use LiteralControl objects to place additional HTML around the child controls to accomodate the layout you are seeking.  Obviously, through the use of properties, you can provide different layout by simply building the Controls collection in a different way.  Child controls can raise events to its parent, our custom control, which can in turn raise its own events to the outside.  Most of the controls I write fall into this category and I definately find it the preferred method for writing business-oriented site-specific webcontrols.  These are controls which are not necessarily intended to be largely reusable components but are just broken out pieces of a website.  This is a 'declarative programming' approach to ASP.NET development which I use pretty extensively.  Check out my other entry which talks about this a bit:
http://www.geekswithblogs.com/mcastro/archive/2004/11/22/15465.aspx.
Another advantage of composite controls is the fact that everything within them is object-oriented so you can apply different patterns to your webcontrol library.  I've developed libraries of webcontrols that use abstract classes and interfaces extensively to share common visual objects and functionality.  In fact I have webcontrol libraries (generally site-specific ones), that have multiple levels of inheritance for controls, designers, type-converters, and all sorts of helper objects.

Both types of controls serve their purpose, and a combination of the two usually makes up the best arsennal of components.  I have composite webcontrols which draw entire forms using rendered controls as some of its children.  One of the deciding factors for you may be as to whether you're targetting Internet or Intranet applications.  With Intranet applications, the rendering lag may not be a big issue for you at all - but truth be told, I've encountered no problems with rendering times even on Internet sites.  I try to concentrate more of my performance-oriented analysis on ViewState use (more about that on the next posting).

Oh yeah, I almost forgot -- there's a third category:  Inherited Controls.  These are just controls that 'inherit' from an existing webcontrol and add functionality.  The best examples I can give you for this is a custom dropdown list that fills itself or a custom textbox that provides highlight-on-focus, or some additional styling, or anything else actually.  The simplest inherited control I've created was an extended button that added a property called ConfirmOnClick.  This property made the button bring up a javascript confirmation box before proceeding with the server-side Click event.

Anyway, as you can guess, this is a big topic but it's a whole lot of fun. --- Happy Coding

posted @ Wednesday, November 24, 2004 2:01 PM | Feedback (1) |

Handling site-wide variables in ASP.NET

I'm sure many of you use cookies to track certain pieces of data within a website and even ViewState for data you only need for that page.  Here's a cool way of hiding the cookie/viewstate code and exposing simply a property that your page or pages can use (the example uses a boolean property called IsActive).  I cover both cookies and ViewState within the property for a very specific reason.  If you set a cookie, you of course must use Response.Cookies.  Retrieving it is typically done using Request.Cookies but only after a new page request has taken place.  If you try to access the contents of the cookie using Request within the same page request (in a called method for example), you will not have have access to it (or you will see a previous value).  In this case you must still use Response, even to read the cookie contents.  My property wrapper stores the value in both a cookie and ViewState, then during reading I check ViewState first.  This ensures that reading a value in a new page request will hit the Request.Cookies and reading it a second time in the same page request (or subsequent page postbacks) you get the value in ViewState.

Public Property IsActive() As Boolean
     Get
          If CType(ViewState("IsActive"), Object) Is Nothing Then
               If HttpContext.Current.Request.Cookies("IsActive") Is Nothing Then
                        ' Defaults
                        HttpContext.Current.Response.Cookies("IsActive").Value = "0"
                        ViewState("IsActive") = False
               Else
                        Dim s_Value As String = HttpContext.Current.Request.Cookies("IsActive").Value
                        ViewState("IsActive") = IIf(s_Value = "1", True, False)
               End If
          End If
          Return CType(ViewState("IsActive"), Boolean)
     End Get
     Set(ByVal Value As Boolean)
            HttpContext.Current.Response.Cookies("IsActive").Value = IIf(Value, "1", "0")
            ViewState("IsActive") = Value
     End Set
End Property

Also not that you can set property value defaults here too (within the first If-Else in the Property-Get).

This code can go right in your page's code-behind class but since you would typically share a cookie across a site, setup a custom page base class that inherits from System.Web.UI.Page and use this class as the base class for your code-behind classes.

posted @ Tuesday, November 23, 2004 3:33 PM | Feedback (0) |

"Refactoring" as a coding technique

This one's for Eric.

I've noticed that in some places, by some people, the term 'refactoring' seems to have a slightly negative connotation.  I don't think this has to always be the case.  In fact, in my webcontrol development (an area of .NET I use quite a bit), I have refactoring constantly in the forefront.  Of course, I'm not talking about constantly tearing everything apart and redoing things, but I am always splitting off classes and inserting new abstract classes, etc.   You can only spend so much time in your design stage and you can only think of so many things before you get to coding.  In the development of webcontrols, I'm always coming up with a new webcontrol that I need, then while coding it I find it bears a resemblance to another one I already have.  If I cannot leverate the entire webcontrol I already have developed, I end up breaking out a baseclass that both the old and the new one will derive from.  This can and has happenned at multiple levels in an inheritance chain and happens not only on webcontrol development.  Building business object models seems to trigger this kind of “refactoring” during development.   By the time I deliver a system, my object tree shows inheritance levels and polymorphisms that I did not initially come up with when I was designing the application.  Personally, I think it's quite cool to see a class model, being business or UI related, evolve and take shape as its development progresses.  Maybe the term “refactoring” is not the proper term here.  I welcome any comments of course.

When I said earlier, “this one's for Eric”, I didn't mean it in a negative way.  Eric actually shares a lot of design beliefs, techniques, and methodologies with me; I just think he was in the middle of a “refactor-hell” at the moment so I'm trying ease his pain.

Check out this book:
http://www.amazon.com/exec/obidos/search-handle-form/104-7165989-8051142

I was reading it for a while at Borders Book store and was delighted to see the author feels the same way about this as I do.

posted @ Tuesday, November 23, 2004 2:23 PM | Feedback (0) |

The most underused technology...

...in my humble opinion are Custom ASP.NET Webcontrols.  For this reason, I've made this the one area of ASP.NET I concentrate most of my efforts on.  When most of us talk about custom webcontrols, we think of the ones provided by component vendors like Infragistics and ComponentOne.  Now, I have no doubt there are developers out there that know how to create them but as a consultant developing applications in the business world and working with other .NET programmers, I have noticed that most do not have much experience outside of simply 'using' third-party webcontrols.  I've also noticed that those developers I know that do write custom webcontrols seem to concentrate more on the 'reusable component' concept they provide for us.  Don't get me wrong, they do provide the ultimate UI code reuse available in ASP.NET, but there's another use for them as well.  First of all, webcontrols written do not have to be completely generic and usable across many websites.  This is of course the practice we see from third party component vendors and even from many of us as well, but webcontrols developed for a specific site or business solution are a great idea too.  Indeed I use custom webcontrols as an entire approach to ASP.NET website programming.  OK, here comes the part many may disagree with:  I develop sites made up primarily of custom webcontrols and some are not even reused in more than one spot within the site.  Why, you may ask?  Well, for me it provides great UI code encapsulation and allows for signifigantly less code clutter at the page level.  That's just one reason.  Another is that it allows me to concentrate on small sections of a site one piece at a time.  Instead of designing pages with many tables within tables within tables to accomplish the layout I need, I start from the inside and work my way out.  I've developed webcontrols that provide me custom form fields and webcontrols that provide me complete data entry forms.  In the latter case, I provide base classes that provide common functionality that all my data entry forms may share (i.e. headings, submit buttons, etc.).  Designing the data entry form in just code, with no visual interface, has never been a problem.  For one, like I said before, I can concentrate on just that one are of visual rendering, and that ususally boils down to a table or two with some labels and fields in it.  Sizing, believe or not, is actually simpler since the contents of the webcontrol should size maximally to their container.  When you drop the controls on a form you can then size the entire control to the page and not worry about individual pieces within it.  I can provide functionality such as read-only vs. read-write on text fields in properties of the webcontrol, then I can reuse the same control to display detail information for data entry or for viewing only using the same webcontrol.  This is just one example; others I have done include custom grids or lists of information, and yes of course there are those webcontrols that are fully reusable by any website.  Check out my daughter's website at http://www.familiacastro.com/victoria and look at the photo gallery.  The entire functionality from displaying and paging through the thumbnails to actually displaying each photo and paging through them is provided by a single webcontrol which simply requires pointing it to a folder of photos.  The control itself creates thumbnails, if necessary, and gives you all the functionality you need.  This control also provides extensive styling so you can make a gallery look any way you like.  If you'd like, you can download this at http://www.infotekcg.com/downloads.aspx.  For those who have downloaded, or even just used, the forums at www.asp.net you may already know that the entire site is written using custom webcontrols, as is the new Community Forums that Rob Howard and Scott Watermasysk are working on.  Another advantage of this type of design is a developer can simply add functionality provided by these controls to his or her site.  In the case of the forums site, think about being able to add a specific forum posting to your website just by dropping a certain webcontrol on a page and pointing it to a posting ID or something like that.  You get the idea.  Again, it's more than just writing reusable components, it's an approach to website design and development in ASP.NET.  Anyway, this is the topic that most of my postings in this blog will be about so check back and expect more.

posted @ Monday, November 22, 2004 1:03 PM | Feedback (1) |

Template solution for checkboxes

Check out Scott's solution for trapping checkbox changed events from a checkbox contained in a datagrid column template.

http://www.geekswithblogs.com/sgreenberger/archive/2004/11/12/14871.aspx?Pending=true

I've added some extra stuff in the feedback and will blog about it completely tomorrow. -- good job Scott.

posted @ Friday, November 12, 2004 5:35 AM | Feedback (0) |

And now for something completely different...

As this is my first posting on GeeksWithBlogs, let me tell you a little something about geek that is I.   I've actually had a blog for quite some time (http://www.infotekcg.com/blog) but I've been meaning to switch to a community blog site for a while in a borg-type assimilation attempt with the other fellow cyber entitities.  I've been in the computer business for a very long time (we're talking Trash-80s and Ataris here folks) and have been a VB guy since 1.0.  My specialty today is the .NET platform where I concentrate most of my efforts on ASP.NET.  Over a year ago I discovered the power and potential of custom webcontrols and I have been striving to become an expert in this particular technology.  I regularly give user-group talks in NJ and recently NY and CT as well (next month I get to add Philly to that list).  I also have articles in CoDe Magazine and hopefully more magazines soon.  My actual day-job is that of an independent consultant where I am forever in search of that money-to-technology balance that is a consultant's nirvana.  On a personal note, I have a wife and 11 month-old little girl.  I anticipate 2-3 blog entries a week if I can so I look forward to some good exchanges with all my fellows in the business.  My personal blog is at www.miguelacastro.com where there is no tech allowed.

Catch you on the bandwidth...

posted @ Tuesday, November 09, 2004 12:50 PM | Feedback (0) |