I am just trying to decide whether to split my code and uses code behind. I
did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the only
one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I would
need to run over to the person working on the codebehind and tell him to add
the new object to his page.
Things that are assumed on the .aspx page are not assumed on the codebehind
and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned. Normally,
you are told that it is better. Is this the case in all situations?
Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.
Thanks,
Tom
171  7555 
Tom,
I think you have some valid points against codebehind. If you are 100% sure
that you'll be the only one developing the site and you are 100% sure that
won't change or that things won't get a lot more complicated (say like when
I do my dad's website), then I agree the benefits of codebehind aren't as
significant. having said that, using Vs.Net you get great intellisense in
codebehind which pretty much makes it worthwhile just for that. Personally
I'd recommend you use it because I'm an OO bigot and love tiered
architecture ;) but if it works for you without it, then by all means. You
seem to have a fairly good understanding of why you'd want to use
codebehind...so you seem in a good position to decide if it's good for you.
Karl
--
MY ASP.Net tutorials http://www.openmymind.net/
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl... I am just trying to decide whether to split my code and uses code behind.
I did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the only
one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I would
need to run over to the person working on the codebehind and tell him to
add the new object to his page.
Things that are assumed on the .aspx page are not assumed on the
codebehind and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned.
Normally, you are told that it is better. Is this the case in all situations?
Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.
Thanks,
Tom
Separate them will make looking at your code easier, especially when you have
large file. Visual Studio.NET has good support for code behind so that when
you modify the UI, some of it is reflected in the code-behind file as well.
"tshad" wrote: I am just trying to decide whether to split my code and uses code behind. I
did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the only
one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I would
need to run over to the person working on the codebehind and tell him to add
the new object to his page.
Things that are assumed on the .aspx page are not assumed on the codebehind
and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned. Normally,
you are told that it is better. Is this the case in all situations?
Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.
Thanks,
Tom
Please read the thread with subject :
"What's the difference/advantages
between code behind and code inside?
Juan T. Llibre
ASP.NET MVP
===========
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl... I am just trying to decide whether to split my code and uses code behind.
I did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the only
one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I would
need to run over to the person working on the codebehind and tell him to
add the new object to his page.
Things that are assumed on the .aspx page are not assumed on the
codebehind and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned.
Normally, you are told that it is better. Is this the case in all
situations?
Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.
Thanks,
Tom
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl... I use Dreamweaver to do my design and find it a bit of a hassle to have
I heard the new version of Dreamweaver can handle Asp.Net page. May be it is
worthwhile to consult with the guys there to see if it is so.
John
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:u6**************@TK2MSFTNGP11.phx.gbl... Please read the thread with subject :
"What's the difference/advantages
between code behind and code inside?
I did and added my 2 cents worth - which is about all I can handle at this
point.
So far, I've determined that there really is no discernable benefit from
going from code-inside to code-behind (other than to use VS) or are trying
to hide the source if deploying the application. It really is a matter of
preference. Not a better way to code - as was mentioned.
Thanks,
Tom
The separation happens whether or not you use code-behind
Juan T. Llibre
ASP.NET MVP
===========
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl...I am just trying to decide whether to split my code and uses code behind.
I did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the
only one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I
would need to run over to the person working on the codebehind and tell
him to add the new object to his page.
Things that are assumed on the .aspx page are not assumed on the
codebehind and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned.
Normally, you are told that it is better. Is this the case in all
situations?
Just trying to get other opinions on this, as I have already have about
30 pages designed and am trying to decide if I should split the files or
not.
Thanks,
Tom
This isn't, by any means, the end of this topic.
In ASP.NET 2.0, partial classes will add another element
to the current compilation model : partial classes.
See http://pluralsight.com/blogs/fritz/a...1/18/5111.aspx
to get up to speed with partial classes.
Make sure you follow through on the
comments after all the demo code.
There's an interesting discussion going on.
Juan T. Llibre
ASP.NET MVP
===========
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:u6**************@TK2MSFTNGP11.phx.gbl... Please read the thread with subject :
"What's the difference/advantages
between code behind and code inside?
I did and added my 2 cents worth - which is about all I can handle at this
point.
So far, I've determined that there really is no discernable benefit from
going from code-inside to code-behind (other than to use VS) or are trying
to hide the source if deploying the application. It really is a matter of
preference. Not a better way to code - as was mentioned.
Thanks,
Tom
The separation happens whether or not you use code-behind
Juan T. Llibre
ASP.NET MVP
===========
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl...I am just trying to decide whether to split my code and uses code behind.
I did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the
only one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I
would need to run over to the person working on the codebehind and tell
him to add the new object to his page.
Things that are assumed on the .aspx page are not assumed on the
codebehind and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned.
Normally, you are told that it is better. Is this the case in all
situations?
Just trying to get other opinions on this, as I have already have about
30 pages designed and am trying to decide if I should split the files or
not.
Thanks,
Tom
Tom,
Maybe you feel this way at this point in your career. Maybe you only work on
small applications. But, like good architecture, your methodology should be
extensible. Extensibility, and ease of code maintenance are the chief
reasons for separating an app into separate tiers, and separating HTML
template layout markup from Page business logic. At some point, hopefully,
you will work on large-scale apps, and/or work in a team, and I hope your
methodology can accomodate the new situation when and if it comes.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:u6**************@TK2MSFTNGP11.phx.gbl... Please read the thread with subject :
"What's the difference/advantages
between code behind and code inside?
I did and added my 2 cents worth - which is about all I can handle at this
point.
So far, I've determined that there really is no discernable benefit from
going from code-inside to code-behind (other than to use VS) or are trying
to hide the source if deploying the application. It really is a matter of
preference. Not a better way to code - as was mentioned.
Thanks,
Tom
The separation happens whether or not you use code-behind
Juan T. Llibre
ASP.NET MVP
===========
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl...I am just trying to decide whether to split my code and uses code behind.
I did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the
only one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I
would need to run over to the person working on the codebehind and tell
him to add the new object to his page.
Things that are assumed on the .aspx page are not assumed on the
codebehind and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned.
Normally, you are told that it is better. Is this the case in all
situations?
Just trying to get other opinions on this, as I have already have about
30 pages designed and am trying to decide if I should split the files or
not.
Thanks,
Tom
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O0**************@TK2MSFTNGP11.phx.gbl... Tom,
Maybe you feel this way at this point in your career. Maybe you only work
on small applications. But, like good architecture, your methodology
should be extensible. Extensibility, and ease of code maintenance are the
chief reasons for separating an app into separate tiers, and separating
HTML template layout markup from Page business logic. At some point,
hopefully, you will work on large-scale apps, and/or work in a team, and I
hope your methodology can accomodate the new situation when and if it
comes.
Actually, I have been around for a long time and have rarely found a "best"
way for anything. Most times there are best ways depending on the
situation. There is a saying: give a programming task to 100 programmers
and you will get 100 programs. Some will be bad, but there will not be a
"best", but many good programs.
I am not saying that breaking an app into separate tiers is not the good way
for the situation you mention, but it is not a Panacea for all situations,
either.
I agree that breaking up code into objects and libraries is a good idea (and
I do it all the time) - but not for everything.
I am just trying to see the pluses and minuses I may not have come up with,
before I go in one direction or the other.
Always a good methodology.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:u6**************@TK2MSFTNGP11.phx.gbl... Please read the thread with subject :
"What's the difference/advantages
between code behind and code inside?
I did and added my 2 cents worth - which is about all I can handle at
this point.
So far, I've determined that there really is no discernable benefit from
going from code-inside to code-behind (other than to use VS) or are
trying to hide the source if deploying the application. It really is a
matter of preference. Not a better way to code - as was mentioned.
Thanks,
Tom
The separation happens whether or not you use code-behind
Juan T. Llibre
ASP.NET MVP
===========
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl...
I am just trying to decide whether to split my code and uses code
behind. I did it with one of my pages and found it was quite a bit of
trouble.
I know that most people (and books and articles) like it because you
can split the code from the design. That is logical. But if you are
the only one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page
to define it there. If I was working with multiple people on a page, I
would need to run over to the person working on the codebehind and tell
him to add the new object to his page.
Things that are assumed on the .aspx page are not assumed on the
codebehind and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned.
Normally, you are told that it is better. Is this the case in all
situations?
Just trying to get other opinions on this, as I have already have about
30 pages designed and am trying to decide if I should split the files
or not.
Thanks,
Tom
> Actually, I have been around for a long time and have rarely found a "best" way for anything. Most times there are best ways depending on the
situation. There is a saying: give a programming task to 100 programmers
and you will get 100 programs. Some will be bad, but there will not be a
"best", but many good programs.
I have to disagree. There are many ways to write a program, but only ONE
best way. If you don't shoot for it, you'll never get close.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:e1**************@TK2MSFTNGP14.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O0**************@TK2MSFTNGP11.phx.gbl... Tom,
Maybe you feel this way at this point in your career. Maybe you only work
on small applications. But, like good architecture, your methodology
should be extensible. Extensibility, and ease of code maintenance are the
chief reasons for separating an app into separate tiers, and separating
HTML template layout markup from Page business logic. At some point,
hopefully, you will work on large-scale apps, and/or work in a team, and
I hope your methodology can accomodate the new situation when and if it
comes.
Actually, I have been around for a long time and have rarely found a
"best" way for anything. Most times there are best ways depending on the
situation. There is a saying: give a programming task to 100 programmers
and you will get 100 programs. Some will be bad, but there will not be a
"best", but many good programs.
I am not saying that breaking an app into separate tiers is not the good
way for the situation you mention, but it is not a Panacea for all
situations, either.
I agree that breaking up code into objects and libraries is a good idea
(and I do it all the time) - but not for everything.
I am just trying to see the pluses and minuses I may not have come up
with, before I go in one direction or the other.
Always a good methodology.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:u6**************@TK2MSFTNGP11.phx.gbl...
Please read the thread with subject :
"What's the difference/advantages
between code behind and code inside?
I did and added my 2 cents worth - which is about all I can handle at
this point.
So far, I've determined that there really is no discernable benefit from
going from code-inside to code-behind (other than to use VS) or are
trying to hide the source if deploying the application. It really is a
matter of preference. Not a better way to code - as was mentioned.
Thanks,
Tom
The separation happens whether or not you use code-behind
Juan T. Llibre
ASP.NET MVP
===========
"tshad" <ts**********@ftsolutions.com> wrote in message
news:em**************@TK2MSFTNGP11.phx.gbl...
>I am just trying to decide whether to split my code and uses code
>behind. I did it with one of my pages and found it was quite a bit of
>trouble.
>
> I know that most people (and books and articles) like it because you
> can split the code from the design. That is logical. But if you are
> the only one working on the code, it seem a little overkill.
>
> I use Dreamweaver to do my design and find it a bit of a hassle to
> have multiple files open for each of my pages as I am working on them.
> I typically have 3 or 4 pages open at one time that I am working on
> which translates into 6-8 files open.
>
> If I add an object to my design page I need to go the codebehind page
> to define it there. If I was working with multiple people on a page,
> I would need to run over to the person working on the codebehind and
> tell him to add the new object to his page.
>
> Things that are assumed on the .aspx page are not assumed on the
> codebehind and have to be explicitly defined.
>
> None of this is really talked about when codebehind is mentioned.
> Normally, you are told that it is better. Is this the case in all
> situations?
>
> Just trying to get other opinions on this, as I have already have
> about 30 pages designed and am trying to decide if I should split the
> files or not.
>
> Thanks,
>
> Tom
>
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O4**************@TK2MSFTNGP12.phx.gbl... Actually, I have been around for a long time and have rarely found a
"best" way for anything. Most times there are best ways depending on the
situation. There is a saying: give a programming task to 100 programmers
and you will get 100 programs. Some will be bad, but there will not be a
"best", but many good programs.
I have to disagree. There are many ways to write a program, but only ONE
best way.
Based on who?
If I have a choice between the most efficient and the most readable and
maintainable - the best way is not necessarily going to be the same.
Programming has evolved over the years with "many" best ways and there are
differing arguments on what is the best. Just as you have disagreements on
whether MS is better than Linux or a Ferrari is better than a Volkswagon.
It depends on your situation.
You look at your options and pick the best based on your needs and
resources.
If you don't shoot for it, you'll never get close.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:e1**************@TK2MSFTNGP14.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O0**************@TK2MSFTNGP11.phx.gbl... Tom,
Maybe you feel this way at this point in your career. Maybe you only
work on small applications. But, like good architecture, your
methodology should be extensible. Extensibility, and ease of code
maintenance are the chief reasons for separating an app into separate
tiers, and separating HTML template layout markup from Page business
logic. At some point, hopefully, you will work on large-scale apps,
and/or work in a team, and I hope your methodology can accomodate the
new situation when and if it comes.
Actually, I have been around for a long time and have rarely found a
"best" way for anything. Most times there are best ways depending on the
situation. There is a saying: give a programming task to 100 programmers
and you will get 100 programs. Some will be bad, but there will not be a
"best", but many good programs.
I am not saying that breaking an app into separate tiers is not the good
way for the situation you mention, but it is not a Panacea for all
situations, either.
I agree that breaking up code into objects and libraries is a good idea
(and I do it all the time) - but not for everything.
I am just trying to see the pluses and minuses I may not have come up
with, before I go in one direction or the other.
Always a good methodology.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:u6**************@TK2MSFTNGP11.phx.gbl...
> Please read the thread with subject :
>
> "What's the difference/advantages
> between code behind and code inside?
I did and added my 2 cents worth - which is about all I can handle at
this point.
So far, I've determined that there really is no discernable benefit
from going from code-inside to code-behind (other than to use VS) or
are trying to hide the source if deploying the application. It really
is a matter of preference. Not a better way to code - as was
mentioned.
Thanks,
Tom
The separation happens whether or not you use code-behind
>
>
>
> Juan T. Llibre
> ASP.NET MVP
> ===========
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:em**************@TK2MSFTNGP11.phx.gbl...
>>I am just trying to decide whether to split my code and uses code
>>behind. I did it with one of my pages and found it was quite a bit of
>>trouble.
>>
>> I know that most people (and books and articles) like it because you
>> can split the code from the design. That is logical. But if you are
>> the only one working on the code, it seem a little overkill.
>>
>> I use Dreamweaver to do my design and find it a bit of a hassle to
>> have multiple files open for each of my pages as I am working on
>> them. I typically have 3 or 4 pages open at one time that I am
>> working on which translates into 6-8 files open.
>>
>> If I add an object to my design page I need to go the codebehind page
>> to define it there. If I was working with multiple people on a page,
>> I would need to run over to the person working on the codebehind and
>> tell him to add the new object to his page.
>>
>> Things that are assumed on the .aspx page are not assumed on the
>> codebehind and have to be explicitly defined.
>>
>> None of this is really talked about when codebehind is mentioned.
>> Normally, you are told that it is better. Is this the case in all
>> situations?
>>
>> Just trying to get other opinions on this, as I have already have
>> about 30 pages designed and am trying to decide if I should split the
>> files or not.
>>
>> Thanks,
>>
>> Tom
>>
>
>
> You look at your options and pick the best based on your needs and resources.
Didn't you just say that there wasn't a "best?"
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uz**************@TK2MSFTNGP11.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O4**************@TK2MSFTNGP12.phx.gbl... Actually, I have been around for a long time and have rarely found a
"best" way for anything. Most times there are best ways depending on
the situation. There is a saying: give a programming task to 100
programmers and you will get 100 programs. Some will be bad, but there
will not be a "best", but many good programs.
I have to disagree. There are many ways to write a program, but only ONE
best way.
Based on who?
If I have a choice between the most efficient and the most readable and
maintainable - the best way is not necessarily going to be the same.
Programming has evolved over the years with "many" best ways and there are
differing arguments on what is the best. Just as you have disagreements
on whether MS is better than Linux or a Ferrari is better than a
Volkswagon. It depends on your situation.
You look at your options and pick the best based on your needs and
resources.
If you don't shoot for it, you'll never get close.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:e1**************@TK2MSFTNGP14.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O0**************@TK2MSFTNGP11.phx.gbl...
Tom,
Maybe you feel this way at this point in your career. Maybe you only
work on small applications. But, like good architecture, your
methodology should be extensible. Extensibility, and ease of code
maintenance are the chief reasons for separating an app into separate
tiers, and separating HTML template layout markup from Page business
logic. At some point, hopefully, you will work on large-scale apps,
and/or work in a team, and I hope your methodology can accomodate the
new situation when and if it comes.
Actually, I have been around for a long time and have rarely found a
"best" way for anything. Most times there are best ways depending on
the situation. There is a saying: give a programming task to 100
programmers and you will get 100 programs. Some will be bad, but there
will not be a "best", but many good programs.
I am not saying that breaking an app into separate tiers is not the good
way for the situation you mention, but it is not a Panacea for all
situations, either.
I agree that breaking up code into objects and libraries is a good idea
(and I do it all the time) - but not for everything.
I am just trying to see the pluses and minuses I may not have come up
with, before I go in one direction or the other.
Always a good methodology.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
> news:u6**************@TK2MSFTNGP11.phx.gbl...
>> Please read the thread with subject :
>>
>> "What's the difference/advantages
>> between code behind and code inside?
>
> I did and added my 2 cents worth - which is about all I can handle at
> this point.
>
> So far, I've determined that there really is no discernable benefit
> from going from code-inside to code-behind (other than to use VS) or
> are trying to hide the source if deploying the application. It really
> is a matter of preference. Not a better way to code - as was
> mentioned.
>
> Thanks,
>
> Tom
>
> The separation happens whether or not you use code-behind
>>
>>
>>
>> Juan T. Llibre
>> ASP.NET MVP
>> ===========
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>I am just trying to decide whether to split my code and uses code
>>>behind. I did it with one of my pages and found it was quite a bit of
>>>trouble.
>>>
>>> I know that most people (and books and articles) like it because you
>>> can split the code from the design. That is logical. But if you
>>> are the only one working on the code, it seem a little overkill.
>>>
>>> I use Dreamweaver to do my design and find it a bit of a hassle to
>>> have multiple files open for each of my pages as I am working on
>>> them. I typically have 3 or 4 pages open at one time that I am
>>> working on which translates into 6-8 files open.
>>>
>>> If I add an object to my design page I need to go the codebehind
>>> page to define it there. If I was working with multiple people on a
>>> page, I would need to run over to the person working on the
>>> codebehind and tell him to add the new object to his page.
>>>
>>> Things that are assumed on the .aspx page are not assumed on the
>>> codebehind and have to be explicitly defined.
>>>
>>> None of this is really talked about when codebehind is mentioned.
>>> Normally, you are told that it is better. Is this the case in all
>>> situations?
>>>
>>> Just trying to get other opinions on this, as I have already have
>>> about 30 pages designed and am trying to decide if I should split
>>> the files or not.
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>
>>
>
>
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u6**************@TK2MSFTNGP10.phx.gbl... You look at your options and pick the best based on your needs and
resources.
Didn't you just say that there wasn't a "best?"
No. You said that. You said there is only ONE Best way.
I said there are many ways. As I said - "best based on your needs and
resources". What is best for me is not necessarily what is best for you.
Back to my car scenario.
Let's say I have a small income. Therefore, the Ferrari is not the Best car
for me.
My only point here is that you can't say that one thing (whatever that is)
is the best for everyone.
I agree with you that structure is the better way over non structured. But
you can be structured without splitting files. That is what code-inside
asp.net has over asp.
You can write very bad code using separate files and really good code-inside
files. Splitting the files doesn't make it better code.
Just because you can DO something doesn't mean you SHOULD do something.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uz**************@TK2MSFTNGP11.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O4**************@TK2MSFTNGP12.phx.gbl... Actually, I have been around for a long time and have rarely found a
"best" way for anything. Most times there are best ways depending on
the situation. There is a saying: give a programming task to 100
programmers and you will get 100 programs. Some will be bad, but there
will not be a "best", but many good programs.
I have to disagree. There are many ways to write a program, but only ONE
best way.
Based on who?
If I have a choice between the most efficient and the most readable and
maintainable - the best way is not necessarily going to be the same.
Programming has evolved over the years with "many" best ways and there
are differing arguments on what is the best. Just as you have
disagreements on whether MS is better than Linux or a Ferrari is better
than a Volkswagon. It depends on your situation.
You look at your options and pick the best based on your needs and
resources.
If you don't shoot for it, you'll never get close.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:e1**************@TK2MSFTNGP14.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O0**************@TK2MSFTNGP11.phx.gbl...
> Tom,
>
> Maybe you feel this way at this point in your career. Maybe you only
> work on small applications. But, like good architecture, your
> methodology should be extensible. Extensibility, and ease of code
> maintenance are the chief reasons for separating an app into separate
> tiers, and separating HTML template layout markup from Page business
> logic. At some point, hopefully, you will work on large-scale apps,
> and/or work in a team, and I hope your methodology can accomodate the
> new situation when and if it comes.
Actually, I have been around for a long time and have rarely found a
"best" way for anything. Most times there are best ways depending on
the situation. There is a saying: give a programming task to 100
programmers and you will get 100 programs. Some will be bad, but there
will not be a "best", but many good programs.
I am not saying that breaking an app into separate tiers is not the
good way for the situation you mention, but it is not a Panacea for all
situations, either.
I agree that breaking up code into objects and libraries is a good idea
(and I do it all the time) - but not for everything.
I am just trying to see the pluses and minuses I may not have come up
with, before I go in one direction or the other.
Always a good methodology.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:%2******************@tk2msftngp13.phx.gbl...
>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>> news:u6**************@TK2MSFTNGP11.phx.gbl...
>>> Please read the thread with subject :
>>>
>>> "What's the difference/advantages
>>> between code behind and code inside?
>>
>> I did and added my 2 cents worth - which is about all I can handle at
>> this point.
>>
>> So far, I've determined that there really is no discernable benefit
>> from going from code-inside to code-behind (other than to use VS) or
>> are trying to hide the source if deploying the application. It
>> really is a matter of preference. Not a better way to code - as was
>> mentioned.
>>
>> Thanks,
>>
>> Tom
>>
>> The separation happens whether or not you use code-behind
>>>
>>>
>>>
>>> Juan T. Llibre
>>> ASP.NET MVP
>>> ===========
>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>>I am just trying to decide whether to split my code and uses code
>>>>behind. I did it with one of my pages and found it was quite a bit
>>>>of trouble.
>>>>
>>>> I know that most people (and books and articles) like it because
>>>> you can split the code from the design. That is logical. But if
>>>> you are the only one working on the code, it seem a little
>>>> overkill.
>>>>
>>>> I use Dreamweaver to do my design and find it a bit of a hassle to
>>>> have multiple files open for each of my pages as I am working on
>>>> them. I typically have 3 or 4 pages open at one time that I am
>>>> working on which translates into 6-8 files open.
>>>>
>>>> If I add an object to my design page I need to go the codebehind
>>>> page to define it there. If I was working with multiple people on
>>>> a page, I would need to run over to the person working on the
>>>> codebehind and tell him to add the new object to his page.
>>>>
>>>> Things that are assumed on the .aspx page are not assumed on the
>>>> codebehind and have to be explicitly defined.
>>>>
>>>> None of this is really talked about when codebehind is mentioned.
>>>> Normally, you are told that it is better. Is this the case in all
>>>> situations?
>>>>
>>>> Just trying to get other opinions on this, as I have already have
>>>> about 30 pages designed and am trying to decide if I should split
>>>> the files or not.
>>>>
>>>> Thanks,
>>>>
>>>> Tom
>>>>
>>>
>>>
>>
>>
>
>
> No. You said that. You said there is only ONE Best way.
Nope. YOU said "THE best" - the definite article indicates a singular
reference.
--
;-),
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u6**************@TK2MSFTNGP10.phx.gbl... You look at your options and pick the best based on your needs and
resources.
Didn't you just say that there wasn't a "best?"
No. You said that. You said there is only ONE Best way.
I said there are many ways. As I said - "best based on your needs and
resources". What is best for me is not necessarily what is best for you.
Back to my car scenario.
Let's say I have a small income. Therefore, the Ferrari is not the Best
car for me.
My only point here is that you can't say that one thing (whatever that is)
is the best for everyone.
I agree with you that structure is the better way over non structured.
But you can be structured without splitting files. That is what
code-inside asp.net has over asp.
You can write very bad code using separate files and really good
code-inside files. Splitting the files doesn't make it better code.
Just because you can DO something doesn't mean you SHOULD do something.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uz**************@TK2MSFTNGP11.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O4**************@TK2MSFTNGP12.phx.gbl...
> Actually, I have been around for a long time and have rarely found a
> "best" way for anything. Most times there are best ways depending on
> the situation. There is a saying: give a programming task to 100
> programmers and you will get 100 programs. Some will be bad, but
> there will not be a "best", but many good programs.
>
I have to disagree. There are many ways to write a program, but only
ONE best way.
Based on who?
If I have a choice between the most efficient and the most readable and
maintainable - the best way is not necessarily going to be the same.
Programming has evolved over the years with "many" best ways and there
are differing arguments on what is the best. Just as you have
disagreements on whether MS is better than Linux or a Ferrari is better
than a Volkswagon. It depends on your situation.
You look at your options and pick the best based on your needs and
resources.
If you don't shoot for it, you'll never get close.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:e1**************@TK2MSFTNGP14.phx.gbl...
> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:O0**************@TK2MSFTNGP11.phx.gbl...
>> Tom,
>>
>> Maybe you feel this way at this point in your career. Maybe you only
>> work on small applications. But, like good architecture, your
>> methodology should be extensible. Extensibility, and ease of code
>> maintenance are the chief reasons for separating an app into separate
>> tiers, and separating HTML template layout markup from Page business
>> logic. At some point, hopefully, you will work on large-scale apps,
>> and/or work in a team, and I hope your methodology can accomodate the
>> new situation when and if it comes.
>
> Actually, I have been around for a long time and have rarely found a
> "best" way for anything. Most times there are best ways depending on
> the situation. There is a saying: give a programming task to 100
> programmers and you will get 100 programs. Some will be bad, but
> there will not be a "best", but many good programs.
>
> I am not saying that breaking an app into separate tiers is not the
> good way for the situation you mention, but it is not a Panacea for
> all situations, either.
>
> I agree that breaking up code into objects and libraries is a good
> idea (and I do it all the time) - but not for everything.
>
> I am just trying to see the pluses and minuses I may not have come up
> with, before I go in one direction or the other.
>
> Always a good methodology.
>
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> Neither a follower nor a lender be.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:%2******************@tk2msftngp13.phx.gbl...
>>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>>> news:u6**************@TK2MSFTNGP11.phx.gbl...
>>>> Please read the thread with subject :
>>>>
>>>> "What's the difference/advantages
>>>> between code behind and code inside?
>>>
>>> I did and added my 2 cents worth - which is about all I can handle
>>> at this point.
>>>
>>> So far, I've determined that there really is no discernable benefit
>>> from going from code-inside to code-behind (other than to use VS) or
>>> are trying to hide the source if deploying the application. It
>>> really is a matter of preference. Not a better way to code - as was
>>> mentioned.
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>> The separation happens whether or not you use code-behind
>>>>
>>>>
>>>>
>>>> Juan T. Llibre
>>>> ASP.NET MVP
>>>> ===========
>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>>>I am just trying to decide whether to split my code and uses code
>>>>>behind. I did it with one of my pages and found it was quite a bit
>>>>>of trouble.
>>>>>
>>>>> I know that most people (and books and articles) like it because
>>>>> you can split the code from the design. That is logical. But if
>>>>> you are the only one working on the code, it seem a little
>>>>> overkill.
>>>>>
>>>>> I use Dreamweaver to do my design and find it a bit of a hassle to
>>>>> have multiple files open for each of my pages as I am working on
>>>>> them. I typically have 3 or 4 pages open at one time that I am
>>>>> working on which translates into 6-8 files open.
>>>>>
>>>>> If I add an object to my design page I need to go the codebehind
>>>>> page to define it there. If I was working with multiple people on
>>>>> a page, I would need to run over to the person working on the
>>>>> codebehind and tell him to add the new object to his page.
>>>>>
>>>>> Things that are assumed on the .aspx page are not assumed on the
>>>>> codebehind and have to be explicitly defined.
>>>>>
>>>>> None of this is really talked about when codebehind is mentioned.
>>>>> Normally, you are told that it is better. Is this the case in all
>>>>> situations?
>>>>>
>>>>> Just trying to get other opinions on this, as I have already have
>>>>> about 30 pages designed and am trying to decide if I should split
>>>>> the files or not.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Tom
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uY****************@TK2MSFTNGP09.phx.gbl... No. You said that. You said there is only ONE Best way.
Nope. YOU said "THE best" - the definite article indicates a singular
reference.
Only if you take it out of context - as you did.
"If I have a choice between the most efficient and the most readable and
maintainable - "the best" way is not necessarily going to be the same"
Not singular here.
"My only point here is that you can't say that one thing (whatever that is)
is "the best" for everyone."
Not here.
"You look at your options and pick "the best" based on your needs and
resources."
Not here, either.
Also, "the best" can change as circumstances change. (not singular) :)
--
;-),
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u6**************@TK2MSFTNGP10.phx.gbl... You look at your options and pick the best based on your needs and
resources.
Didn't you just say that there wasn't a "best?"
No. You said that. You said there is only ONE Best way.
I said there are many ways. As I said - "best based on your needs and
resources". What is best for me is not necessarily what is best for you.
Back to my car scenario.
Let's say I have a small income. Therefore, the Ferrari is not the Best
car for me.
My only point here is that you can't say that one thing (whatever that
is) is the best for everyone.
I agree with you that structure is the better way over non structured.
But you can be structured without splitting files. That is what
code-inside asp.net has over asp.
You can write very bad code using separate files and really good
code-inside files. Splitting the files doesn't make it better code.
Just because you can DO something doesn't mean you SHOULD do something.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uz**************@TK2MSFTNGP11.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:O4**************@TK2MSFTNGP12.phx.gbl...
>> Actually, I have been around for a long time and have rarely found a
>> "best" way for anything. Most times there are best ways depending on
>> the situation. There is a saying: give a programming task to 100
>> programmers and you will get 100 programs. Some will be bad, but
>> there will not be a "best", but many good programs.
>>
>
> I have to disagree. There are many ways to write a program, but only
> ONE best way.
Based on who?
If I have a choice between the most efficient and the most readable and
maintainable - the best way is not necessarily going to be the same.
Programming has evolved over the years with "many" best ways and there
are differing arguments on what is the best. Just as you have
disagreements on whether MS is better than Linux or a Ferrari is better
than a Volkswagon. It depends on your situation.
You look at your options and pick the best based on your needs and
resources.
> If you don't shoot for it, you'll never get close.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:e1**************@TK2MSFTNGP14.phx.gbl...
>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> news:O0**************@TK2MSFTNGP11.phx.gbl...
>>> Tom,
>>>
>>> Maybe you feel this way at this point in your career. Maybe you only
>>> work on small applications. But, like good architecture, your
>>> methodology should be extensible. Extensibility, and ease of code
>>> maintenance are the chief reasons for separating an app into
>>> separate tiers, and separating HTML template layout markup from Page
>>> business logic. At some point, hopefully, you will work on
>>> large-scale apps, and/or work in a team, and I hope your methodology
>>> can accomodate the new situation when and if it comes.
>>
>> Actually, I have been around for a long time and have rarely found a
>> "best" way for anything. Most times there are best ways depending on
>> the situation. There is a saying: give a programming task to 100
>> programmers and you will get 100 programs. Some will be bad, but
>> there will not be a "best", but many good programs.
>>
>> I am not saying that breaking an app into separate tiers is not the
>> good way for the situation you mention, but it is not a Panacea for
>> all situations, either.
>>
>> I agree that breaking up code into objects and libraries is a good
>> idea (and I do it all the time) - but not for everything.
>>
>> I am just trying to see the pluses and minuses I may not have come up
>> with, before I go in one direction or the other.
>>
>> Always a good methodology.
>>
>>>
>>> --
>>> HTH,
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> .Net Developer
>>> Neither a follower nor a lender be.
>>>
>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>> news:%2******************@tk2msftngp13.phx.gbl...
>>>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>>>> news:u6**************@TK2MSFTNGP11.phx.gbl...
>>>>> Please read the thread with subject :
>>>>>
>>>>> "What's the difference/advantages
>>>>> between code behind and code inside?
>>>>
>>>> I did and added my 2 cents worth - which is about all I can handle
>>>> at this point.
>>>>
>>>> So far, I've determined that there really is no discernable benefit
>>>> from going from code-inside to code-behind (other than to use VS)
>>>> or are trying to hide the source if deploying the application. It
>>>> really is a matter of preference. Not a better way to code - as
>>>> was mentioned.
>>>>
>>>> Thanks,
>>>>
>>>> Tom
>>>>
>>>> The separation happens whether or not you use code-behind
>>>>>
>>>>>
>>>>>
>>>>> Juan T. Llibre
>>>>> ASP.NET MVP
>>>>> ===========
>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>>>>I am just trying to decide whether to split my code and uses code
>>>>>>behind. I did it with one of my pages and found it was quite a bit
>>>>>>of trouble.
>>>>>>
>>>>>> I know that most people (and books and articles) like it because
>>>>>> you can split the code from the design. That is logical. But if
>>>>>> you are the only one working on the code, it seem a little
>>>>>> overkill.
>>>>>>
>>>>>> I use Dreamweaver to do my design and find it a bit of a hassle
>>>>>> to have multiple files open for each of my pages as I am working
>>>>>> on them. I typically have 3 or 4 pages open at one time that I am
>>>>>> working on which translates into 6-8 files open.
>>>>>>
>>>>>> If I add an object to my design page I need to go the codebehind
>>>>>> page to define it there. If I was working with multiple people
>>>>>> on a page, I would need to run over to the person working on the
>>>>>> codebehind and tell him to add the new object to his page.
>>>>>>
>>>>>> Things that are assumed on the .aspx page are not assumed on the
>>>>>> codebehind and have to be explicitly defined.
>>>>>>
>>>>>> None of this is really talked about when codebehind is mentioned.
>>>>>> Normally, you are told that it is better. Is this the case in
>>>>>> all situations?
>>>>>>
>>>>>> Just trying to get other opinions on this, as I have already have
>>>>>> about 30 pages designed and am trying to decide if I should split
>>>>>> the files or not.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
By the time you two settle this partial classes might be 4 years old...
I always find quoting the simpsons in such matters helpful:
"And so, Gary Coleman and the Simpsons argued long into the night, and
then, as day broke, the spirit of the season entered their hearts.
'Lets just agree that the commercialization of Christmas is, at best, a
mixed blessing' "
--
MY ASP.Net tutorials http://www.openmymind.net/
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OB**************@TK2MSFTNGP11.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uY****************@TK2MSFTNGP09.phx.gbl... No. You said that. You said there is only ONE Best way.
Nope. YOU said "THE best" - the definite article indicates a singular
reference.
Only if you take it out of context - as you did.
"If I have a choice between the most efficient and the most readable and
maintainable - "the best" way is not necessarily going to be the same"
Not singular here.
"My only point here is that you can't say that one thing (whatever that
is) is "the best" for everyone."
Not here.
"You look at your options and pick "the best" based on your needs and
resources."
Not here, either.
Also, "the best" can change as circumstances change. (not singular) :)
--
;-),
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u6**************@TK2MSFTNGP10.phx.gbl...
> You look at your options and pick the best based on your needs and
> resources.
Didn't you just say that there wasn't a "best?"
No. You said that. You said there is only ONE Best way.
I said there are many ways. As I said - "best based on your needs and
resources". What is best for me is not necessarily what is best for
you.
Back to my car scenario.
Let's say I have a small income. Therefore, the Ferrari is not the
Best car for me.
My only point here is that you can't say that one thing (whatever that
is) is the best for everyone.
I agree with you that structure is the better way over non structured.
But you can be structured without splitting files. That is what
code-inside asp.net has over asp.
You can write very bad code using separate files and really good
code-inside files. Splitting the files doesn't make it better code.
Just because you can DO something doesn't mean you SHOULD do something.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uz**************@TK2MSFTNGP11.phx.gbl...
> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:O4**************@TK2MSFTNGP12.phx.gbl...
>>> Actually, I have been around for a long time and have rarely found
a>>> "best" way for anything. Most times there are best ways depending
on>>> the situation. There is a saying: give a programming task to 100
>>> programmers and you will get 100 programs. Some will be bad, but
>>> there will not be a "best", but many good programs.
>>>
>>
>> I have to disagree. There are many ways to write a program, but only
>> ONE best way.
>
> Based on who?
>
> If I have a choice between the most efficient and the most readable
and> maintainable - the best way is not necessarily going to be the same.
>
> Programming has evolved over the years with "many" best ways and
there> are differing arguments on what is the best. Just as you have
> disagreements on whether MS is better than Linux or a Ferrari is
better> than a Volkswagon. It depends on your situation.
>
> You look at your options and pick the best based on your needs and
> resources.
>
>> If you don't shoot for it, you'll never get close.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> Neither a follower nor a lender be.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:e1**************@TK2MSFTNGP14.phx.gbl...
>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>>> news:O0**************@TK2MSFTNGP11.phx.gbl...
>>>> Tom,
>>>>
>>>> Maybe you feel this way at this point in your career. Maybe you
only>>>> work on small applications. But, like good architecture, your
>>>> methodology should be extensible. Extensibility, and ease of code
>>>> maintenance are the chief reasons for separating an app into
>>>> separate tiers, and separating HTML template layout markup from
Page>>>> business logic. At some point, hopefully, you will work on
>>>> large-scale apps, and/or work in a team, and I hope your
methodology>>>> can accomodate the new situation when and if it comes.
>>>
>>> Actually, I have been around for a long time and have rarely found
a>>> "best" way for anything. Most times there are best ways depending
on>>> the situation. There is a saying: give a programming task to 100
>>> programmers and you will get 100 programs. Some will be bad, but
>>> there will not be a "best", but many good programs.
>>>
>>> I am not saying that breaking an app into separate tiers is not the
>>> good way for the situation you mention, but it is not a Panacea for
>>> all situations, either.
>>>
>>> I agree that breaking up code into objects and libraries is a good
>>> idea (and I do it all the time) - but not for everything.
>>>
>>> I am just trying to see the pluses and minuses I may not have come
up>>> with, before I go in one direction or the other.
>>>
>>> Always a good methodology.
>>>
>>>>
>>>> --
>>>> HTH,
>>>>
>>>> Kevin Spencer
>>>> Microsoft MVP
>>>> .Net Developer
>>>> Neither a follower nor a lender be.
>>>>
>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>> news:%2******************@tk2msftngp13.phx.gbl...
>>>>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>>>>> news:u6**************@TK2MSFTNGP11.phx.gbl...
>>>>>> Please read the thread with subject :
>>>>>>
>>>>>> "What's the difference/advantages
>>>>>> between code behind and code inside?
>>>>>
>>>>> I did and added my 2 cents worth - which is about all I can
handle>>>>> at this point.
>>>>>
>>>>> So far, I've determined that there really is no discernable
benefit>>>>> from going from code-inside to code-behind (other than to use VS)
>>>>> or are trying to hide the source if deploying the application.
It>>>>> really is a matter of preference. Not a better way to code - as
>>>>> was mentioned.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Tom
>>>>>
>>>>> The separation happens whether or not you use code-behind
>>>>>>
>>>>>>
>>>>>>
>>>>>> Juan T. Llibre
>>>>>> ASP.NET MVP
>>>>>> ===========
>>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>>>>>I am just trying to decide whether to split my code and uses
code>>>>>>>behind. I did it with one of my pages and found it was quite a
bit>>>>>>>of trouble.
>>>>>>>
>>>>>>> I know that most people (and books and articles) like it
because>>>>>>> you can split the code from the design. That is logical. But
if>>>>>>> you are the only one working on the code, it seem a little
>>>>>>> overkill.
>>>>>>>
>>>>>>> I use Dreamweaver to do my design and find it a bit of a hassle
>>>>>>> to have multiple files open for each of my pages as I am
working>>>>>>> on them. I typically have 3 or 4 pages open at one time that I
am>>>>>>> working on which translates into 6-8 files open.
>>>>>>>
>>>>>>> If I add an object to my design page I need to go the
codebehind>>>>>>> page to define it there. If I was working with multiple people
>>>>>>> on a page, I would need to run over to the person working on
the>>>>>>> codebehind and tell him to add the new object to his page.
>>>>>>>
>>>>>>> Things that are assumed on the .aspx page are not assumed on
the>>>>>>> codebehind and have to be explicitly defined.
>>>>>>>
>>>>>>> None of this is really talked about when codebehind is
mentioned.>>>>>>> Normally, you are told that it is better. Is this the case in
>>>>>>> all situations?
>>>>>>>
>>>>>>> Just trying to get other opinions on this, as I have already
have>>>>>>> about 30 pages designed and am trying to decide if I should
split>>>>>>> the files or not.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:uK**************@tk2msftngp13.phx.gbl... By the time you two settle this partial classes might be 4 years old...
I always find quoting the simpsons in such matters helpful:
"And so, Gary Coleman and the Simpsons argued long into the night, and
then, as day broke, the spirit of the season entered their hearts.
'Lets just agree that the commercialization of Christmas is, at best, a
mixed blessing' "
I agree, but then you miss the fun :)
Tom
--
MY ASP.Net tutorials
http://www.openmymind.net/
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OB**************@TK2MSFTNGP11.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uY****************@TK2MSFTNGP09.phx.gbl... >> No. You said that. You said there is only ONE Best way.
>
> Nope. YOU said "THE best" - the definite article indicates a singular
> reference.
Only if you take it out of context - as you did.
"If I have a choice between the most efficient and the most readable and
maintainable - "the best" way is not necessarily going to be the same"
Not singular here.
"My only point here is that you can't say that one thing (whatever that
is) is "the best" for everyone."
Not here.
"You look at your options and pick "the best" based on your needs and
resources."
Not here, either.
Also, "the best" can change as circumstances change. (not singular) :) >
> --
> ;-),
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:uj**************@TK2MSFTNGP09.phx.gbl...
>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> news:u6**************@TK2MSFTNGP10.phx.gbl...
>>>> You look at your options and pick the best based on your needs and
>>>> resources.
>>>
>>> Didn't you just say that there wasn't a "best?"
>>
>> No. You said that. You said there is only ONE Best way.
>>
>> I said there are many ways. As I said - "best based on your needs and
>> resources". What is best for me is not necessarily what is best for you. >>
>> Back to my car scenario.
>>
>> Let's say I have a small income. Therefore, the Ferrari is not the Best >> car for me.
>>
>> My only point here is that you can't say that one thing (whatever that
>> is) is the best for everyone.
>>
>> I agree with you that structure is the better way over non structured.
>> But you can be structured without splitting files. That is what
>> code-inside asp.net has over asp.
>>
>> You can write very bad code using separate files and really good
>> code-inside files. Splitting the files doesn't make it better code.
>>
>> Just because you can DO something doesn't mean you SHOULD do
>> something.
>>>
>>> --
>>> HTH,
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> .Net Developer
>>> Neither a follower nor a lender be.
>>>
>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>> news:uz**************@TK2MSFTNGP11.phx.gbl...
>>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>>>> news:O4**************@TK2MSFTNGP12.phx.gbl...
>>>>>> Actually, I have been around for a long time and have rarely found a >>>>>> "best" way for anything. Most times there are best ways depending on >>>>>> the situation. There is a saying: give a programming task to 100
>>>>>> programmers and you will get 100 programs. Some will be bad, but
>>>>>> there will not be a "best", but many good programs.
>>>>>>
>>>>>
>>>>> I have to disagree. There are many ways to write a program, but
>>>>> only
>>>>> ONE best way.
>>>>
>>>> Based on who?
>>>>
>>>> If I have a choice between the most efficient and the most readable and >>>> maintainable - the best way is not necessarily going to be the same.
>>>>
>>>> Programming has evolved over the years with "many" best ways and there >>>> are differing arguments on what is the best. Just as you have
>>>> disagreements on whether MS is better than Linux or a Ferrari is better >>>> than a Volkswagon. It depends on your situation.
>>>>
>>>> You look at your options and pick the best based on your needs and
>>>> resources.
>>>>
>>>>> If you don't shoot for it, you'll never get close.
>>>>>
>>>>> --
>>>>> HTH,
>>>>>
>>>>> Kevin Spencer
>>>>> Microsoft MVP
>>>>> .Net Developer
>>>>> Neither a follower nor a lender be.
>>>>>
>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>> news:e1**************@TK2MSFTNGP14.phx.gbl...
>>>>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>>>>>> message
>>>>>> news:O0**************@TK2MSFTNGP11.phx.gbl...
>>>>>>> Tom,
>>>>>>>
>>>>>>> Maybe you feel this way at this point in your career. Maybe you only >>>>>>> work on small applications. But, like good architecture, your
>>>>>>> methodology should be extensible. Extensibility, and ease of code
>>>>>>> maintenance are the chief reasons for separating an app into
>>>>>>> separate tiers, and separating HTML template layout markup from Page >>>>>>> business logic. At some point, hopefully, you will work on
>>>>>>> large-scale apps, and/or work in a team, and I hope your methodology >>>>>>> can accomodate the new situation when and if it comes.
>>>>>>
>>>>>> Actually, I have been around for a long time and have rarely found a >>>>>> "best" way for anything. Most times there are best ways depending on >>>>>> the situation. There is a saying: give a programming task to 100
>>>>>> programmers and you will get 100 programs. Some will be bad, but
>>>>>> there will not be a "best", but many good programs.
>>>>>>
>>>>>> I am not saying that breaking an app into separate tiers is not
>>>>>> the
>>>>>> good way for the situation you mention, but it is not a Panacea
>>>>>> for
>>>>>> all situations, either.
>>>>>>
>>>>>> I agree that breaking up code into objects and libraries is a good
>>>>>> idea (and I do it all the time) - but not for everything.
>>>>>>
>>>>>> I am just trying to see the pluses and minuses I may not have come up >>>>>> with, before I go in one direction or the other.
>>>>>>
>>>>>> Always a good methodology.
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> HTH,
>>>>>>>
>>>>>>> Kevin Spencer
>>>>>>> Microsoft MVP
>>>>>>> .Net Developer
>>>>>>> Neither a follower nor a lender be.
>>>>>>>
>>>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>>>> news:%2******************@tk2msftngp13.phx.gbl...
>>>>>>>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>>>>>>>> news:u6**************@TK2MSFTNGP11.phx.gbl...
>>>>>>>>> Please read the thread with subject :
>>>>>>>>>
>>>>>>>>> "What's the difference/advantages
>>>>>>>>> between code behind and code inside?
>>>>>>>>
>>>>>>>> I did and added my 2 cents worth - which is about all I can handle >>>>>>>> at this point.
>>>>>>>>
>>>>>>>> So far, I've determined that there really is no discernable benefit >>>>>>>> from going from code-inside to code-behind (other than to use
>>>>>>>> VS)
>>>>>>>> or are trying to hide the source if deploying the application. It >>>>>>>> really is a matter of preference. Not a better way to code - as
>>>>>>>> was mentioned.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> The separation happens whether or not you use code-behind
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Juan T. Llibre
>>>>>>>>> ASP.NET MVP
>>>>>>>>> ===========
>>>>>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>>>>>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>>>>>>>>I am just trying to decide whether to split my code and uses code >>>>>>>>>>behind. I did it with one of my pages and found it was quite a bit >>>>>>>>>>of trouble.
>>>>>>>>>>
>>>>>>>>>> I know that most people (and books and articles) like it because >>>>>>>>>> you can split the code from the design. That is logical. But if >>>>>>>>>> you are the only one working on the code, it seem a little
>>>>>>>>>> overkill.
>>>>>>>>>>
>>>>>>>>>> I use Dreamweaver to do my design and find it a bit of a
>>>>>>>>>> hassle
>>>>>>>>>> to have multiple files open for each of my pages as I am working >>>>>>>>>> on them. I typically have 3 or 4 pages open at one time that I am >>>>>>>>>> working on which translates into 6-8 files open.
>>>>>>>>>>
>>>>>>>>>> If I add an object to my design page I need to go the codebehind >>>>>>>>>> page to define it there. If I was working with multiple
>>>>>>>>>> people
>>>>>>>>>> on a page, I would need to run over to the person working on the >>>>>>>>>> codebehind and tell him to add the new object to his page.
>>>>>>>>>>
>>>>>>>>>> Things that are assumed on the .aspx page are not assumed on the >>>>>>>>>> codebehind and have to be explicitly defined.
>>>>>>>>>>
>>>>>>>>>> None of this is really talked about when codebehind is mentioned. >>>>>>>>>> Normally, you are told that it is better. Is this the case in
>>>>>>>>>> all situations?
>>>>>>>>>>
>>>>>>>>>> Just trying to get other opinions on this, as I have already have >>>>>>>>>> about 30 pages designed and am trying to decide if I should split >>>>>>>>>> the files or not.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Heck, Karl, I'm done. If he doesn't believe in "best" practices, it's his
loss. I did my best. ;-)
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:uK**************@tk2msftngp13.phx.gbl... By the time you two settle this partial classes might be 4 years old...
I always find quoting the simpsons in such matters helpful:
"And so, Gary Coleman and the Simpsons argued long into the night, and
then, as day broke, the spirit of the season entered their hearts.
'Lets just agree that the commercialization of Christmas is, at best, a
mixed blessing' "
--
MY ASP.Net tutorials
http://www.openmymind.net/
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OB**************@TK2MSFTNGP11.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uY****************@TK2MSFTNGP09.phx.gbl... >> No. You said that. You said there is only ONE Best way.
>
> Nope. YOU said "THE best" - the definite article indicates a singular
> reference.
Only if you take it out of context - as you did.
"If I have a choice between the most efficient and the most readable and
maintainable - "the best" way is not necessarily going to be the same"
Not singular here.
"My only point here is that you can't say that one thing (whatever that
is) is "the best" for everyone."
Not here.
"You look at your options and pick "the best" based on your needs and
resources."
Not here, either.
Also, "the best" can change as circumstances change. (not singular) :) >
> --
> ;-),
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:uj**************@TK2MSFTNGP09.phx.gbl...
>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> news:u6**************@TK2MSFTNGP10.phx.gbl...
>>>> You look at your options and pick the best based on your needs and
>>>> resources.
>>>
>>> Didn't you just say that there wasn't a "best?"
>>
>> No. You said that. You said there is only ONE Best way.
>>
>> I said there are many ways. As I said - "best based on your needs and
>> resources". What is best for me is not necessarily what is best for you. >>
>> Back to my car scenario.
>>
>> Let's say I have a small income. Therefore, the Ferrari is not the Best >> car for me.
>>
>> My only point here is that you can't say that one thing (whatever that
>> is) is the best for everyone.
>>
>> I agree with you that structure is the better way over non structured.
>> But you can be structured without splitting files. That is what
>> code-inside asp.net has over asp.
>>
>> You can write very bad code using separate files and really good
>> code-inside files. Splitting the files doesn't make it better code.
>>
>> Just because you can DO something doesn't mean you SHOULD do
>> something.
>>>
>>> --
>>> HTH,
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> .Net Developer
>>> Neither a follower nor a lender be.
>>>
>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>> news:uz**************@TK2MSFTNGP11.phx.gbl...
>>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>>>> news:O4**************@TK2MSFTNGP12.phx.gbl...
>>>>>> Actually, I have been around for a long time and have rarely found a >>>>>> "best" way for anything. Most times there are best ways depending on >>>>>> the situation. There is a saying: give a programming task to 100
>>>>>> programmers and you will get 100 programs. Some will be bad, but
>>>>>> there will not be a "best", but many good programs.
>>>>>>
>>>>>
>>>>> I have to disagree. There are many ways to write a program, but
>>>>> only
>>>>> ONE best way.
>>>>
>>>> Based on who?
>>>>
>>>> If I have a choice between the most efficient and the most readable and >>>> maintainable - the best way is not necessarily going to be the same.
>>>>
>>>> Programming has evolved over the years with "many" best ways and there >>>> are differing arguments on what is the best. Just as you have
>>>> disagreements on whether MS is better than Linux or a Ferrari is better >>>> than a Volkswagon. It depends on your situation.
>>>>
>>>> You look at your options and pick the best based on your needs and
>>>> resources.
>>>>
>>>>> If you don't shoot for it, you'll never get close.
>>>>>
>>>>> --
>>>>> HTH,
>>>>>
>>>>> Kevin Spencer
>>>>> Microsoft MVP
>>>>> .Net Developer
>>>>> Neither a follower nor a lender be.
>>>>>
>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>> news:e1**************@TK2MSFTNGP14.phx.gbl...
>>>>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>>>>>> message
>>>>>> news:O0**************@TK2MSFTNGP11.phx.gbl...
>>>>>>> Tom,
>>>>>>>
>>>>>>> Maybe you feel this way at this point in your career. Maybe you only >>>>>>> work on small applications. But, like good architecture, your
>>>>>>> methodology should be extensible. Extensibility, and ease of code
>>>>>>> maintenance are the chief reasons for separating an app into
>>>>>>> separate tiers, and separating HTML template layout markup from Page >>>>>>> business logic. At some point, hopefully, you will work on
>>>>>>> large-scale apps, and/or work in a team, and I hope your methodology >>>>>>> can accomodate the new situation when and if it comes.
>>>>>>
>>>>>> Actually, I have been around for a long time and have rarely found a >>>>>> "best" way for anything. Most times there are best ways depending on >>>>>> the situation. There is a saying: give a programming task to 100
>>>>>> programmers and you will get 100 programs. Some will be bad, but
>>>>>> there will not be a "best", but many good programs.
>>>>>>
>>>>>> I am not saying that breaking an app into separate tiers is not
>>>>>> the
>>>>>> good way for the situation you mention, but it is not a Panacea
>>>>>> for
>>>>>> all situations, either.
>>>>>>
>>>>>> I agree that breaking up code into objects and libraries is a good
>>>>>> idea (and I do it all the time) - but not for everything.
>>>>>>
>>>>>> I am just trying to see the pluses and minuses I may not have come up >>>>>> with, before I go in one direction or the other.
>>>>>>
>>>>>> Always a good methodology.
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> HTH,
>>>>>>>
>>>>>>> Kevin Spencer
>>>>>>> Microsoft MVP
>>>>>>> .Net Developer
>>>>>>> Neither a follower nor a lender be.
>>>>>>>
>>>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>>>> news:%2******************@tk2msftngp13.phx.gbl...
>>>>>>>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>>>>>>>> news:u6**************@TK2MSFTNGP11.phx.gbl...
>>>>>>>>> Please read the thread with subject :
>>>>>>>>>
>>>>>>>>> "What's the difference/advantages
>>>>>>>>> between code behind and code inside?
>>>>>>>>
>>>>>>>> I did and added my 2 cents worth - which is about all I can handle >>>>>>>> at this point.
>>>>>>>>
>>>>>>>> So far, I've determined that there really is no discernable benefit >>>>>>>> from going from code-inside to code-behind (other than to use
>>>>>>>> VS)
>>>>>>>> or are trying to hide the source if deploying the application. It >>>>>>>> really is a matter of preference. Not a better way to code - as
>>>>>>>> was mentioned.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> The separation happens whether or not you use code-behind
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Juan T. Llibre
>>>>>>>>> ASP.NET MVP
>>>>>>>>> ===========
>>>>>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>>>>>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>>>>>>>>I am just trying to decide whether to split my code and uses code >>>>>>>>>>behind. I did it with one of my pages and found it was quite a bit >>>>>>>>>>of trouble.
>>>>>>>>>>
>>>>>>>>>> I know that most people (and books and articles) like it because >>>>>>>>>> you can split the code from the design. That is logical. But if >>>>>>>>>> you are the only one working on the code, it seem a little
>>>>>>>>>> overkill.
>>>>>>>>>>
>>>>>>>>>> I use Dreamweaver to do my design and find it a bit of a
>>>>>>>>>> hassle
>>>>>>>>>> to have multiple files open for each of my pages as I am working >>>>>>>>>> on them. I typically have 3 or 4 pages open at one time that I am >>>>>>>>>> working on which translates into 6-8 files open.
>>>>>>>>>>
>>>>>>>>>> If I add an object to my design page I need to go the codebehind >>>>>>>>>> page to define it there. If I was working with multiple
>>>>>>>>>> people
>>>>>>>>>> on a page, I would need to run over to the person working on the >>>>>>>>>> codebehind and tell him to add the new object to his page.
>>>>>>>>>>
>>>>>>>>>> Things that are assumed on the .aspx page are not assumed on the >>>>>>>>>> codebehind and have to be explicitly defined.
>>>>>>>>>>
>>>>>>>>>> None of this is really talked about when codebehind is mentioned. >>>>>>>>>> Normally, you are told that it is better. Is this the case in
>>>>>>>>>> all situations?
>>>>>>>>>>
>>>>>>>>>> Just trying to get other opinions on this, as I have already have >>>>>>>>>> about 30 pages designed and am trying to decide if I should split >>>>>>>>>> the files or not.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl... Heck, Karl, I'm done. If he doesn't believe in "best" practices, it's his
loss. I did my best. ;-)
Actually, I was not completely disagreeing with you. I was just saying that
it is not necessarily "the best" in all cases :)
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:uK**************@tk2msftngp13.phx.gbl... By the time you two settle this partial classes might be 4 years old...
I always find quoting the simpsons in such matters helpful:
"And so, Gary Coleman and the Simpsons argued long into the night, and
then, as day broke, the spirit of the season entered their
hearts.
'Lets just agree that the commercialization of Christmas is, at best, a
mixed blessing' "
--
MY ASP.Net tutorials
http://www.openmymind.net/
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OB**************@TK2MSFTNGP11.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uY****************@TK2MSFTNGP09.phx.gbl...
>> No. You said that. You said there is only ONE Best way.
>
> Nope. YOU said "THE best" - the definite article indicates a singular
> reference.
Only if you take it out of context - as you did.
"If I have a choice between the most efficient and the most readable and
maintainable - "the best" way is not necessarily going to be the same"
Not singular here.
"My only point here is that you can't say that one thing (whatever that
is) is "the best" for everyone."
Not here.
"You look at your options and pick "the best" based on your needs and
resources."
Not here, either.
Also, "the best" can change as circumstances change. (not singular) :)
>
> --
> ;-),
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:uj**************@TK2MSFTNGP09.phx.gbl...
>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> news:u6**************@TK2MSFTNGP10.phx.gbl...
>>>> You look at your options and pick the best based on your needs and
>>>> resources.
>>>
>>> Didn't you just say that there wasn't a "best?"
>>
>> No. You said that. You said there is only ONE Best way.
>>
>> I said there are many ways. As I said - "best based on your needs
>> and
>> resources". What is best for me is not necessarily what is best for
you. >>
>> Back to my car scenario.
>>
>> Let's say I have a small income. Therefore, the Ferrari is not the
Best >> car for me.
>>
>> My only point here is that you can't say that one thing (whatever
>> that
>> is) is the best for everyone.
>>
>> I agree with you that structure is the better way over non
>> structured.
>> But you can be structured without splitting files. That is what
>> code-inside asp.net has over asp.
>>
>> You can write very bad code using separate files and really good
>> code-inside files. Splitting the files doesn't make it better code.
>>
>> Just because you can DO something doesn't mean you SHOULD do
>> something.
>>>
>>> --
>>> HTH,
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> .Net Developer
>>> Neither a follower nor a lender be.
>>>
>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>> news:uz**************@TK2MSFTNGP11.phx.gbl...
>>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>>>> news:O4**************@TK2MSFTNGP12.phx.gbl...
>>>>>> Actually, I have been around for a long time and have rarely
>>>>>> found
a >>>>>> "best" way for anything. Most times there are best ways
>>>>>> depending
on >>>>>> the situation. There is a saying: give a programming task to 100
>>>>>> programmers and you will get 100 programs. Some will be bad, but
>>>>>> there will not be a "best", but many good programs.
>>>>>>
>>>>>
>>>>> I have to disagree. There are many ways to write a program, but
>>>>> only
>>>>> ONE best way.
>>>>
>>>> Based on who?
>>>>
>>>> If I have a choice between the most efficient and the most readable
and >>>> maintainable - the best way is not necessarily going to be the
>>>> same.
>>>>
>>>> Programming has evolved over the years with "many" best ways and
there >>>> are differing arguments on what is the best. Just as you have
>>>> disagreements on whether MS is better than Linux or a Ferrari is
better >>>> than a Volkswagon. It depends on your situation.
>>>>
>>>> You look at your options and pick the best based on your needs and
>>>> resources.
>>>>
>>>>> If you don't shoot for it, you'll never get close.
>>>>>
>>>>> --
>>>>> HTH,
>>>>>
>>>>> Kevin Spencer
>>>>> Microsoft MVP
>>>>> .Net Developer
>>>>> Neither a follower nor a lender be.
>>>>>
>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>> news:e1**************@TK2MSFTNGP14.phx.gbl...
>>>>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>>>>>> message
>>>>>> news:O0**************@TK2MSFTNGP11.phx.gbl...
>>>>>>> Tom,
>>>>>>>
>>>>>>> Maybe you feel this way at this point in your career. Maybe you
only >>>>>>> work on small applications. But, like good architecture, your
>>>>>>> methodology should be extensible. Extensibility, and ease of
>>>>>>> code
>>>>>>> maintenance are the chief reasons for separating an app into
>>>>>>> separate tiers, and separating HTML template layout markup from
Page >>>>>>> business logic. At some point, hopefully, you will work on
>>>>>>> large-scale apps, and/or work in a team, and I hope your
methodology >>>>>>> can accomodate the new situation when and if it comes.
>>>>>>
>>>>>> Actually, I have been around for a long time and have rarely
>>>>>> found
a >>>>>> "best" way for anything. Most times there are best ways
>>>>>> depending
on >>>>>> the situation. There is a saying: give a programming task to 100
>>>>>> programmers and you will get 100 programs. Some will be bad, but
>>>>>> there will not be a "best", but many good programs.
>>>>>>
>>>>>> I am not saying that breaking an app into separate tiers is not
>>>>>> the
>>>>>> good way for the situation you mention, but it is not a Panacea
>>>>>> for
>>>>>> all situations, either.
>>>>>>
>>>>>> I agree that breaking up code into objects and libraries is a
>>>>>> good
>>>>>> idea (and I do it all the time) - but not for everything.
>>>>>>
>>>>>> I am just trying to see the pluses and minuses I may not have
>>>>>> come
up >>>>>> with, before I go in one direction or the other.
>>>>>>
>>>>>> Always a good methodology.
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> HTH,
>>>>>>>
>>>>>>> Kevin Spencer
>>>>>>> Microsoft MVP
>>>>>>> .Net Developer
>>>>>>> Neither a follower nor a lender be.
>>>>>>>
>>>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>>>> news:%2******************@tk2msftngp13.phx.gbl...
>>>>>>>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>>>>>>>> news:u6**************@TK2MSFTNGP11.phx.gbl...
>>>>>>>>> Please read the thread with subject :
>>>>>>>>>
>>>>>>>>> "What's the difference/advantages
>>>>>>>>> between code behind and code inside?
>>>>>>>>
>>>>>>>> I did and added my 2 cents worth - which is about all I can
handle >>>>>>>> at this point.
>>>>>>>>
>>>>>>>> So far, I've determined that there really is no discernable
benefit >>>>>>>> from going from code-inside to code-behind (other than to use
>>>>>>>> VS)
>>>>>>>> or are trying to hide the source if deploying the application.
It >>>>>>>> really is a matter of preference. Not a better way to code -
>>>>>>>> as
>>>>>>>> was mentioned.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> The separation happens whether or not you use code-behind
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Juan T. Llibre
>>>>>>>>> ASP.NET MVP
>>>>>>>>> ===========
>>>>>>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>>>>>>> news:em**************@TK2MSFTNGP11.phx.gbl...
>>>>>>>>>>I am just trying to decide whether to split my code and uses
code >>>>>>>>>>behind. I did it with one of my pages and found it was quite a
bit >>>>>>>>>>of trouble.
>>>>>>>>>>
>>>>>>>>>> I know that most people (and books and articles) like it
because >>>>>>>>>> you can split the code from the design. That is logical.
>>>>>>>>>> But
if >>>>>>>>>> you are the only one working on the code, it seem a little
>>>>>>>>>> overkill.
>>>>>>>>>>
>>>>>>>>>> I use Dreamweaver to do my design and find it a bit of a
>>>>>>>>>> hassle
>>>>>>>>>> to have multiple files open for each of my pages as I am
working >>>>>>>>>> on them. I typically have 3 or 4 pages open at one time that
>>>>>>>>>> I
am >>>>>>>>>> working on which translates into 6-8 files open.
>>>>>>>>>>
>>>>>>>>>> If I add an object to my design page I need to go the
codebehind >>>>>>>>>> page to define it there. If I was working with multiple
>>>>>>>>>> people
>>>>>>>>>> on a page, I would need to run over to the person working on
the >>>>>>>>>> codebehind and tell him to add the new object to his page.
>>>>>>>>>>
>>>>>>>>>> Things that are assumed on the .aspx page are not assumed on
the >>>>>>>>>> codebehind and have to be explicitly defined.
>>>>>>>>>>
>>>>>>>>>> None of this is really talked about when codebehind is
mentioned. >>>>>>>>>> Normally, you are told that it is better. Is this the case
>>>>>>>>>> in
>>>>>>>>>> all situations?
>>>>>>>>>>
>>>>>>>>>> Just trying to get other opinions on this, as I have already
have >>>>>>>>>> about 30 pages designed and am trying to decide if I should
split >>>>>>>>>> the files or not.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
I think your first mistake is using dreamweaver to develop .net apps, for it
has no intrinsic support for code behinds. Dreamweaver is good for html
editing and that'z about it.
"Brian" <Br***@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com... I think your first mistake is using dreamweaver to develop .net apps, for
it has no intrinsic support for code behinds. Dreamweaver is good for html
editing and that'z about it.
Hi,
Sorry to jump in. My newsreader doesn't show the actual thread that led
up to your response -- only the response itself. I'm not the original
poster, just a lurker.
You touched on using DreamWeaver for .NET projects. More and more people
are doing this because the web design UI in VS.NET is horrible compared to
DreamWeaver -- so horrible, in fact, that I too have had to resort to
creating my pages in DreamWeaver and then copying them over to a Visual
Studio environment where I write then write my C# code via code-behind. This
is a real PITA. I'm hoping that the web designer UI in VS2005 will be much
better so that I can ditch DreamWeaver all together.
Larry
"Larry David" <My***************@HealthyChoice.org> wrote in message
news:TM********************@giganews.com...
"Brian" <Br***@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com... I think your first mistake is using dreamweaver to develop .net apps, for it has no intrinsic support for code behinds. Dreamweaver is good for html
editing and that'z about it.
Hi,
Sorry to jump in. My newsreader doesn't show the actual thread that led
up to your response -- only the response itself. I'm not the original
poster, just a lurker.
You touched on using DreamWeaver for .NET projects. More and more
people
are doing this because the web design UI in VS.NET is horrible compared to
DreamWeaver -- so horrible, in fact, that I too have had to resort to
creating my pages in DreamWeaver and then copying them over to a Visual
Studio environment where I write then write my C# code via code-behind.
This
is a real PITA. I'm hoping that the web designer UI in VS2005 will be much
better so that I can ditch DreamWeaver all together.
But, according to other posts here, VS also won't handle code-inside pages -
which it should !
Even though code behind is the preferred method, VS should be able to handle
both.
Actually, I use DW to do both. I have both pages open (the aspx page and
the code-behind page). When I am handling the objects or the HTML, I just
use switch to the aspx page and if I am working on the Subs, I switch to the
code behind page. DWMX2004 does a decent job of using the asp.net objects.
I have my issues with DW, but at least I can code the way I want and not the
way DW wants me too.
MS apparently won't let you do it your way (sound like a commercial). One
of the problems with them.
IMHO.
Tom
Larry
re: But, according to other posts here, VS also won't handle code-inside
pages - which it should !
It will, as of VS.NET 2005.
re: Even though code behind is the preferred method, VS should be able to
handle both.
It will, as of VS.NET 2005.
re: MS apparently won't let you do it your way (sound like a commercial). One
of the problems with them.
No more...
They've been listening to people like you. :-)
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eq**************@TK2MSFTNGP09.phx.gbl... "Larry David" <My***************@HealthyChoice.org> wrote in message
news:TM********************@giganews.com...
"Brian" <Br***@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com... I think your first mistake is using dreamweaver to develop .net apps,
for
it has no intrinsic support for code behinds. Dreamweaver is good for
html
editing and that'z about it.
Hi,
Sorry to jump in. My newsreader doesn't show the actual thread that
led
up to your response -- only the response itself. I'm not the original
poster, just a lurker.
You touched on using DreamWeaver for .NET projects. More and more
people
are doing this because the web design UI in VS.NET is horrible compared
to
DreamWeaver -- so horrible, in fact, that I too have had to resort to
creating my pages in DreamWeaver and then copying them over to a Visual
Studio environment where I write then write my C# code via code-behind.
This
is a real PITA. I'm hoping that the web designer UI in VS2005 will be
much
better so that I can ditch DreamWeaver all together.
But, according to other posts here, VS also won't handle code-inside
pages - which it should !
Even though code behind is the preferred method, VS should be able to
handle both.
Actually, I use DW to do both. I have both pages open (the aspx page and
the code-behind page). When I am handling the objects or the HTML, I just
use switch to the aspx page and if I am working on the Subs, I switch to
the code behind page. DWMX2004 does a decent job of using the asp.net
objects. I have my issues with DW, but at least I can code the way I want
and not the way DW wants me too.
MS apparently won't let you do it your way (sound like a commercial). One
of the problems with them.
IMHO.
Tom
Larry
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:eA**************@TK2MSFTNGP12.phx.gbl... re: But, according to other posts here, VS also won't handle code-inside
pages - which it should !
It will, as of VS.NET 2005.
I am just getting ready to buy VS 2003. How soon is VS 2005 coming out?
Is it going to be that much better that 2003?
Tom
re: Even though code behind is the preferred method, VS should be able to
handle both.
It will, as of VS.NET 2005.
re: MS apparently won't let you do it your way (sound like a commercial).
One of the problems with them.
No more...
They've been listening to people like you. :-)
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eq**************@TK2MSFTNGP09.phx.gbl... "Larry David" <My***************@HealthyChoice.org> wrote in message
news:TM********************@giganews.com...
"Brian" <Br***@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com...
I think your first mistake is using dreamweaver to develop .net apps,
for
it
has no intrinsic support for code behinds. Dreamweaver is good for
html
editing and that'z about it.
Hi,
Sorry to jump in. My newsreader doesn't show the actual thread that
led
up to your response -- only the response itself. I'm not the original
poster, just a lurker.
You touched on using DreamWeaver for .NET projects. More and more
people
are doing this because the web design UI in VS.NET is horrible compared
to
DreamWeaver -- so horrible, in fact, that I too have had to resort to
creating my pages in DreamWeaver and then copying them over to a Visual
Studio environment where I write then write my C# code via code-behind.
This
is a real PITA. I'm hoping that the web designer UI in VS2005 will be
much
better so that I can ditch DreamWeaver all together.
But, according to other posts here, VS also won't handle code-inside
pages - which it should !
Even though code behind is the preferred method, VS should be able to
handle both.
Actually, I use DW to do both. I have both pages open (the aspx page and
the code-behind page). When I am handling the objects or the HTML, I
just use switch to the aspx page and if I am working on the Subs, I
switch to the code behind page. DWMX2004 does a decent job of using the
asp.net objects. I have my issues with DW, but at least I can code the
way I want and not the way DW wants me too.
MS apparently won't let you do it your way (sound like a commercial).
One of the problems with them.
IMHO.
Tom
Larry
re: How soon is VS 2005 coming out?
Beta 2 should happen sometime in the next month or so,
and product release well before the end of the year,
according to the pundits.
re: Is it going to be that much better that 2003?
Oh, yes...
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uI****************@TK2MSFTNGP12.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:eA**************@TK2MSFTNGP12.phx.gbl... re: But, according to other posts here, VS also won't handle code-inside
pages - which it should !
It will, as of VS.NET 2005.
I am just getting ready to buy VS 2003. How soon is VS 2005 coming out?
Is it going to be that much better that 2003?
Tom
re: Even though code behind is the preferred method, VS should be able to
handle both.
It will, as of VS.NET 2005.
re: MS apparently won't let you do it your way (sound like a commercial).
One of the problems with them.
No more...
They've been listening to people like you. :-)
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eq**************@TK2MSFTNGP09.phx.gbl... "Larry David" <My***************@HealthyChoice.org> wrote in message
news:TM********************@giganews.com...
"Brian" <Br***@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com...
> I think your first mistake is using dreamweaver to develop .net apps,
> for
it
> has no intrinsic support for code behinds. Dreamweaver is good for
> html
> editing and that'z about it.
Hi,
Sorry to jump in. My newsreader doesn't show the actual thread that
led
up to your response -- only the response itself. I'm not the original
poster, just a lurker.
You touched on using DreamWeaver for .NET projects. More and more
people
are doing this because the web design UI in VS.NET is horrible compared
to
DreamWeaver -- so horrible, in fact, that I too have had to resort to
creating my pages in DreamWeaver and then copying them over to a Visual
Studio environment where I write then write my C# code via code-behind.
This
is a real PITA. I'm hoping that the web designer UI in VS2005 will be
much
better so that I can ditch DreamWeaver all together.
But, according to other posts here, VS also won't handle code-inside
pages - which it should !
Even though code behind is the preferred method, VS should be able to
handle both.
Actually, I use DW to do both. I have both pages open (the aspx page
and the code-behind page). When I am handling the objects or the HTML,
I just use switch to the aspx page and if I am working on the Subs, I
switch to the code behind page. DWMX2004 does a decent job of using the
asp.net objects. I have my issues with DW, but at least I can code the
way I want and not the way DW wants me too.
MS apparently won't let you do it your way (sound like a commercial).
One of the problems with them.
IMHO.
Tom
Larry
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:Oj**************@TK2MSFTNGP10.phx.gbl... re: How soon is VS 2005 coming out?
Beta 2 should happen sometime in the next month or so,
and product release well before the end of the year,
according to the pundits.
re: Is it going to be that much better that 2003?
Oh, yes...
I am just curious because I just got the 60 day trial and don't want to
purchase it if the newer one is going to come out soon and have to pay an
exorbitant upgrade charge.
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uI****************@TK2MSFTNGP12.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:eA**************@TK2MSFTNGP12.phx.gbl... re:
But, according to other posts here, VS also won't handle code-inside
pages - which it should !
It will, as of VS.NET 2005.
I am just getting ready to buy VS 2003. How soon is VS 2005 coming out?
Is it going to be that much better that 2003?
Tom
re:
Even though code behind is the preferred method, VS should be able to
handle both.
It will, as of VS.NET 2005.
re:
MS apparently won't let you do it your way (sound like a commercial).
One of the problems with them.
No more...
They've been listening to people like you. :-)
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eq**************@TK2MSFTNGP09.phx.gbl...
"Larry David" <My***************@HealthyChoice.org> wrote in message
news:TM********************@giganews.com...
>
> "Brian" <Br***@discussions.microsoft.com> wrote in message
> news:D8**********************************@microsof t.com...
>> I think your first mistake is using dreamweaver to develop .net apps,
>> for
> it
>> has no intrinsic support for code behinds. Dreamweaver is good for
>> html
>> editing and that'z about it.
>
> Hi,
>
> Sorry to jump in. My newsreader doesn't show the actual thread that
> led
> up to your response -- only the response itself. I'm not the original
> poster, just a lurker.
>
> You touched on using DreamWeaver for .NET projects. More and more
> people
> are doing this because the web design UI in VS.NET is horrible
> compared to
> DreamWeaver -- so horrible, in fact, that I too have had to resort to
> creating my pages in DreamWeaver and then copying them over to a
> Visual
> Studio environment where I write then write my C# code via
> code-behind. This
> is a real PITA. I'm hoping that the web designer UI in VS2005 will be
> much
> better so that I can ditch DreamWeaver all together.
But, according to other posts here, VS also won't handle code-inside
pages - which it should !
Even though code behind is the preferred method, VS should be able to
handle both.
Actually, I use DW to do both. I have both pages open (the aspx page
and the code-behind page). When I am handling the objects or the HTML,
I just use switch to the aspx page and if I am working on the Subs, I
switch to the code behind page. DWMX2004 does a decent job of using
the asp.net objects. I have my issues with DW, but at least I can code
the way I want and not the way DW wants me too.
MS apparently won't let you do it your way (sound like a commercial).
One of the problems with them.
IMHO.
Tom
>
> Larry
As usual, there's a lot of speculation about Microsoft
product release dates, particularly with developer products.
The truth is...nobody knows when.
The best estimates about Beta 2 place it anywhere
from one month to two months from now, given that
it was promised by end of Q1.
Then, I'd guess that another 4-6 months before RTM,
and then allow 6-8 weeks for product distribution
( actually making the CD's & DVD's and getting them
out to retailers )
That would place product release at sometime
between 3rd and 4th quarters 2005.
If you can wait... do so.
You might also be able to get an upgrade coupon for 2005
when you purchase 2003. Check with whomever you're
planning to purchase it from.
An alternative is to download/install the betas as they are
released at http://lab.msdn.microsoft.com/express/
The Express products, particularly VWD for web development,
have very similar characteristics to Visual Studio, and you'll be
able to come up to speed with ASP.NET 2.0 before you
purchase Visual Studio, making a faster transition.
Juan T. Llibre
ASP.NET MVP http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OV*************@TK2MSFTNGP15.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:Oj**************@TK2MSFTNGP10.phx.gbl... re: How soon is VS 2005 coming out?
Beta 2 should happen sometime in the next month or so,
and product release well before the end of the year,
according to the pundits.
re: Is it going to be that much better that 2003?
Oh, yes...
I am just curious because I just got the 60 day trial and don't want to
purchase it if the newer one is going to come out soon and have to pay an
exorbitant upgrade charge.
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uI****************@TK2MSFTNGP12.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:eA**************@TK2MSFTNGP12.phx.gbl...
re:
> But, according to other posts here, VS also won't handle code-inside
> pages - which it should !
It will, as of VS.NET 2005.
I am just getting ready to buy VS 2003. How soon is VS 2005 coming out?
Is it going to be that much better that 2003?
Tom
re:
> Even though code behind is the preferred method, VS should be able to
> handle both.
It will, as of VS.NET 2005.
re:
> MS apparently won't let you do it your way (sound like a commercial).
> One of the problems with them.
No more...
They've been listening to people like you. :-)
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eq**************@TK2MSFTNGP09.phx.gbl...
> "Larry David" <My***************@HealthyChoice.org> wrote in message
> news:TM********************@giganews.com...
>>
>> "Brian" <Br***@discussions.microsoft.com> wrote in message
>> news:D8**********************************@microsof t.com...
>>> I think your first mistake is using dreamweaver to develop .net
>>> apps, for
>> it
>>> has no intrinsic support for code behinds. Dreamweaver is good for
>>> html
>>> editing and that'z about it.
>>
>> Hi,
>>
>> Sorry to jump in. My newsreader doesn't show the actual thread
>> that led
>> up to your response -- only the response itself. I'm not the original
>> poster, just a lurker.
>>
>> You touched on using DreamWeaver for .NET projects. More and more
>> people
>> are doing this because the web design UI in VS.NET is horrible
>> compared to
>> DreamWeaver -- so horrible, in fact, that I too have had to resort to
>> creating my pages in DreamWeaver and then copying them over to a
>> Visual
>> Studio environment where I write then write my C# code via
>> code-behind. This
>> is a real PITA. I'm hoping that the web designer UI in VS2005 will be
>> much
>> better so that I can ditch DreamWeaver all together.
>
> But, according to other posts here, VS also won't handle code-inside
> pages - which it should !
>
> Even though code behind is the preferred method, VS should be able to
> handle both.
>
> Actually, I use DW to do both. I have both pages open (the aspx page
> and the code-behind page). When I am handling the objects or the
> HTML, I just use switch to the aspx page and if I am working on the
> Subs, I switch to the code behind page. DWMX2004 does a decent job of
> using the asp.net objects. I have my issues with DW, but at least I
> can code the way I want and not the way DW wants me too.
>
> MS apparently won't let you do it your way (sound like a commercial).
> One of the problems with them.
>
> IMHO.
>
> Tom
>>
>> Larry
> I am just trying to decide whether to split my code and uses code behind. I did it with one of my pages and found it was quite a bit of trouble.
How so?
if you are the only
one working on the code, it seem a little overkill.
I disagree strongly. How is it overkill? Please elucidate.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
How horrible! 6 to 8 open files! Sorry for being facetious, but that's a
very weak reason if one at all.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I would
need to run over to the person working on the codebehind and tell him to add
the new object to his page.
I work in a 5 person team on a large site (3 guesses which one) and we never
have this issue. If I'm modifying the page I have it checked out and thus I
add the object to both sides.
Things that are assumed on the .aspx page are not assumed on the codebehind
and have to be explicitly defined.
That's a good thing.
Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.
Yes, you should. Aside from your gripe about multiple open files you
haven't mentioned any reasons which would indicate that code-behind is
inferior in any situation. Code-behind separates data gathering and business
logic from presentation and is INCREDIBLY valuable.
Just to illustrate my point, let's say you are gathering data about
customers for a data table to distribute to your users. If your code is in
the ASPX, then sure, it might be faster to just pull all the data there and
be done with it (although my opinion is that it would take longer. ) What,
then, about when your users want the data in a different format? Say,
instead of a rows/columns datatable, a large detail format depicting each
item in full? Would you copy and paste the ASPX code, reformat, and make a
new copy of your page? If the data later changed, then you now have to
change your data gathering code in two places.
In the same case, were you to have relegated the data gathering to a
codebehind you could have pushed that to its own class, separate from even
the page's codebehind, and simply coded a new ASPX page, included the class,
and bound the data.
Not using codebehind is ignoring one of the largest benefits of the dotNET
architecture, IMHO.
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:uP**************@tk2msftngp13.phx.gbl... As usual, there's a lot of speculation about Microsoft
product release dates, particularly with developer products.
The truth is...nobody knows when.
The best estimates about Beta 2 place it anywhere
from one month to two months from now, given that
it was promised by end of Q1.
Then, I'd guess that another 4-6 months before RTM,
and then allow 6-8 weeks for product distribution
( actually making the CD's & DVD's and getting them
out to retailers )
That would place product release at sometime
between 3rd and 4th quarters 2005.
If you can wait... do so.
You might also be able to get an upgrade coupon for 2005
when you purchase 2003. Check with whomever you're
planning to purchase it from.
An alternative is to download/install the betas as they are
released at http://lab.msdn.microsoft.com/express/
The Express products, particularly VWD for web development,
have very similar characteristics to Visual Studio, and you'll be
able to come up to speed with ASP.NET 2.0 before you
purchase Visual Studio, making a faster transition.
What are we going to need to do to go to ASP.NET 2.0?
We have our Web Servers on 2000 (IIS 5 - I believe) and 2003 (IIS6).
Is it just an add on or a whole different IIS?
Do we know what the ~timeframe from MS is for 2.0?
Thanks,
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OV*************@TK2MSFTNGP15.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:Oj**************@TK2MSFTNGP10.phx.gbl... re:
How soon is VS 2005 coming out?
Beta 2 should happen sometime in the next month or so,
and product release well before the end of the year,
according to the pundits.
re:
Is it going to be that much better that 2003?
Oh, yes...
I am just curious because I just got the 60 day trial and don't want to
purchase it if the newer one is going to come out soon and have to pay an
exorbitant upgrade charge.
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uI****************@TK2MSFTNGP12.phx.gbl...
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:eA**************@TK2MSFTNGP12.phx.gbl...
> re:
>> But, according to other posts here, VS also won't handle code-inside
>> pages - which it should !
>
> It will, as of VS.NET 2005.
I am just getting ready to buy VS 2003. How soon is VS 2005 coming
out?
Is it going to be that much better that 2003?
Tom
>
> re:
>> Even though code behind is the preferred method, VS should be able to
>> handle both.
>
> It will, as of VS.NET 2005.
>
> re:
>> MS apparently won't let you do it your way (sound like a commercial).
>> One of the problems with them.
>
> No more...
>
> They've been listening to people like you. :-)
>
>
>
> Juan T. Llibre
> ASP.NET MVP
> http://asp.net.do/foros/
> Foros de ASP.NET en Español
> =====================
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:eq**************@TK2MSFTNGP09.phx.gbl...
>> "Larry David" <My***************@HealthyChoice.org> wrote in message
>> news:TM********************@giganews.com...
>>>
>>> "Brian" <Br***@discussions.microsoft.com> wrote in message
>>> news:D8**********************************@microsof t.com...
>>>> I think your first mistake is using dreamweaver to develop .net
>>>> apps, for
>>> it
>>>> has no intrinsic support for code behinds. Dreamweaver is good
>>>> for html
>>>> editing and that'z about it.
>>>
>>> Hi,
>>>
>>> Sorry to jump in. My newsreader doesn't show the actual thread
>>> that led
>>> up to your response -- only the response itself. I'm not the
>>> original
>>> poster, just a lurker.
>>>
>>> You touched on using DreamWeaver for .NET projects. More and more
>>> people
>>> are doing this because the web design UI in VS.NET is horrible
>>> compared to
>>> DreamWeaver -- so horrible, in fact, that I too have had to resort
>>> to
>>> creating my pages in DreamWeaver and then copying them over to a
>>> Visual
>>> Studio environment where I write then write my C# code via
>>> code-behind. This
>>> is a real PITA. I'm hoping that the web designer UI in VS2005 will
>>> be much
>>> better so that I can ditch DreamWeaver all together.
>>
>> But, according to other posts here, VS also won't handle code-inside
>> pages - which it should !
>>
>> Even though code behind is the preferred method, VS should be able to
>> handle both.
>>
>> Actually, I use DW to do both. I have both pages open (the aspx page
>> and the code-behind page). When I am handling the objects or the
>> HTML, I just use switch to the aspx page and if I am working on the
>> Subs, I switch to the code behind page. DWMX2004 does a decent job
>> of using the asp.net objects. I have my issues with DW, but at least
>> I can code the way I want and not the way DW wants me too.
>>
>> MS apparently won't let you do it your way (sound like a commercial).
>> One of the problems with them.
>>
>> IMHO.
>>
>> Tom
>>>
>>> Larry
>
>
re: What are we going to need to do to go to ASP.NET 2.0?
Is it just an add on or a whole different IIS?
It's just another version of the .NET Framework.
ASP.NET is an ISAPI program which runs against
a particular version of the .NET Framework.
You probably have both version 1.0
and 1.1 on your system now.
After you install .Net Framework 2.0,
you'll be able to run 1.1 apps and 2.0 apps side-by-side.
re: Do we know what the ~timeframe from MS is for 2.0?
Like I said, they promised Beta 2 for before the end of Q1.
They had promised it for last September, though.
I dropped out of a book authoring deal
because the dates kept slipping... ;-)
I'd be very surprised if Q4 2005 came and we still didn't
have a released version of both VS.NET 2005 and .NET 2.0
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:uP**************@tk2msftngp13.phx.gbl... As usual, there's a lot of speculation about Microsoft
product release dates, particularly with developer products.
The truth is...nobody knows when.
The best estimates about Beta 2 place it anywhere
from one month to two months from now, given that
it was promised by end of Q1.
Then, I'd guess that another 4-6 months before RTM,
and then allow 6-8 weeks for product distribution
( actually making the CD's & DVD's and getting them
out to retailers )
That would place product release at sometime
between 3rd and 4th quarters 2005.
If you can wait... do so.
You might also be able to get an upgrade coupon for 2005
when you purchase 2003. Check with whomever you're
planning to purchase it from.
An alternative is to download/install the betas as they are
released at http://lab.msdn.microsoft.com/express/
The Express products, particularly VWD for web development,
have very similar characteristics to Visual Studio, and you'll be
able to come up to speed with ASP.NET 2.0 before you
purchase Visual Studio, making a faster transition.
What are we going to need to do to go to ASP.NET 2.0?
We have our Web Servers on 2000 (IIS 5 - I believe) and 2003 (IIS6).
Is it just an add on or a whole different IIS?
Do we know what the ~timeframe from MS is for 2.0?
Thanks,
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OV*************@TK2MSFTNGP15.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:Oj**************@TK2MSFTNGP10.phx.gbl...
re:
> How soon is VS 2005 coming out?
Beta 2 should happen sometime in the next month or so,
and product release well before the end of the year,
according to the pundits.
re:
> Is it going to be that much better that 2003?
Oh, yes...
I am just curious because I just got the 60 day trial and don't want to
purchase it if the newer one is going to come out soon and have to pay
an exorbitant upgrade charge.
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:uI****************@TK2MSFTNGP12.phx.gbl...
> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
> news:eA**************@TK2MSFTNGP12.phx.gbl...
>> re:
>>> But, according to other posts here, VS also won't handle code-inside
>>> pages - which it should !
>>
>> It will, as of VS.NET 2005.
>
> I am just getting ready to buy VS 2003. How soon is VS 2005 coming
> out?
>
> Is it going to be that much better that 2003?
>
> Tom
>>
>> re:
>>> Even though code behind is the preferred method, VS should be able
>>> to handle both.
>>
>> It will, as of VS.NET 2005.
>>
>> re:
>>> MS apparently won't let you do it your way (sound like a
>>> commercial). One of the problems with them.
>>
>> No more...
>>
>> They've been listening to people like you. :-)
>>
>>
>>
>> Juan T. Llibre
>> ASP.NET MVP
>> http://asp.net.do/foros/
>> Foros de ASP.NET en Español
>> =====================
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:eq**************@TK2MSFTNGP09.phx.gbl...
>>> "Larry David" <My***************@HealthyChoice.org> wrote in message
>>> news:TM********************@giganews.com...
>>>>
>>>> "Brian" <Br***@discussions.microsoft.com> wrote in message
>>>> news:D8**********************************@microsof t.com...
>>>>> I think your first mistake is using dreamweaver to develop .net
>>>>> apps, for
>>>> it
>>>>> has no intrinsic support for code behinds. Dreamweaver is good
>>>>> for html
>>>>> editing and that'z about it.
>>>>
>>>> Hi,
>>>>
>>>> Sorry to jump in. My newsreader doesn't show the actual thread
>>>> that led
>>>> up to your response -- only the response itself. I'm not the
>>>> original
>>>> poster, just a lurker.
>>>>
>>>> You touched on using DreamWeaver for .NET projects. More and
>>>> more people
>>>> are doing this because the web design UI in VS.NET is horrible
>>>> compared to
>>>> DreamWeaver -- so horrible, in fact, that I too have had to resort
>>>> to
>>>> creating my pages in DreamWeaver and then copying them over to a
>>>> Visual
>>>> Studio environment where I write then write my C# code via
>>>> code-behind. This
>>>> is a real PITA. I'm hoping that the web designer UI in VS2005 will
>>>> be much
>>>> better so that I can ditch DreamWeaver all together.
>>>
>>> But, according to other posts here, VS also won't handle code-inside
>>> pages - which it should !
>>>
>>> Even though code behind is the preferred method, VS should be able
>>> to handle both.
>>>
>>> Actually, I use DW to do both. I have both pages open (the aspx
>>> page and the code-behind page). When I am handling the objects or
>>> the HTML, I just use switch to the aspx page and if I am working on
>>> the Subs, I switch to the code behind page. DWMX2004 does a decent
>>> job of using the asp.net objects. I have my issues with DW, but at
>>> least I can code the way I want and not the way DW wants me too.
>>>
>>> MS apparently won't let you do it your way (sound like a
>>> commercial). One of the problems with them.
>>>
>>> IMHO.
>>>
>>> Tom
>>>>
>>>> Larry
>>
>>
>
>
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:eD****************@tk2msftngp13.phx.gbl... re: What are we going to need to do to go to ASP.NET 2.0?
Is it just an add on or a whole different IIS?
It's just another version of the .NET Framework.
ASP.NET is an ISAPI program which runs against
a particular version of the .NET Framework.
You probably have both version 1.0
and 1.1 on your system now.
After you install .Net Framework 2.0,
you'll be able to run 1.1 apps and 2.0 apps side-by-side.
How does the .Net know which app you are running?
Is 2.0 going to be a different extension or is there a declaration like
DOCTYPE to tell how to run it?
Tom
re: Do we know what the ~timeframe from MS is for 2.0?
Like I said, they promised Beta 2 for before the end of Q1.
They had promised it for last September, though.
I dropped out of a book authoring deal
because the dates kept slipping... ;-)
I'd be very surprised if Q4 2005 came and we still didn't
have a released version of both VS.NET 2005 and .NET 2.0
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:uP**************@tk2msftngp13.phx.gbl... As usual, there's a lot of speculation about Microsoft
product release dates, particularly with developer products.
The truth is...nobody knows when.
The best estimates about Beta 2 place it anywhere
from one month to two months from now, given that
it was promised by end of Q1.
Then, I'd guess that another 4-6 months before RTM,
and then allow 6-8 weeks for product distribution
( actually making the CD's & DVD's and getting them
out to retailers )
That would place product release at sometime
between 3rd and 4th quarters 2005.
If you can wait... do so.
You might also be able to get an upgrade coupon for 2005
when you purchase 2003. Check with whomever you're
planning to purchase it from.
An alternative is to download/install the betas as they are
released at http://lab.msdn.microsoft.com/express/
The Express products, particularly VWD for web development,
have very similar characteristics to Visual Studio, and you'll be
able to come up to speed with ASP.NET 2.0 before you
purchase Visual Studio, making a faster transition.
What are we going to need to do to go to ASP.NET 2.0?
We have our Web Servers on 2000 (IIS 5 - I believe) and 2003 (IIS6).
Is it just an add on or a whole different IIS?
Do we know what the ~timeframe from MS is for 2.0?
Thanks,
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OV*************@TK2MSFTNGP15.phx.gbl...
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:Oj**************@TK2MSFTNGP10.phx.gbl...
> re:
>> How soon is VS 2005 coming out?
>
> Beta 2 should happen sometime in the next month or so,
> and product release well before the end of the year,
> according to the pundits.
>
> re:
>> Is it going to be that much better that 2003?
>
> Oh, yes...
I am just curious because I just got the 60 day trial and don't want to
purchase it if the newer one is going to come out soon and have to pay
an exorbitant upgrade charge.
Tom
>
>
>
> Juan T. Llibre
> ASP.NET MVP
> http://asp.net.do/foros/
> Foros de ASP.NET en Español
> =====================
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:uI****************@TK2MSFTNGP12.phx.gbl...
>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>> news:eA**************@TK2MSFTNGP12.phx.gbl...
>>> re:
>>>> But, according to other posts here, VS also won't handle
>>>> code-inside pages - which it should !
>>>
>>> It will, as of VS.NET 2005.
>>
>> I am just getting ready to buy VS 2003. How soon is VS 2005 coming
>> out?
>>
>> Is it going to be that much better that 2003?
>>
>> Tom
>>>
>>> re:
>>>> Even though code behind is the preferred method, VS should be able
>>>> to handle both.
>>>
>>> It will, as of VS.NET 2005.
>>>
>>> re:
>>>> MS apparently won't let you do it your way (sound like a
>>>> commercial). One of the problems with them.
>>>
>>> No more...
>>>
>>> They've been listening to people like you. :-)
>>>
>>>
>>>
>>> Juan T. Llibre
>>> ASP.NET MVP
>>> http://asp.net.do/foros/
>>> Foros de ASP.NET en Español
>>> =====================
>>>
>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>> news:eq**************@TK2MSFTNGP09.phx.gbl...
>>>> "Larry David" <My***************@HealthyChoice.org> wrote in
>>>> message news:TM********************@giganews.com...
>>>>>
>>>>> "Brian" <Br***@discussions.microsoft.com> wrote in message
>>>>> news:D8**********************************@microsof t.com...
>>>>>> I think your first mistake is using dreamweaver to develop .net
>>>>>> apps, for
>>>>> it
>>>>>> has no intrinsic support for code behinds. Dreamweaver is good
>>>>>> for html
>>>>>> editing and that'z about it.
>>>>>
>>>>> Hi,
>>>>>
>>>>> Sorry to jump in. My newsreader doesn't show the actual thread
>>>>> that led
>>>>> up to your response -- only the response itself. I'm not the
>>>>> original
>>>>> poster, just a lurker.
>>>>>
>>>>> You touched on using DreamWeaver for .NET projects. More and
>>>>> more people
>>>>> are doing this because the web design UI in VS.NET is horrible
>>>>> compared to
>>>>> DreamWeaver -- so horrible, in fact, that I too have had to resort
>>>>> to
>>>>> creating my pages in DreamWeaver and then copying them over to a
>>>>> Visual
>>>>> Studio environment where I write then write my C# code via
>>>>> code-behind. This
>>>>> is a real PITA. I'm hoping that the web designer UI in VS2005 will
>>>>> be much
>>>>> better so that I can ditch DreamWeaver all together.
>>>>
>>>> But, according to other posts here, VS also won't handle
>>>> code-inside pages - which it should !
>>>>
>>>> Even though code behind is the preferred method, VS should be able
>>>> to handle both.
>>>>
>>>> Actually, I use DW to do both. I have both pages open (the aspx
>>>> page and the code-behind page). When I am handling the objects or
>>>> the HTML, I just use switch to the aspx page and if I am working on
>>>> the Subs, I switch to the code behind page. DWMX2004 does a decent
>>>> job of using the asp.net objects. I have my issues with DW, but at
>>>> least I can code the way I want and not the way DW wants me too.
>>>>
>>>> MS apparently won't let you do it your way (sound like a
>>>> commercial). One of the problems with them.
>>>>
>>>> IMHO.
>>>>
>>>> Tom
>>>>>
>>>>> Larry
>>>
>>>
>>
>>
>
>
re: How does the .Net know which app you are running?
Is 2.0 going to be a different extension or is there a declaration like
DOCTYPE to tell how to run it?
You register the .NET version which ASP.NET
will run against, by running " aspnet_regiis -i " .
Generally, that is done by the installation program.
A neat, free, ASP.NET Version Switcher was written by Denis Bauer.
You can find it at :
http://www.denisbauer.com/NETTools/A...nSwitcher.aspx
You can run any number of versions of ASP.NET,
side-by-side, in any number of virtual directories,
but you will need to run each version of ASP.NET
in a different Application Pool.
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:ef**************@tk2msftngp13.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:eD****************@tk2msftngp13.phx.gbl... re: What are we going to need to do to go to ASP.NET 2.0?
Is it just an add on or a whole different IIS?
It's just another version of the .NET Framework.
ASP.NET is an ISAPI program which runs against
a particular version of the .NET Framework.
You probably have both version 1.0
and 1.1 on your system now.
After you install .Net Framework 2.0,
you'll be able to run 1.1 apps and 2.0 apps side-by-side.
How does the .Net know which app you are running?
Is 2.0 going to be a different extension or is there a declaration like
DOCTYPE to tell how to run it?
Tom
re: Do we know what the ~timeframe from MS is for 2.0?
Like I said, they promised Beta 2 for before the end of Q1.
They had promised it for last September, though.
I dropped out of a book authoring deal
because the dates kept slipping... ;-)
I'd be very surprised if Q4 2005 came and we still didn't
have a released version of both VS.NET 2005 and .NET 2.0
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:uP**************@tk2msftngp13.phx.gbl...
As usual, there's a lot of speculation about Microsoft
product release dates, particularly with developer products.
The truth is...nobody knows when.
The best estimates about Beta 2 place it anywhere
from one month to two months from now, given that
it was promised by end of Q1.
Then, I'd guess that another 4-6 months before RTM,
and then allow 6-8 weeks for product distribution
( actually making the CD's & DVD's and getting them
out to retailers )
That would place product release at sometime
between 3rd and 4th quarters 2005.
If you can wait... do so.
You might also be able to get an upgrade coupon for 2005
when you purchase 2003. Check with whomever you're
planning to purchase it from.
An alternative is to download/install the betas as they are
released at http://lab.msdn.microsoft.com/express/
The Express products, particularly VWD for web development,
have very similar characteristics to Visual Studio, and you'll be
able to come up to speed with ASP.NET 2.0 before you
purchase Visual Studio, making a faster transition.
What are we going to need to do to go to ASP.NET 2.0?
We have our Web Servers on 2000 (IIS 5 - I believe) and 2003 (IIS6).
Is it just an add on or a whole different IIS?
Do we know what the ~timeframe from MS is for 2.0?
Thanks,
Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=====================
"tshad" <ts**********@ftsolutions.com> wrote in message
news:OV*************@TK2MSFTNGP15.phx.gbl...
> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
> news:Oj**************@TK2MSFTNGP10.phx.gbl...
>> re:
>>> How soon is VS 2005 coming out?
>>
>> Beta 2 should happen sometime in the next month or so,
>> and product release well before the end of the year,
>> according to the pundits.
>>
>> re:
>>> Is it going to be that much better that 2003?
>>
>> Oh, yes...
>
> I am just curious because I just got the 60 day trial and don't want
> to purchase it if the newer one is going to come out soon and have to
> pay an exorbitant upgrade charge.
>
> Tom
>
>>
>>
>>
>> Juan T. Llibre
>> ASP.NET MVP
>> http://asp.net.do/foros/
>> Foros de ASP.NET en Español
>> =====================
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:uI****************@TK2MSFTNGP12.phx.gbl...
>>> "Juan T. Llibre" <no***********@nowhere.com> wrote in message
>>> news:eA**************@TK2MSFTNGP12.phx.gbl...
>>>> re:
>>>>> But, according to other posts here, VS also won't handle
>>>>> code-inside pages - which it should !
>>>>
>>>> It will, as of VS.NET 2005.
>>>
>>> I am just getting ready to buy VS 2003. How soon is VS 2005 coming
>>> out?
>>>
>>> Is it going to be that much better that 2003?
>>>
>>> Tom
>>>>
>>>> re:
>>>>> Even though code behind is the preferred method, VS should be able
>>>>> to handle both.
>>>>
>>>> It will, as of VS.NET 2005.
>>>>
>>>> re:
>>>>> MS apparently won't let you do it your way (sound like a
>>>>> commercial). One of the problems with them.
>>>>
>>>> No more...
>>>>
>>>> They've been listening to people like you. :-)
>>>>
>>>>
>>>>
>>>> Juan T. Llibre
>>>> ASP.NET MVP
>>>> http://asp.net.do/foros/
>>>> Foros de ASP.NET en Español
>>>> =====================
>>>>
>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>> news:eq**************@TK2MSFTNGP09.phx.gbl...
>>>>> "Larry David" <My***************@HealthyChoice.org> wrote in
>>>>> message news:TM********************@giganews.com...
>>>>>>
>>>>>> "Brian" <Br***@discussions.microsoft.com> wrote in message
>>>>>> news:D8**********************************@microsof t.com...
>>>>>>> I think your first mistake is using dreamweaver to develop .net
>>>>>>> apps, for
>>>>>> it
>>>>>>> has no intrinsic support for code behinds. Dreamweaver is good
>>>>>>> for html
>>>>>>> editing and that'z about it.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Sorry to jump in. My newsreader doesn't show the actual thread
>>>>>> that led
>>>>>> up to your response -- only the response itself. I'm not the
>>>>>> original
>>>>>> poster, just a lurker.
>>>>>>
>>>>>> You touched on using DreamWeaver for .NET projects. More and
>>>>>> more people
>>>>>> are doing this because the web design UI in VS.NET is horrible
>>>>>> compared to
>>>>>> DreamWeaver -- so horrible, in fact, that I too have had to
>>>>>> resort to
>>>>>> creating my pages in DreamWeaver and then copying them over to a
>>>>>> Visual
>>>>>> Studio environment where I write then write my C# code via
>>>>>> code-behind. This
>>>>>> is a real PITA. I'm hoping that the web designer UI in VS2005
>>>>>> will be much
>>>>>> better so that I can ditch DreamWeaver all together.
>>>>>
>>>>> But, according to other posts here, VS also won't handle
>>>>> code-inside pages - which it should !
>>>>>
>>>>> Even though code behind is the preferred method, VS should be able
>>>>> to handle both.
>>>>>
>>>>> Actually, I use DW to do both. I have both pages open (the aspx
>>>>> page and the code-behind page). When I am handling the objects or
>>>>> the HTML, I just use switch to the aspx page and if I am working
>>>>> on the Subs, I switch to the code behind page. DWMX2004 does a
>>>>> decent job of using the asp.net objects. I have my issues with DW,
>>>>> but at least I can code the way I want and not the way DW wants me
>>>>> too.
>>>>>
>>>>> MS apparently won't let you do it your way (sound like a
>>>>> commercial). One of the problems with them.
>>>>>
>>>>> IMHO.
>>>>>
>>>>> Tom
>>>>>>
>>>>>> Larry
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>The Express products, particularly VWD for web development, have very similar characteristics to Visual Studio, and you'll be able to come up
to speed with ASP.NET 2.0 before you purchase Visual Studio, making a
faster transition.
"up to speed" is a lovely expression, especially considering the snail's
pace response of VWD. I downloaded that beta, and was quite impressed
with the product, but gave up with it very quickly due to it being
unbelievably slow to use. When viewing the HTML, it can take 10 seconds
to notice when I click my mouse somewhere else in the code. Typing lags
noticeably behind too.
I know I don't have the fastest machine going (PII 500MHz, 256Mb RAM),
but Visual Studio 6 (pre-.NET) runs like a dream, VWD crawls like an
asthmatic ant carrying a load of heavy shopping!!
--
Alan Silver
(anything added below this line is nothing to do with me)
>> if you are the only one working on the code, it seem a little overkill.
I disagree strongly. How is it overkill? Please elucidate.
Just to set the balance straight, I agree with the OP. I am a sole
developer and find code-behind makes life more complicated. Having all
the code in one file is much easier. That's not to say there aren't
advantages to code behind, but it's not as clear cut as you are making
out.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
How horrible! 6 to 8 open files! Sorry for being facetious, but that's a
very weak reason if one at all.
You are being unquestionably facetious and assuming that *your* style of
working must be the best for all. If you have several pages open at once
and you want to flip between HTML and code, then code behind forces you
to switch to another file. This can be quite disturbing to the mental
processes as you have to take your mind off the task at hand to deal
with the excise of switching windows.
Again, I'm not offering this as an absolute triumph of code-beside, but
it is a consideration, all other things being equal. Again, maybe your
working style doesn't have a problem with switching files so often, but
for many people this is distracting.
Things that are assumed on the .aspx page are not assumed on the codebehind
and have to be explicitly defined.
That's a good thing.
Why? It just makes extra work.
Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.
Yes, you should. Aside from your gripe about multiple open files you
haven't mentioned any reasons which would indicate that code-behind is
inferior in any situation. Code-behind separates data gathering and business
logic from presentation and is INCREDIBLY valuable.
In certain situations, yes. You are stomping your opinion on everyne
else's and assuming that the specific case(s) that you offer make
code-behind the only choice for everyone in every situation. This is
simply not true. You have to deal with each situation on its own merits.
Obviously there are advantages to code-behind, but there are advantages
to code-beside too, and you have to look at both before deciding. You
simply cannot lay down a blanket rule and say one is better.
Just to illustrate my point, let's say you are gathering data about
customers for a data table to distribute to your users. If your code is in
the ASPX, then sure, it might be faster to just pull all the data there and
be done with it (although my opinion is that it would take longer. ) What,
then, about when your users want the data in a different format? Say,
instead of a rows/columns datatable, a large detail format depicting each
item in full? Would you copy and paste the ASPX code, reformat, and make a
new copy of your page? If the data later changed, then you now have to
change your data gathering code in two places.
No, you would have the data gathering code in a separate module. This is
nothing to do with code-besides vs code-behind, this is reuse of code,
which can also be done with code-beside. You are implying that all of
the code for the page needs to be reused. In your example, only a very
small part of the code is going to be reused. That small part could be
put into a separate class, but you don't necessarily have to put all of
the code for the page separately as well.
Again, I'm not saying you shouldn't use code-behind, just that your
blanket rule is too simplistic to be useful. The case you give could be
done either way, and I don't see a huge benefit to code-behind from the
reuse of such a small piece of code, especially when that can be reused
either way.
In the same case, were you to have relegated the data gathering to a
codebehind you could have pushed that to its own class, separate from even
the page's codebehind, and simply coded a new ASPX page, included the class,
and bound the data.
Which you can do even with code-beside.
You could have picked a far better example if you wanted to champion
code-behind. Yours is hardly a killer argument.
And before you provide a better example, I would point out yet again
that it depends on the specific situation. Sometimes code-behind is the
obvious choice, sometimes it's just adding extra work for little or no
benefit.
Not using codebehind is ignoring one of the largest benefits of the dotNET
architecture, IMHO.
You're entitled to your opinion, but please don't state it as fact. Not
using code-behind *could*, in some case, ignore a big benefit of .NET,
but in other cases it would not make much (or any) difference. In some
cases it even makes more work.
And yes, this is *my* opinion, stated as opinion and not fact ;-)
--
Alan Silver
(anything added below this line is nothing to do with me)
It's really the wrong question. It's not a matter of "Code-Behind" versus
"Code-Beside." It's a matter of code organization in general. As ASP.Net app
is not a collection of unrelated Page classes. It is an application. It is
also object-oriented.
If you ever plan for extensibility, code-maintenance, and optimization,
separating various operations into classes is essential. If you're just
working on a simple and small app, it is less important. The larger and more
complex your apps are, the more you will benefit from the use of good
object-oriented principles, which includes abstraction, ploymorphism, and
encapsulation, as well as inheritance.
The Page's Code-Behind model is simply an extension of those principles.
People who don't like it generally are either working on very small
projects, and have never worked on large ones, or simply don't want to work
to learn OOP principles and application of them.
OOP is a learning curve. But it came about as a necessary extension of
procedural programming, and in response to the limitations of procedural
programming, just as Assembler was developed to improve productivity over
using Machine language. And if one is unwilling to adapt, think of the
consequences when the next generation of programming architecture comes out:
AOP (Aspect-Oriented Programming). AOP is coming soon!
Hang ten or die!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:6n**************@nospamthankyou.spam... if you are the only
one working on the code, it seem a little overkill.
I disagree strongly. How is it overkill? Please elucidate.
Just to set the balance straight, I agree with the OP. I am a sole
developer and find code-behind makes life more complicated. Having all the
code in one file is much easier. That's not to say there aren't advantages
to code behind, but it's not as clear cut as you are making out.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
How horrible! 6 to 8 open files! Sorry for being facetious, but that's a
very weak reason if one at all.
You are being unquestionably facetious and assuming that *your* style of
working must be the best for all. If you have several pages open at once
and you want to flip between HTML and code, then code behind forces you to
switch to another file. This can be quite disturbing to the mental
processes as you have to take your mind off the task at hand to deal with
the excise of switching windows.
Again, I'm not offering this as an absolute triumph of code-beside, but it
is a consideration, all other things being equal. Again, maybe your
working style doesn't have a problem with switching files so often, but
for many people this is distracting.
Things that are assumed on the .aspx page are not assumed on the
codebehind
and have to be explicitly defined.
That's a good thing.
Why? It just makes extra work.
Just trying to get other opinions on this, as I have already have about
30
pages designed and am trying to decide if I should split the files or
not.
Yes, you should. Aside from your gripe about multiple open files you
haven't mentioned any reasons which would indicate that code-behind is
inferior in any situation. Code-behind separates data gathering and
business
logic from presentation and is INCREDIBLY valuable.
In certain situations, yes. You are stomping your opinion on everyne
else's and assuming that the specific case(s) that you offer make
code-behind the only choice for everyone in every situation. This is
simply not true. You have to deal with each situation on its own merits.
Obviously there are advantages to code-behind, but there are advantages to
code-beside too, and you have to look at both before deciding. You simply
cannot lay down a blanket rule and say one is better.
Just to illustrate my point, let's say you are gathering data about
customers for a data table to distribute to your users. If your code is
in
the ASPX, then sure, it might be faster to just pull all the data there
and
be done with it (although my opinion is that it would take longer. )
What,
then, about when your users want the data in a different format? Say,
instead of a rows/columns datatable, a large detail format depicting each
item in full? Would you copy and paste the ASPX code, reformat, and make
a
new copy of your page? If the data later changed, then you now have to
change your data gathering code in two places.
No, you would have the data gathering code in a separate module. This is
nothing to do with code-besides vs code-behind, this is reuse of code,
which can also be done with code-beside. You are implying that all of the
code for the page needs to be reused. In your example, only a very small
part of the code is going to be reused. That small part could be put into
a separate class, but you don't necessarily have to put all of the code
for the page separately as well.
Again, I'm not saying you shouldn't use code-behind, just that your
blanket rule is too simplistic to be useful. The case you give could be
done either way, and I don't see a huge benefit to code-behind from the
reuse of such a small piece of code, especially when that can be reused
either way.
In the same case, were you to have relegated the data gathering to a
codebehind you could have pushed that to its own class, separate from even
the page's codebehind, and simply coded a new ASPX page, included the
class,
and bound the data.
Which you can do even with code-beside.
You could have picked a far better example if you wanted to champion
code-behind. Yours is hardly a killer argument.
And before you provide a better example, I would point out yet again that
it depends on the specific situation. Sometimes code-behind is the obvious
choice, sometimes it's just adding extra work for little or no benefit.
Not using codebehind is ignoring one of the largest benefits of the dotNET
architecture, IMHO.
You're entitled to your opinion, but please don't state it as fact. Not
using code-behind *could*, in some case, ignore a big benefit of .NET, but
in other cases it would not make much (or any) difference. In some cases
it even makes more work.
And yes, this is *my* opinion, stated as opinion and not fact ;-)
--
Alan Silver
(anything added below this line is nothing to do with me)
>If you ever plan for extensibility, code-maintenance, and optimization, separating various operations into classes is essential. If you're just
working on a simple and small app, it is less important. The larger and
more complex your apps are, the more you will benefit from the use of
good object-oriented principles, which includes abstraction,
ploymorphism, and encapsulation, as well as inheritance.
This is precisely the point I was making. Believe it or not, many of us
make our living on small applications that are highly unlikely to become
enterprise-scale applications. I often work on small apps and find that
many "best practice" techniques are overkill. Sure, when working on big
apps they are important, but sometimes they can just get in the way of
getting the job done.
As I said before, you have to judge each case on its own merits. There
are times when you will want one method, and times when you will want
another. Blanket statements claiming that code-behind (or anything else
for that matter) is the only correct way to do it are misleading and
incorrect.
Thanks for your reply.
--
Alan Silver
(anything added below this line is nothing to do with me)
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:KE**************@nospamthankyou.spam... If you ever plan for extensibility, code-maintenance, and optimization,
separating various operations into classes is essential. If you're just
working on a simple and small app, it is less important. The larger and
more complex your apps are, the more you will benefit from the use of
good object-oriented principles, which includes abstraction,
ploymorphism, and encapsulation, as well as inheritance.
This is precisely the point I was making. Believe it or not, many of us
make our living on small applications that are highly unlikely to become
enterprise-scale applications. I often work on small apps and find that
many "best practice" techniques are overkill. Sure, when working on big
apps they are important, but sometimes they can just get in the way of
getting the job done.
As I said before, you have to judge each case on its own merits. There are
times when you will want one method, and times when you will want another.
Blanket statements claiming that code-behind (or anything else for that
matter) is the only correct way to do it are misleading and incorrect.
These were the points I was trying to make and am glad to see someone else
thinking the same way I do.
I also feel that you need to look at the situations. Rarely is there only
*one* way to do anything. I just wanted to see the pluses and minus of both
styles.
Kevin really made the point.
"People who don't like it generally are either working on very small
projects, and have never worked on large ones, or simply don't want to work
to learn OOP principles and application of them".
I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the same
application at the same time. But if you are the only person, this
advantage is lost.
Just because you *can* do something, doesn't mean you *should* do something.
OOP is a good thing. But it isn't the only thing. I do build my own
classes, but I am not going to build a whole class for 2 lines of code.
I can see the advantages of both styles. But you can't make a choice until
you understand both styles.
Tom
> I think he slightly misses the point, as you were mentioning, that it is more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the same
application at the same time. But if you are the only person, this
advantage is lost.
I didn't miss any point. Do you know the average length of time it takes to
develop a habit? 6 weeks. So, assuming that you've been working with ASP.Net
for more than 6 weeks, you've already developed some habits. Now, let's say
you graduate from working on tiny applications to something of some size and
scope. It will take you another 6 weeks to teach yourself to do it right.
I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.
My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.
Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll never
be without a good-paying job.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl... "Alan Silver" <al*********@nospam.thanx> wrote in message
news:KE**************@nospamthankyou.spam... >If you ever plan for extensibility, code-maintenance, and optimization,
>separating various operations into classes is essential. If you're just
>working on a simple and small app, it is less important. The larger and
>more complex your apps are, the more you will benefit from the use of
>good object-oriented principles, which includes abstraction,
>ploymorphism, and encapsulation, as well as inheritance.
This is precisely the point I was making. Believe it or not, many of us
make our living on small applications that are highly unlikely to become
enterprise-scale applications. I often work on small apps and find that
many "best practice" techniques are overkill. Sure, when working on big
apps they are important, but sometimes they can just get in the way of
getting the job done.
As I said before, you have to judge each case on its own merits. There
are times when you will want one method, and times when you will want
another. Blanket statements claiming that code-behind (or anything else
for that matter) is the only correct way to do it are misleading and
incorrect.
These were the points I was trying to make and am glad to see someone else
thinking the same way I do.
I also feel that you need to look at the situations. Rarely is there only
*one* way to do anything. I just wanted to see the pluses and minus of
both styles.
Kevin really made the point.
"People who don't like it generally are either working on very small
projects, and have never worked on large ones, or simply don't want to
work
to learn OOP principles and application of them".
I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the same
application at the same time. But if you are the only person, this
advantage is lost.
Just because you *can* do something, doesn't mean you *should* do
something.
OOP is a good thing. But it isn't the only thing. I do build my own
classes, but I am not going to build a whole class for 2 lines of code.
I can see the advantages of both styles. But you can't make a choice
until you understand both styles.
Tom
>Just because you *can* do something, doesn't mean you *should* do something.
Perhaps the wisest words said today.
Perhaps not, but pretty sharp either way!!
--
Alan Silver
(anything added below this line is nothing to do with me)
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:JA**************@nospamthankyou.spam... Just because you *can* do something, doesn't mean you *should* do
something.
Perhaps the wisest words said today.
Perhaps not, but pretty sharp either way!!
--
Alan Silver
(anything added below this line is nothing to do with me)
This has nothing to do with Alan Silver. Oh darn. It has his name it it.
;-)
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ep**************@tk2msftngp13.phx.gbl... I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the
same application at the same time. But if you are the only person, this
advantage is lost.
I didn't miss any point. Do you know the average length of time it takes
to develop a habit? 6 weeks. So, assuming that you've been working with
ASP.Net for more than 6 weeks, you've already developed some habits. Now,
let's say you graduate from working on tiny applications to something of
some size and scope. It will take you another 6 weeks to teach yourself to
do it right.
You're assuming that code-beside is a bad habit.
Based on your last post, I think you are mixing arguments OOP is not
Code-behind. You called it an extension. I don't agree here. It would
take you a little while, as you correctly state, to learn new methods. OOP
will take a while to learn. But the difference between Code-Behind vs
Code-Beside is minimal, at least as far as I can fathom (and I could be
wrong here). Based on what I have seen, you can take a Code-Beside page -
take out the script section move it to another page - add some attributes to
the Page definition - On the code-behind page add the Namespace and Class as
well as a few imports that the aspx page takes for granted as well as the
defining the objects on the aspx page (I am getting tired just thinking
about it).
Any code you want to reuse you would put in a class (which you could do -
and should do - in either case).
I don't see a bad habit here.
Earlier it was mentioned:
"Not using codebehind is ignoring one of the largest benefits of the dotNET
architecture"
I don't agree here, either. I think the largest benefits of the dotNET
architecture is the *separation* of code from design elements (which you
didn't have in asp). A code-beside page does have the separation
(completely) from the design. It just happens to be on the same page.
I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.
I have been doing it for many more years than that (so I probably do have
some bad habits). More work in the short run does NOT always lead to less
work in the long run.
My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.
Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll
never be without a good-paying job.
Whether you use Code-behind vs Code-beside doesn't make a good programmer.
A good programmer, I guarentee you, can go from Code-beside to Code-behind
in no time at all. That doesn't mean he should.
Tom
> You're assuming that code-beside is a bad habit.
Not at all. I'm arguing that poor code organization is a bad habit. An
assumption is made without evidence. An argument, on the other hand,
provides evidence.
Also, note that I never made a specific argument about "Code-Behind." To
quote my earlier post: It's really the wrong question. It's not a matter of "Code-Behind" versus
"Code-Beside." It's a matter of code organization in general.
You're presuming, however that that is the issue I was discussing, and had
made assumptions about. The concept of organizing code is much broader, but
does apply to specific issues. I side-stepped the specific issue, as it is
merely a symptom of the bigger (deeper) issue. Whenever I encounter a
specific issue, I tend to step back and have a look at the forest, to see if
there is a broad principle that needs to be applied overall. Once the broad
issue of code organization is identified and understood, it can be applied
specifically to all areas of development.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:e$**************@TK2MSFTNGP10.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ep**************@tk2msftngp13.phx.gbl... I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't
like it, it is just less work. If it is a larger project, it may be
better in most cases to write code-behind. But the biggest advantage,
that I have been able to gleen from this, is that multiple people can
work on the same application at the same time. But if you are the only
person, this advantage is lost.
I didn't miss any point. Do you know the average length of time it takes
to develop a habit? 6 weeks. So, assuming that you've been working with
ASP.Net for more than 6 weeks, you've already developed some habits. Now,
let's say you graduate from working on tiny applications to something of
some size and scope. It will take you another 6 weeks to teach yourself
to do it right.
You're assuming that code-beside is a bad habit.
Based on your last post, I think you are mixing arguments OOP is not
Code-behind. You called it an extension. I don't agree here. It would
take you a little while, as you correctly state, to learn new methods.
OOP will take a while to learn. But the difference between Code-Behind vs
Code-Beside is minimal, at least as far as I can fathom (and I could be
wrong here). Based on what I have seen, you can take a Code-Beside page -
take out the script section move it to another page - add some attributes
to the Page definition - On the code-behind page add the Namespace and
Class as well as a few imports that the aspx page takes for granted as
well as the defining the objects on the aspx page (I am getting tired just
thinking about it).
Any code you want to reuse you would put in a class (which you could do -
and should do - in either case).
I don't see a bad habit here.
Earlier it was mentioned:
"Not using codebehind is ignoring one of the largest benefits of the
dotNET
architecture"
I don't agree here, either. I think the largest benefits of the dotNET
architecture is the *separation* of code from design elements (which you
didn't have in asp). A code-beside page does have the separation
(completely) from the design. It just happens to be on the same page.
I've been programming for about 10 years now. This is not theory; it is
my experience. In my experience, more work in the short run always leads
to less work in the long run. Today is gone tomorrow. But tomorrow is
always just around the bend.
I have been doing it for many more years than that (so I probably do have
some bad habits). More work in the short run does NOT always lead to less
work in the long run.
My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.
Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll
never be without a good-paying job.
Whether you use Code-behind vs Code-beside doesn't make a good programmer.
A good programmer, I guarentee you, can go from Code-beside to
Code-behind in no time at all. That doesn't mean he should.
Tom
>> Alan Silver (anything added below this line is nothing to do with me)
This has nothing to do with Alan Silver. Oh darn. It has his name it
it.
;-)
You would be amazed what I get the blame for!! Even things without my
name on. If my name is on, then I'm *really8 in trouble!!
--
Alan Silver
(anything added below this line is nothing to do with me)
>> I think he slightly misses the point, as you were mentioning, that it is more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the same
application at the same time. But if you are the only person, this
advantage is lost.
I didn't miss any point. Do you know the average length of time it takes to
develop a habit? 6 weeks. So, assuming that you've been working with ASP.Net
for more than 6 weeks, you've already developed some habits. Now, let's say
you graduate from working on tiny applications to something of some size and
scope. It will take you another 6 weeks to teach yourself to do it right.
Well, each of us is different, so I guess we can happily agree to have
different ideas on this, but I have more than one behaviour pattern and
can change from one to the other depending on the situation.
This doesn't just apply to programming, it applies to being a father,
running a voluntary organisation, almost anything in life. I have
behaviour patterns suited to different situations. In the case of web
programming, I have ASP behaviour patterns that I apply for small sites,
and ones I apply for larger sites. I use whichever is appropriate. I
rarely get it wrong nowadays, and rarely (almost never) waste any time
with short-term conveniences that lead to long-term problems.
I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.
You are of course entitled to your experience and your opinion, as long
as you accept them for the subjective points that they are. I have been
programming for over 20 years (yup, I'm that old!!), and have learnt how
to distinguish between a small job and one that may grow. I can't
remember the last time I got that wrong. I apply the behaviour pattern
that suits best.
My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.
Correct. But developing best practices does *not* mean applying one
mindset to every situation, it means being flexible enough to know what
to do in any situation.
Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll never
be without a good-paying job.
Well, I think the current IT slump might prove you wrong, there are
plenty of good programmers who can't get jobs, not because they aren't
good, but because there aren't always enough jobs, and managers are
being convinced that anyone can program. They are shown slick
presentations where someone creates an apparently complex application
from scratch in about ten minutes using the latest Visual Studio RAD
tools. They go away believing that a student fresh out of college can do
the same job as a highly trained and experienced professional with 20
years' experience. That's bad for everyone.
Ta ra
--
Alan Silver
(anything added below this line is nothing to do with me)
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl... You're assuming that code-beside is a bad habit.
Not at all. I'm arguing that poor code organization is a bad habit. An
assumption is made without evidence. An argument, on the other hand,
provides evidence.
I agree.
But the fact that you use Code-beside, doesn't mean your code is poorly
organized. Alan made this point very well.
This is not to say that I disagree with using Code-Behind, because I don't.
Also, note that I never made a specific argument about "Code-Behind." To
quote my earlier post:
It's really the wrong question. It's not a matter of "Code-Behind" versus
"Code-Beside." It's a matter of code organization in general.
But this was the whole discussion. The benefits of one over the other.
Putting the code in a separate file (physically separated) or in the same
file (where it is logically separated) does not make it more organized.
Reuse of code would not necessarily be in your Code-Behind, anyway, but
could be in a different class.
You're presuming, however that that is the issue I was discussing, and had
made assumptions about. The concept of organizing code is much broader,
but does apply to specific issues.
I agree here.
I side-stepped the specific issue, as it is merely a symptom of the bigger
(deeper) issue. Whenever I encounter a specific issue, I tend to step back
and have a look at the forest, to see if there is a broad principle that
needs to be applied overall. Once the broad issue of code organization is
identified and understood, it can be applied specifically to all areas of
development.
But then you miss the point of the question when you do this. If I want the
parameters of a particular call, I don't want to know bigger issue.
I never disagreed with your points, only that it was the only way or the
best way in *all* situations.
Tom
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:8p**************@nospamthankyou.spam... I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't
like
it, it is just less work. If it is a larger project, it may be better
in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the
same
application at the same time. But if you are the only person, this
advantage is lost.
I didn't miss any point. Do you know the average length of time it takes
to
develop a habit? 6 weeks. So, assuming that you've been working with
ASP.Net
for more than 6 weeks, you've already developed some habits. Now, let's
say
you graduate from working on tiny applications to something of some size
and
scope. It will take you another 6 weeks to teach yourself to do it right.
Well, each of us is different, so I guess we can happily agree to have
different ideas on this, but I have more than one behaviour pattern and
can change from one to the other depending on the situation.
This doesn't just apply to programming, it applies to being a father,
running a voluntary organisation, almost anything in life. I have
behaviour patterns suited to different situations. In the case of web
programming, I have ASP behaviour patterns that I apply for small sites,
and ones I apply for larger sites. I use whichever is appropriate. I
rarely get it wrong nowadays, and rarely (almost never) waste any time
with short-term conveniences that lead to long-term problems.
I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.
You are of course entitled to your experience and your opinion, as long as
you accept them for the subjective points that they are. I have been
programming for over 20 years (yup, I'm that old!!), and have learnt how
to distinguish between a small job and one that may grow. I can't remember
the last time I got that wrong. I apply the behaviour pattern that suits
best.
Me too. Hard to believe, sometimes.
My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.
Correct. But developing best practices does *not* mean applying one
mindset to every situation, it means being flexible enough to know what to
do in any situation.
Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll
never
be without a good-paying job.
Well, I think the current IT slump might prove you wrong, there are plenty
of good programmers who can't get jobs, not because they aren't good, but
because there aren't always enough jobs, and managers are being convinced
that anyone can program. They are shown slick presentations where someone
creates an apparently complex application from scratch in about ten
minutes using the latest Visual Studio RAD tools. They go away believing
that a student fresh out of college can do the same job as a highly
trained and experienced professional with 20 years' experience. That's bad
for everyone.
I can tell you from experience that this is the case.
Tom
Ta ra
--
Alan Silver
(anything added below this line is nothing to do with me)
Understood, Alan. I wasn't specifically trying to tell you what to do. I was
posting for the benefit of everyone who reads the thread. Of course, each of
us must make their own decisions regarding what is best. Well, I think the current IT slump might prove you wrong, there are plenty
of good programmers who can't get jobs, not because they aren't good, but
because there aren't always enough jobs, and managers are being convinced
that anyone can program. They are shown slick presentations where someone
creates an apparently complex application from scratch in about ten
minutes using the latest Visual Studio RAD tools. They go away believing
that a student fresh out of college can do the same job as a highly
trained and experienced professional with 20 years' experience. That's bad
for everyone.
I do have to disagree with this point. Managers, like programmers, are a
dime a dozen. Good managers are rare. But the good managers know how to find
and hire the good programmers! ;-) I, for one, have never had trouble
finding work. I did have to give up my independent consulting business when
the DotCom crash broke out, but I've had several good jobs since then, and
more offers than I care to have to deal with.
As my old Drill Sergeant taught me many years ago: The maximum effective
range of an excuse is 0 meters.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:8p**************@nospamthankyou.spam... I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't
like
it, it is just less work. If it is a larger project, it may be better
in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the
same
application at the same time. But if you are the only person, this
advantage is lost.
I didn't miss any point. Do you know the average length of time it takes
to
develop a habit? 6 weeks. So, assuming that you've been working with
ASP.Net
for more than 6 weeks, you've already developed some habits. Now, let's
say
you graduate from working on tiny applications to something of some size
and
scope. It will take you another 6 weeks to teach yourself to do it right.
Well, each of us is different, so I guess we can happily agree to have
different ideas on this, but I have more than one behaviour pattern and
can change from one to the other depending on the situation.
This doesn't just apply to programming, it applies to being a father,
running a voluntary organisation, almost anything in life. I have
behaviour patterns suited to different situations. In the case of web
programming, I have ASP behaviour patterns that I apply for small sites,
and ones I apply for larger sites. I use whichever is appropriate. I
rarely get it wrong nowadays, and rarely (almost never) waste any time
with short-term conveniences that lead to long-term problems.
I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.
You are of course entitled to your experience and your opinion, as long as
you accept them for the subjective points that they are. I have been
programming for over 20 years (yup, I'm that old!!), and have learnt how
to distinguish between a small job and one that may grow. I can't remember
the last time I got that wrong. I apply the behaviour pattern that suits
best.
My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.
Correct. But developing best practices does *not* mean applying one
mindset to every situation, it means being flexible enough to know what to
do in any situation.
Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll
never
be without a good-paying job.
Well, I think the current IT slump might prove you wrong, there are plenty
of good programmers who can't get jobs, not because they aren't good, but
because there aren't always enough jobs, and managers are being convinced
that anyone can program. They are shown slick presentations where someone
creates an apparently complex application from scratch in about ten
minutes using the latest Visual Studio RAD tools. They go away believing
that a student fresh out of college can do the same job as a highly
trained and experienced professional with 20 years' experience. That's bad
for everyone.
Ta ra
--
Alan Silver
(anything added below this line is nothing to do with me)
>Good managers are rare. But the good managers know how to find and hire the good programmers! ;-)
You've just disproved your own argument. Good managers are rare,
therefore the number of managers hiring good programmers are rare. So
the good programmers don't necessarily get the jobs.
--
Alan Silver
(anything added below this line is nothing to do with me)
> You've just disproved your own argument. Good managers are rare, therefore the number of managers hiring good programmers are rare. So the good
programmers don't necessarily get the jobs.
You didn't read carefully. I said that the good managers know how to find
and hire the good programmers. Since both good programmers and good managers
are rare, the number of each is such that neither good managers go wanting
for good programmers, nor do good programmers have a hard time finding jobs.
And I backed it up with my own experience.
A programmer is a problem-solver. Lack of employment is a problem. Good
programmers, who are by nature good problem-solvers, approach the issue as a
problem and solve it. Average programmers look at what everyone else is
doing, and try that.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:JY**************@nospamthankyou.spam... Good managers are rare. But the good managers know how to find and hire
the good programmers! ;-)
You've just disproved your own argument. Good managers are rare, therefore
the number of managers hiring good programmers are rare. So the good
programmers don't necessarily get the jobs.
--
Alan Silver
(anything added below this line is nothing to do with me)
My recommendation is that if your application isn't very complicated, to
simply put all your code behind into a single file. Multiple classes can
exist within the same codebehind file and it makes for one central location
where you can go to modify all logic for your entire application.
I've developed many small apps in dreamweaver using this method and find it
quite streamlined. Less files to edit, less files to upload, etc.
"tshad" wrote: I am just trying to decide whether to split my code and uses code behind. I
did it with one of my pages and found it was quite a bit of trouble.
I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the only
one working on the code, it seem a little overkill.
I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.
If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I would
need to run over to the person working on the codebehind and tell him to add
the new object to his page.
Things that are assumed on the .aspx page are not assumed on the codebehind
and have to be explicitly defined.
None of this is really talked about when codebehind is mentioned. Normally,
you are told that it is better. Is this the case in all situations?
Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.
Thanks,
Tom
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Richard Dixson |
last post by:
I created a new C# web application. Basically all I am trying to do is
create a table that consists of a few rows with two columns in each. And
then to set those columns to text values from my...
|
by: Paolo Pignatelli |
last post by:
I have an aspx code behind page that goes something like this in the HTML
view:
<asp:HyperLink id=HyperLink1 runat="server"
NavigateUrl='<%#"mailto:" &...
|
by: tshad |
last post by:
Many (if not most) have said that code-behind is best if working in teams -
which does seem logical.
How do you deal with the flow of the work?
I have someone who is good at designing, but...
|
by: John Rivers |
last post by:
Hello,
What good reason there is for not allowing methods in ASPX pages I
can't imagine, but here is how to get around that limitation:
(START)
<body MS_POSITIONING="FlowLayout">
<form...
|
by: Me |
last post by:
Hi,
I inherited a web application that has several very similar forms for
gathering user data. User's must choose the form that best fits their needs
and fill it out. Each form has about 15...
|
by: Alan Silver |
last post by:
Hello,
I am just looking at VWD and seeing what needs doing to take an existing
site I've written by hand and importing it into VWD. I've already
discovered that I need to rename my code-behind...
|
by: Alan Silver |
last post by:
Hello,
I have installed the 2.0 framework, and am looking at converting some of
my 1.1 pages to use partial classes. I don't (yet) have VS2005, so I'm
doing this by hand, but am having problems....
|
by: walter |
last post by:
Hi, when I add a new page in my asp.net 2 project and put some controls
there, everything works fine until I move the code behind into App_Code
folder.--When I compile , it tells me that control...
|
by: rn5a |
last post by:
Assume that a user control (MyUC.ascx) encapsulates 2 TextBoxes with
the IDs 'txt1' & 'txt2' respectively. To use this user control in an
ASPX page, the following Register directive will be...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
