Re: Treeviews
From: Pete Dashwood (dashwood_at_enternet.co.nz)
Date: 02/24/05
- Next message: Richard: "Re: Treeviews"
- Previous message: Rick Smith: "Re: Cross-language challenge (of POSSIBLE interest)"
- In reply to: Richard: "Re: Treeviews"
- Next in thread: Richard: "Re: Treeviews"
- Reply: Richard: "Re: Treeviews"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 24 Feb 2005 12:35:44 +1300
Richard,
I don't take issue with your observations, but there are a few points of
fact that may have been overlooked... see below.
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1109131731.753197.196380@g14g2000cwa.googlegroups.com...
> > Most of the stuff I am doing currently is web based, I'm using ASP
> (looking
> > at PHP)
>
> It seems to me that the server side web stuff is divided into two
> groups. On one side there is ASP, PHP, JSP. On the other side there
> is Java srvlets, CGI, Perl and other scripts.
>
That is a fair comment, but it isn't quite as rigid as that. (see below).
> The first group is 'code in page': the html web pages incorporate
> server side code that executes to extract data base stuff. The second
> group is 'page in code': the program runs and builds the data then
> writes out the html for the web page.
Hmmm... certainly ASP runs on the server, but so do the items in your second
group.
>
> In many cases both of these approaches mingle the program code and the
> html in ways that make then inseparable. I hate that.
>
Me too. But it doesn't HAVE to be like that. You CAN intermingle client side
HTML and JavaScript with ASP code but it is not a REQUIREMENT.
I have found through experience that completely separating ASP code to
BEFORE the <HTML> tag helps immensely. (It also allows non-persisting
(session duration only) cookies to be served in the Browser header, so that
state can be easily maintained without reliance on Session or Application
scope. Of course, some people don't allow cookies, but I am prepared to
'lose' those people. The cookies I am talking about are NOT stored on the
Client hard drive)
My smart pages have their ASP procedures at the start. These procedures are
written in JavaScript (within ASP delimiters, simply using JavaScript as the
language. The default is VBScript, but I have more affinity with Java than I
do with VB.)
> > It would be pointless without OO and components.
>
> Ah, now here is the crux of the matter. When using ASP or JSP etc the
> code is buried in the web page and this means that it may need to be
> duplicated if the same result is required in a different page. The
> 'solution' is to extract the code and make it into a component so that
> it can be accessed from two or more pages.
Well, Richard, that is ONE solution. You can also use SSI from ASP and
simply include your (single copy of) source where you want it.
>
> Leastways this is how JSP solves the problem, though I think that JSP
> is just a means for Java to have a 'me too' workalike for ASP and
> wouldn't otherwise be used at all.
>
<G> You could be right...
> It still seems to me to be a backwards solution to a problem that
> shouldn't exist in the first place.
>
> ASP, JSP and PHP (and mod-Perl if you prefer that) are 'web page
> writers' languages. The users want to design the pages and then fixup
> the issue of 'how do I get the data in here'.
Yes, that is a fair description. Realise though that you can write ASP in
either VBScript or JavaScript or any other language you like - Perl, PHP,
whatever...(I'm currently experimenting with COBOL as script, just for the
Hell of it...), PROVIDED you make the appropriate Registry Script Engine
entries, ensure your language is COM compliant, and ensure the code uses
'RUNAT = server' attribute of the <SCRIPT> tag. This is possible because of
components (In this case ActiveX - impossible without OO...).
OTOH Servlets, Perl and
> so on tend to be 'programmers' languages where they extract the data
> and then kludge up something to get the html out to the user.
>
Some people do. Not me... <g>
> I use templating (I may have mentioned this). To me that fits into the
> middle between ASP/JSP and the usual scripting/Perl/servlets approach
> (though Perl does have templating). While it runs as a typical script
> it completely separates the presentation from the code. This has some
> advantages. For example if you wnat that table of invoices in a usable
> format then just get the program to use a different template that
> outputs csv instead of html.
>
Yes, I agree with that approach, Richard, and use something very similar for
CGI code. My CGI code invariably uses templates. So far, I haven't found the
need for it with ASP but it is very simple to include a template then modify
it, under ASP.
In fact, I believe ASP, properly designed, can replace CGI code completely.
> > and Javascript.
>
> Javascript is client side, though it is just built into the html page
No, as I tried to describe above, it can be client or server side, depending
on where and how you write it.
> just as ASP/JSP/PHP is.
All of my ASP is server side. (I didn't know it could run client side; are
you sure about that?)The Active Server Pages engine resides on the server
and 'scans' each page before it is served up. This enables dynamic HTML to
be generated on the page or existing HTML on the page to be modified. HTML
(client side) scripts on the page can utilise ASP to replace variables, get
query strings, and so on, BEFORE the page ever reaches the client.
Half the fun of designing in this environment is working out what needs to
be server side and what needs to be client side. Avoiding 'round trips' is
very satisfying.... for example, I realised yesterday that where (in ASP
server side code) I was using Response.Redirect() to switch pages (this
involves sending an HTTP header to the Browser) I could save this trip to
the client side by using Server.Transfer() which does it immediately. I
noticed a response improvement in several pages...
I find it a very flexible and powerful solution.(Sadly, it is far removed
from COBOL and the procedural paradigm.)
Pete.
- Next message: Richard: "Re: Treeviews"
- Previous message: Rick Smith: "Re: Cross-language challenge (of POSSIBLE interest)"
- In reply to: Richard: "Re: Treeviews"
- Next in thread: Richard: "Re: Treeviews"
- Reply: Richard: "Re: Treeviews"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
