469,286 Members | 2,372 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,286 developers. It's quick & easy.

Controls v HTML

I come from a classic asp background, but have started using ASP.NET about
12 months ago, but I'm still not sure about the pros and cons of using
controls v HTML spat out from code as you would in classic asp. I have also
been using System.Web.UI.ICallbackEventHandler to send data to the server
and back without using controls.

What I want to know is the pros and cons of each. To me you never have quite
the freedom using a control as you do manipulating html and spitting it out,
but it can be quicker using a control for more simple jobs.

what are the performance issues?

What have other classic asp users found to be best when using asp.net?
Oct 11 '07 #1
19 1628
>I come from a classic asp background, but have started using ASP.NET about
>12 months ago, but I'm still not sure about the pros and cons of using
controls v HTML spat out from code as you would in classic asp. I have also
been using System.Web.UI.ICallbackEventHandler to send data to the server
and back without using controls.
The advantages of controls like DataGrid and the like is that it's simply
faster/easier to get data from your back end onto your front end.

The advantages of controls like repeaters and the like is that you can get
that 'ideal' separation of presentation on the front (.aspx) end with logic
on the back end (.vb/cs files)

The disadvantages of the built in web controls...ESPECIALLY in 1.1, was that
the HTML, for the most part, sucked. It wasn't very semantic and often
invalid.

So, I got in the habit of using a lot of stringwriters ala classic ASP.

I'm now trying ot break myself of that habit as I move into 2.0 ;o)
What I want to know is the pros and cons of each. To me you never have
quite the freedom using a control as you do manipulating html and spitting
it out, but it can be quicker using a control for more simple jobs.
that's pretty much it.

Even the 2.0 controls are somewhat limited. Ie, a datagrid is really easy to
set up to allow the viewing and editing of content from one table. But once
you start getting into manipulating data across tables via joins and the
like, then the datagrid becomes rather complex to deal with.
What have other classic asp users found to be best when using asp.net?
IMHO, if you are willing to embrace the entire concept of OOP development,
then do it, and go with ASP.net. If you prefer the ASP 'lifestyle' then
consider migrating to PHP, as that is closer in methedology.

-Darrel
Oct 11 '07 #2
I doubt there are any real performance issues, everything gets spit out to
the response output stream anyway, whether you do it "manually" or let a
control do it by responding to its Render method from the Page class.

I've seen developers coming from a classic ASP (and so did I) environment
who just refuse to accept progress and do everything the "old way". I would
suggest you change your mindset to the concept of ASP.NET controls - and even
consider writing some of your own CustomControls along the way.

If you run into a situation where you just absolutely cannot figure out how
to make the ASP.NET Controls on the Toolbox do what you need, you can always
fall back to building strings of HTML with a StringBuilder and attaching the
output HTML to a placeholder or HtmlGeneric("div") control's InnerHTML
property.

Peter
--
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

"ThatsIT.net.au" wrote:
I come from a classic asp background, but have started using ASP.NET about
12 months ago, but I'm still not sure about the pros and cons of using
controls v HTML spat out from code as you would in classic asp. I have also
been using System.Web.UI.ICallbackEventHandler to send data to the server
and back without using controls.

What I want to know is the pros and cons of each. To me you never have quite
the freedom using a control as you do manipulating html and spitting it out,
but it can be quicker using a control for more simple jobs.

what are the performance issues?

What have other classic asp users found to be best when using asp.net?

Oct 11 '07 #3
The answer really depends on what your career is. If you are a professional
developer, and plan to remain one, embrace and master object-oriented
programming, learn how to employ the power of OOP and good object-oriented
design and architecture patterns and practices, and expect to take a good
long time doing so. In the long run, you'll be much better off, write
software that is powerful, secure, easy to maintain and extend, and get much
more done in much less time.

If on the other hand, you are a hobbyist, it is entirely up to you whether
you want to go to all that trouble.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

"ThatsIT.net.au" <me@thatsitwrote in message
news:6A**********************************@microsof t.com...
>I come from a classic asp background, but have started using ASP.NET about
12 months ago, but I'm still not sure about the pros and cons of using
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?


Oct 12 '07 #4
On 12 Oct, 17:33, "Kevin Spencer" <unclechut...@nothinks.comwrote:
The answer really depends on what your career is. If you are a professional
developer, and plan to remain one, embrace and master object-oriented
programming, learn how to employ the power of OOP and good object-oriented
design and architecture patterns and practices, and expect to take a good
long time doing so. In the long run, you'll be much better off, write
software that is powerful, secure, easy to maintain and extend, and get much
more done in much less time.

If on the other hand, you are a hobbyist, it is entirely up to you whether
you want to go to all that trouble.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:http://www.miradyne.net

