Controls v HTML
ThatsIT.net.au
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?
darrel
>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
Peter Bromberg [C# MVP]
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
--
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com
ThatsIT.net.au
"darrel" <not...@nowhere.com> wrote in message
news:ubdgInBD...@TK2MSFTNGP02.phx.gbl...
> >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)
>
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
>> 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.
>
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
>
ThatsIT.net.au
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.
"Peter Bromberg [C# MVP]" <pbro...@yahoo.yohohhoandabottleofrum.com> wrote
in message news:1C8A2F6A-DB37-4DFB...@microsoft.com...
Kevin Spencer
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.
--
HTH,
Kevin Spencer
Microsoft MVP
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net
"ThatsIT.net.au" <me@thatsit> wrote in message
news:6A1D6B5A-0AD1-4190...@microsoft.com...
Phil H
>
> - 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.
ThatsIT.net.au
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
"Phil H" <goo...@philphall.me.uk> wrote in message
news:1192229128.3...@k35g2000prh.googlegroups.com...
Mike Placentra II
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.
(that's for the PHP programmers who haven't discovered the value of
those RAD frameworks for PHP)
-Michael Placentra II
ThatsIT.net.au
"Mike Placentra II" <nothingsorigin...@gmail.com> wrote in
message news:1192321209.9...@i38g2000prf.googlegroups.com...
> -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
> 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
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
Mike Placentra II
> 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
> > 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,
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
ThatsIT.net.au
> On Oct 14, 12:10 pm, "ThatsIT.net.au" <me@thatsit> wrote:
>> 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.
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
> 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.
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
>> > 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,
>
> 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
> = ...
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
>> 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.
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
>> 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.
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
>> 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.
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
Mike Placentra II
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
Kevin Spencer
<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
> 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.
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.
ThatsIT.net.au
"Kevin Spencer" <unclec...@nothinks.com> wrote in message
news:%23YmWHD$DIHA...@TK2MSFTNGP06.phx.gbl...
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
> 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.
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
> 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.
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
> 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.
>
I hardly see controls as intimidating, but clumsy, like many attempts at
making things easier, they make themselves less flexible.
Kevin Spencer
>
<snip>
> I hardly see controls as intimidating, but clumsy, like many attempts at
> making things easier, they make themselves less flexible.
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.
ThatsIT.net.au
> "ThatsIT.net.au" <me@thatsit> wrote in message
> news:49AA2E70-878C-4D55...@microsoft.com...
>>
> <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.
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
Kevin Spencer
<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.
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.
ThatsIT.net.au
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"
Mike Placentra II
> ... You [Kevin Spencer] did not comment...
> "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"
/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
ThatsIT.net.au
> On Oct 17, 10:57 am, "ThatsIT.net.au" <me@thatsit> wrote:
>> ... You [Kevin Spencer] did not comment...
>> "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"
>
> /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.
>
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
well this is pretty much spitting out html
> -------------------------------------------------
>
> -Michael Placentra II
>
Mike 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
ThatsIT.net.au
I think I will give controls a rethink
Watche...@gmail.com
> "Mike Placentra II" <nothingsoriginalontheinter...@gmail.com> wrote in
> messagenews:1192822809....@t8g2000prg.googlegroups.com...
>
>
>
>
>
> > On Oct 19, 1:06 pm, "ThatsIT.net.au" <me@thatsit> wrote:
> >> 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
> > 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
>
>
> - 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.
ThatsIT.net.au
<Watche...@gmail.com> wrote in message
news:1193108162....@v29g2000prd.googlegroups.com...
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
Mike 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 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
ThatsIT.net.au
> On Nov 16, 9:47 am, "ThatsIT.net.au" <me@thatsit> wrote:
>> 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.
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
Mike Placentra II
> 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
ThatsIT.net.au
> On Nov 22, 9:31 am, "ThatsIT.net.au" <me@thatsit> wrote:
>> 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
>
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
>> 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?
> 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
Mike 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
ThatsIT.net.au
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