In article <uWp#>, Homer J. Simpson
<root@127.0.0.1> writes
<snip>
>>> Can I control that? I'd like to keep organizing things in separate .css
>>> files, but don't necessarily want them *all* automatically included in
>>> aspx pages that don't need them.
>>
>> One of my long-time gripes with themes. I have tried to find a solution to
>> this and failed.
>
>Hearing this sort of thing isn't particularly encouraging, especially when
>this is one of the very first things ever I've tried doing in .NET beyond a
>Hello, World page...I've been holding off on learning .NET for a very long
>time (I've skipped 1.0 and 1.1 entirely), and now that I'm knee-deep into
>it, the reality is such a huge contrast to the endless praise I've been
>hearing for years...
Maybe I should qualify the comment by saying that having done ASP.NET
for a couple of years now, it is *way* better than classic ASP. Once you
get into the swing of it, you wonder how you ever did classic at all. I
look back at old sites and cringe at how badly they were implemented.
That's partly my fault and partly MS's. ASP.NET does encourage you to
make a complete separation between code and output (ie the (X)HTML), and
that's a very powerful and positive step forwards.
I could list grips I had with classic ASP was well. You just happen to
have hit one I have with ASP.NET. Themes are still a great idea, they
just need some improvement. Even as they are, they are a load better
than doing the same idea yourself.
>Anyway...I don't know if this can be useful to you, coming from a noob such
>as myself...I ended up implementing some suggestion I've stumbled upon in
>some other forums. For now, I'm willing to forget all about themes.
>Essentially, I put a reference to my "base" CSS file in my master page's
><head> as one normally would:
<snip>
Thanks for the idea. It's worth considering. You would need some central
mechanism for controlling which page got which CSS file though,
otherwise you would end up with a real mess.
>>>From what I've been seeing, there's an awful lot of books that introduce
>>>various ASP.NET topics, but very few present things in a "this is how you
>>>now do things if you're from a classic HTML/ASP background" fashion.
>>
>> There are a few, but given that the two are *so* different, you're
>> actually better off forgetting (almost) everything you learnt about
>> classic ASP and reading Asp.NET books as though it was something entirely
>> new.
>
>While I don't necessarily disagree, the intent behind that observation was
>just to suggest that I'm convinced there's a market for it. How many
>long-time classic ASP coders have moved on to ASP.NET and would buy a book
>to assist with the transition, as opposed to the endless supply of help-file
>type of books?
Dunno. I tried adapting my classic ASP way of thinking, then realised
that it was confusing rather than helping. I bought ASP.NET Unleashed by
Steven Walther and treated myself as a beginner. It was one of the best
books of it's type I ever read and got me going fast. I still use it
sometimes.
>> Read these forums for a bit and see how many people struggle with the
>> changeover. Most of them suffer from trying to make ASP.NET work in the
>> classic ASP way. It's far better to make a clean break and treat it as a
>> new subject entirely.
>
>It's really a matter of using the right tool for the right job... On one
>hand, if something is doable in ASP.NET but is completely awkward, then
>that's an indication that I (as a .NET newbie) don't fully understand the
>how and the why. On the other, I'd rather stick with the tried-and-true
>methods where it makes sense, and not do absolutely everything "the .NET
>way" just because this is what MS suggests.
Trouble is, the "tried and true" method for classic ASP is often
completely the wrong method for ASP.NET and vice-versa. That's why I
suggested approaching ASP.NET as a newbie, it avoids the problem of
thinking you know the best way to do something, when really the way you
have in mind might be completely inappropriate for ASP.NET. It really is
a new (but highly (superior) way of thinking.
>For one--and it's still early in my learning process--I find that ASP.NET
>generates *way* more inline styles (as tag attributes) than I would ever
>hand-code, especially when "the old method" can be rewritten in a much
>cleaner CSS file in a line or two. I find having some server control
>attributes in an aspx file, along with separate CSS files, really confuses
>matters. And then, of course, not all attributes you can put in a CSS file
>can be specified as server control attributes either, so I really have no
>choice but to have some styles specified in one location, and others
>specified elsewhere...I feel I'm stepping backwards.
Hmm, sounds more like a structure issue than a problem with the way
ASP.NET handles it. I'd need to see a more concrete example before I
could say though.
I do agree about some of the markup produced by the framework. I quickly
learned never to use the Label control as it creates extra markup you
just don't need. My code tends to have things like...
<h2><asp:Label ID="fred" runat="server" /></h2>
....so I can just set the value of the literal, and know that the markup
will be clean.
I do all of my presentation with CSS, so the .aspx file tends to be very
vanilla (X)HTML and nothing more. That keeps the separation between
content and presentation very well, making better structured pages and a
much easier implementation of themes.
>>>Finding the exact keywords on Google to find relevant results for this
>>>sort of thing also seem to escape me...
>>
>> Yeah, that can be a problem too. That's where these groups are so good!
>
>Yeah, but my gripe is that it's often quicker to find a relevant answer and
>get right back to work than posting a new message and waiting for a
>response. No offense to anyone here--I'm a long-time Usenet user...it's
>just the nature of things...
Yup, you need to do both.
Ta ra
--
Alan Silver
(anything added below this line is nothing to do with me)
Similar Threads
