The basic idea behind the ASP.Net CodeBehind model is that it is difficult
to both develop and especially maintain the software when interface HTML and
executable server-side code are mixed up together. I agree wholeheartedly
with this philosophy, as I have had to work on far more than my share of
poorly-organized ASP code. Good coding practice dictates that code should be
well-optimized, well-organized, and well-conceived. The placement of the
code in the HTML would have very little effect on the actual execution of
the Page. However, it might have a great effect on how long it would take
another developer to make any changes in the Page in the future.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
"Patrice Scribe" <no****@nowhere.com> wrote in message
news:Or**************@TK2MSFTNGP12.phx.gbl...
Something that could be perhaps acceptable is :
- if no programmatic id, you can't access it from your code behind. Inline
code is allowed.
- if a value is set once but never changed (such as a common function that
would retrieve localized strings from a database), inline code allowed.
If the value can change depending on the events (for example you change
the image if you meet some other condition at load time or after a postback or
whatever else) keep it in code, inline code to be avoided.
Basically the idea would be to allow inline code for one time
initialization expressions and to avoid inline code when you have some further processing
for this property... Of course always a matter of personal taste...
Patrice
--
"Michael" <raterus@localhost> a écrit dans le message de
news:OH**************@tk2msftngp13.phx.gbl... What is the general opinion of having code in the html section of an asp.net page. For example..
<img src="<%=myImageString%>" />
I see something like that done many times in examples, but I'm wondering
if this is a good practice, or something to be avoided. If one of the
goals of asp.net was to separate html from code, this just seems to be going back
to the old "asp" ways.