Controls v HTML

T

ThatsIT.net.au

Mike Placentra II said:
... 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

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


well this is pretty much spitting out html

 
M

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.
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
 
T

ThatsIT.net.au

Mike Placentra II said:
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.


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 I will give controls a rethink
 
W

Watcher01234

message








I think I will give controls a rethink- Hide quoted text -

- 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.
 
T

ThatsIT.net.au

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.


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
 
M

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
 
T

ThatsIT.net.au

message
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
 
M

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
 
T

ThatsIT.net.au

message
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?

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
 
M

Mike Placentra II

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.
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 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
 
T

ThatsIT.net.au

message
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.


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.


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.

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top