Last post Oct 03, 2007 09:20 AM by bitmask
Sep 27, 2007 08:49 AM|dKinjal|LINK
I'm sure everyone's mind crossed 'User Control Vs Custom Control'..!
They are different; in their Usage, in Hierarchy, one has got UI, while another has to make himself happy only with code.
But they are also much similar; MOST of the capabilities, Working, Common ancestor (Control class), and above all the Purpose of existence.
UC have associated ascx UI, that gives up rapid edge! But, technically, whats it that is keeping CC to have UI like ascx?
These raised in my mind when I was thinking to create WebParts, rapidly. I want all that is offered by WebPart (not just IWebPart abstraction), and wished to have rapid development offered by UC.
Although, thru object composition, I can wrap UC in WebPart, its not the perfect way to do it, as I am wrapping similar "kind of" object (UC) in WebPart (ultimately, CC). Shouldn't we have a separate mechanism that club UI with CC? After all, all CC and
UI are doing is, producing HTML for their respective containers.
Any inside information about, why, or how, or why can't to the point? Have anyone explored these valleys on ASP.NET?
[PS: Please let me know if i am (as it seem) not able to make my point clear.. ]
Sep 27, 2007 11:00 AM|bitmask|LINK
Custom controls always had the advantage that you could package them up into a single assembly and deploy them by dropping the assembly into a bin directory or installing it into the GAC.
With user controls, you generally have to deploy or share the source if you want to use them across multiple projects, although with web deployment projects you can pretty much do the same with .ascx files, too.
Sep 27, 2007 11:17 AM|Suprotim Agarwal|LINK
Some differences have been covered over here
What are the differences between user and custom controls?
Sep 28, 2007 01:01 AM|dKinjal|LINK
The link seems good! Thanks!
I guess, technically, only sensible difference is "share" and "private" possibilities of consumption.
I mean, there must be some reason, why custom controls (including WebParts) cannot have UI for fast development..! Yes, of course, it then needs to carry XML, but it can be embedded in assembly.. or say it can be kept optional.!
The point I want to make is, either there must be some strong reason due to which MS did it this way, or
there are some scopes!!
Have a nice time!
Oct 03, 2007 06:48 AM|dKinjal|LINK
Oct 03, 2007 09:20 AM|bitmask|LINK
You the programming world down into two types: declarative and imperative.
In declarative programming you tell the computer what you want done, and it figures out the exact steps. For example:
<asp:TextBox runat="server" id="_textBox" Text="Hello" />
In imperative programming you tell the computer the exact sequence of steps it will perform to carry out a task. For Example:
TextBox tb = new TextBox(); tb.Text="Hello"; Controls.Add(tb);
Same results, but different styles.
User controls have always been about declarative programming. You use the visual designer to lay out controls and ASP.NET will figure out how to generate the code to achieve that layout.
In custom controls you are writing code, so MS assumes you want the fine-grained control of imperative programming. Although MS might have provided some designer help to write the code for you, the problem would be that the designer and the developer would
both be fighting to write code inside the Render method, which wouldn't be pretty. The designer would be overwriting the developers code and vice-versa.