"ThatsIT.net.au" <me@thatsitwrote in message

news:6A**********************************@microsof t.com...
I come from a classic asp background, but have started using ASP.NET about
12 months ago, but I'm still not sure about the pros and cons of using
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?- Hide quoted text -

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

Oct 12 '07 #5
OOP is not the same as using controls.

I am a big believer in OOP. But I'm not sure that using controls is superior
to spitting out html. My query is not ASP v ASP.NET it is Controls v
spitting out html

"Phil H" <go****@philphall.me.ukwrote in message
news:11**********************@k35g2000prh.googlegr oups.com...
On 12 Oct, 17:33, "Kevin Spencer" <unclechut...@nothinks.comwrote:
>The answer really depends on what your career is. If you are a
professional
developer, and plan to remain one, embrace and master object-oriented
programming, learn how to employ the power of OOP and good
object-oriented
design and architecture patterns and practices, and expect to take a good
long time doing so. In the long run, you'll be much better off, write
software that is powerful, secure, easy to maintain and extend, and get
much
more done in much less time.

If on the other hand, you are a hobbyist, it is entirely up to you
whether
you want to go to all that trouble.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:http://www.miradyne.net

"ThatsIT.net.au" <me@thatsitwrote in message

news:6A**********************************@microso ft.com...
>I come from a classic asp background, but have started using ASP.NET
about
12 months ago, but I'm still not sure about the pros and cons of using
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?-
Hide quoted text -

- 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.
Oct 13 '07 #6
-Easier to reuse
Your next best option to reuse code that spits out dynamic HTML
would be to create a subscript. If you were to create a subscript that
does what the GridView control does, it would have more parameters
than would be worth dealing with.

-OOP benefits
What Kevin Spencer means is that you work with controls
programmatically in an OOP fashion. A control gives you events,
methods, and properties for interacting with it to make your code more
organized. A control is really an object, so using a control is using
OOP.

-IDE integration
You can work with controls graphically at design time, whether
they are user controls or server controls (assuming the server control
code has appropriate attributes and a ControlDesigner).

One who works primarily with ASP.net may take controls for granted,
but programmers of more procedural languages who understand ASP.net
controls sometimes envy you.

http://php.net/dotnet

(that's for the PHP programmers who haven't discovered the value of
those RAD frameworks for PHP)

-Michael Placentra II
On Oct 13, 11:17 am, "ThatsIT.net.au" <me@thatsitwrote:
OOP is not the same as using controls.

I am a big believer in OOP. But I'm not sure that using controls is superior
to spitting out html. My query is not ASP v ASP.NET it is Controls v
spitting out html
Oct 14 '07 #7

"Kevin Spencer" <un**********@nothinks.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
"ThatsIT.net.au" <me@thatsitwrote in message
news:49**********************************@microsof t.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

Oct 17 '07 #8
"ThatsIT.net.au" <me@thatsitwrote in message
news:64**********************************@microsof t.com...
<snip>
>Whatever your perception of ASP.Net Controls is, it is due to your
unfamiliarity with them, and with your unfamiliarity with the ASP.Net
programming paradigm. When used correctly, ASP.Net Controls do whatever
you want them to do, and very well.

no they don't, I think the tasks you are doing may be very basic.
<snip>

I've been doing ASP.Net since the first beta version came out, and I've done
just about everything with ASP.Net that can be done with it, except for
Ajax. I've built a large number of web sites with it, Controls that interact
with SWFs that interact with Web Services that I've built, HttpHandlers for
a variety of purposes, member- and role-based portals that have database
back-ends, database interfaces, Controls that render images and charts,
Controls that use XSLT to create HTML from serialized sets of custom
classes, Controls that render JavaScript, so much stuff that I don't
remember some of it.

Over the years, I've learned to use Controls more, not less, by experience
and research. I have a large personal library of custom Controls that I have
previously built, and employ in projects that come up.

That said, you don't have to believe me. The information I've provided was
for your benefit, not mine. Someday it may be useful to you, if not today.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net
Oct 17 '07 #9

"Kevin Spencer" <un**********@nothinks.comwrote in message
news:eu**************@TK2MSFTNGP03.phx.gbl...
"ThatsIT.net.au" <me@thatsitwrote in message
news:64**********************************@microsof t.com...
<snip>
>>Whatever your perception of ASP.Net Controls is, it is due to your
unfamiliarity with them, and with your unfamiliarity with the ASP.Net
programming paradigm. When used correctly, ASP.Net Controls do whatever
you want them to do, and very well.

no they don't, I think the tasks you are doing may be very basic.
<snip>

