"Dave Anderson" wrote in message
news:Of**************@TK2MSFTNGP15.phx.gbl...
: Roland Hall wrote:
: >> The advantage of using tokens is simple: The HTML template
: >> can be contiguous, and handled by someone else with a
: >> completely different set of tools (like Dreamweaver).
: >
: > You have a flunky writing your client-side code that doesn't
: > ever mix with your server-side variables and yet you somehow
: > pass those to the client?
:
: There is nothing "flunky" about graphic designers. They possess skills
that
: neither you nor I do. It is arrogant and ignorant to assume they have
: nothing to contribute to application design.
You have no idea what my skills are re: graphic design, missy. A 'flunky'
is a subordinate and I said client-side code. I made no reference to a
graphic designer. Graphic designers are not usually flunkies to developers,
they're peers. The only difference in being a flunky for any industry is
whether you take direction or give it.
: As for your shock and awe at the notion that different people can work on
: the client-side and the server-side code, all I can say is, "Get over it".
Clearly that's not all you can say, as I see you're continuing.
: People work collaberatively in a wide variety of settings every day. Web
: development is one of those settings.
That's great but that doesn't happen in small shops and there are many more
small shops than there are large ones. Don't assume everyone's setup is
like yours.
: > I call Dreamweaver a stool, not a tool. What was that catchy phrase?
: > Ah, to each his own.
:
: How astute of you to seize upon my example. In truth, I don't know or care
: what tools are used to produce the HTML templates for the applications.
Nor
: do I care what tool was used to create the graphics therein. The final
: product is what matters. To each his own. Truly.
Then why choose something that is designed for non-developers as a variable
and then dismiss it when it's thrown back at you? I think you could take
both sides of the argument yourself and the rest of us could just read,
trying to follow along, but confused as ever, as the target seems to
constantly move.
: >> Scripting actual tags is a nightmare for validation and maintenance
: >> purposes, so we avoid it as much as possible.
: >
: > Which means you don't avoid it.
:
: Absolutely correct. We have identified some tasks where it makes sense to
: generate tags outside the templates.
:
: One example is a method construct a set of <option> tags from any array.
In
: practice, the page constructor might contain something like this...
:
: this.DeptList = Depts.toOptions(Request.Form("Department").Item)
:
: ...and the template would include this...
:
: <select name="Department"><%=Page.DeptList%></select>
And, in your previous post you said you never do that. Shame on your for
mixing ASP server tags in with your HTML. Oh wait, YOU never do it. Your
flunky does. (O:= I know, I know. It's what you're mixing, not HOW you're
mixing, although my first comment was HOW before the conversation went to
Hell.
: The template author need not worry about the contents of the <select>
: element -- only the name of the control itself and the name of the token
for
: its contents.
Token, schmoken. You're still mixing.
: >> In my environment, all server-side processing[1] occurs before
: >> a single line of HTML is parsed.
: >
: > Which means you have to put in ASP script blocks to pass values
: > from the server-side to the client.
:
: Not quite. I use interlaced output to create a document. Flushing the
buffer
: sends the document to the client. Values are implicitly -- not
explicitly --
: passed to the client.
'interlaced' ooh, aah, 'flushing' ooh, ahh, 'implictly' vs 'explicitly' ooh,
aah...
I'm setting up a cross-reference to refer to so when I read your posts I
know what the Hell you're talking about. Must be due to my sloppy reading
skills.
: Honestly, Roland, I think you're a sloppy reader. I used the word "parsed"
: because I meant "parsed". If I wanted to say "pass values to the client",
I
: would.
Slam count: 12
Actually I think you're too much in touch with your feminine side. Where
does all this emotion come from?
: >> ...which I would never advocate anyway, since I do not mix
: >> processing and rendering.
: >
: > Which is what you do.
:
: No. You can play all the semantic games you want, but there are two
clearly
: different types of task you perform with an ASP script: those that
directly
: construct the output document, and those that do not. Examples of the
first,
: or "rendering" task:
:
: . <html>
: . <%=MyVar%>
: . Response.Write(MyVar)
Never see code like that work but ok. I guess lines 1 and 2 should be read
separately from line 3. As Sarge would say in Quake III Arena, "Sloppy
soldier, sloppy!"
: Examples of the second, or "processing" task:
:
: . Server.CreateObject(...)
: . RS.MoveNext()
Considering I don't do recordset looping, I'm sloppily reading this and
missing it entirely.
: In almost all cases, it is possible to separate processing from rendering.
:
: I suppose there is at least one special case - an act that has nothing to
do
: with constructing a document, but which cannot *usefully* be abstracted
from
: the processing portion: Response.Flush(). But in my experience, documents
: that needs Response.Flush() are typically utility scripts, and as such are
: not "templated".
Perhaps you're just too smart for me Dave... or too emotional. I see it one
of two ways and you see a myriad yet you accuse me of bringing semantics to
the table.
--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center -
http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation -
http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library -
http://msdn.microsoft.com/library/default.asp