I've been doing ASP.Net since the first beta version came out, and I've
done just about everything with ASP.Net that can be done with it, except
for Ajax. I've built a large number of web sites with it, Controls that
interact with SWFs that interact with Web Services that I've built,
HttpHandlers for a variety of purposes, member- and role-based portals
that have database back-ends, database interfaces, Controls that render
images and charts, Controls that use XSLT to create HTML from serialized
sets of custom classes, Controls that render JavaScript, so much stuff
that I don't remember some of it.

Over the years, I've learned to use Controls more, not less, by experience
and research. I have a large personal library of custom Controls that I
have previously built, and employ in projects that come up.

That said, you don't have to believe me. The information I've provided was
for your benefit, not mine. Someday it may be useful to you, if not today.
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"

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

Oct 17 '07 #10
On Oct 19, 1:06 pm, "ThatsIT.net.au" <me@thatsitwrote:
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

Oct 19 '07 #11

"Mike Placentra II" <no***************************@gmail.comwrote in
message news:11*********************@t8g2000prg.googlegrou ps.com...
On Oct 19, 1:06 pm, "ThatsIT.net.au" <me@thatsitwrote:
>i think we agree, There is a place for both, while controls may be abkle
to
be manipulated, sometimes it is more bother than it is worth

There are certainly wrong ways to use controls, but any time you need
to code your display logic in a way that you can create more
instances, creating a control is the best option.
{code example}
well this is pretty much spitting out html

Yep. That's the point in any control (except for some managers):
handling the display logic and outputting a result. Essentially, it's
just taking your regular code for "spitting out" HTML and making an
object out of it, using some ASP.net declarative syntax if you are
making a .ascx user control. I felt the need to show you that example
to explain that controls do exactly the same thing but in a more
organized fashion.

-Michael Placentra II
I think I will give controls a rethink

Oct 20 '07 #12
On Oct 20, 1:19 pm, "ThatsIT.net.au" <me@thatsitwrote:
"Mike Placentra II" <nothingsoriginalontheinter...@gmail.comwrote in
messagenews:11*********************@t8g2000prg.goo glegroups.com...


On Oct 19, 1:06 pm, "ThatsIT.net.au" <me@thatsitwrote:
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 someASP.netdeclarative 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- 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.
Oct 23 '07 #13

<Wa**********@gmail.comwrote in message
news:11*********************@v29g2000prd.googlegro ups.com...
On Oct 20, 1:19 pm, "ThatsIT.net.au" <me@thatsitwrote:
>"Mike Placentra II" <nothingsoriginalontheinter...@gmail.comwrote in
messagenews:11*********************@t8g2000prg.go oglegroups.com...


On Oct 19, 1:06 pm, "ThatsIT.net.au" <me@thatsitwrote:
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 someASP.netdeclarative 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- 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.

Yes you have complete control by spitting out html, I some times get the
idea those that limit themselves to controls have trouble with html. If you
know your html well anything is possible, no matter how well controls are
made they can not think of everything
If we are really concerned about reusability, it can be accomplished
with ASP as well. There is lot of emphasis on OOP but I fail to
understand the outdated concept of server-side controls in this day
and age, when a client side code should really be the way go.

Nov 16 '07 #14
On Nov 16, 9:47 am, "ThatsIT.net.au" <me@thatsitwrote:
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
Nov 21 '07 #15

"Mike Placentra II" <no***************************@gmail.comwrote in
message
news:f3**********************************@w40g2000 hsb.googlegroups.com...
On Nov 16, 9:47 am, "ThatsIT.net.au" <me@thatsitwrote:
>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

Nov 22 '07 #16
On Nov 22, 9:31 am, "ThatsIT.net.au" <me@thatsitwrote:
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
Nov 25 '07 #17

"Mike Placentra II" <no***************************@gmail.comwrote in
message
news:67**********************************@d27g2000 prf.googlegroups.com...
On Nov 22, 9:31 am, "ThatsIT.net.au" <me@thatsitwrote:
>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
Dec 3 '07 #18
On Dec 3, 7:54 am, "ThatsIT.net.au" <me@thatsitwrote:
>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 <trelement 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
Dec 5 '07 #19

"Mike Placentra II" <no***************************@gmail.comwrote in
message
news:e9**********************************@l16g2000 hsf.googlegroups.com...
On Dec 3, 7:54 am, "ThatsIT.net.au" <me@thatsitwrote:
>>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 <trelement 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

>
>...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
Dec 22 '07 #20

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Steve Drake | last post: by
10 posts views Thread by Sacha Korell | last post: by
5 posts views Thread by Brian Kitt | last post: by
22 posts views Thread by Mr Newbie | last post: by
8 posts views Thread by mark.norgate | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.