Need help clarifying use of VBxxx for creating webpages ...

[brooksr]

I know VB5/VBA very well but have not used VB to create web pages but
need to do so.

Can someone explain the purposes and differences between VBScript and
VB.NET to create web pages?

Also where do Visual Web Developer Express Edition and Microsoft
Frontpage fit into the picture?

It seems there are a bewildering array of choices in creating websites
using Microsoft tools.

Appreciate any help.

Brooks

[Bob Barrows [MVP]]

brooksr wrote:

I know VB5/VBA very well but have not used VB to create web pages but
need to do so.

Can someone explain the purposes and differences between VBScript and
VB.NET to create web pages?

Also where do Visual Web Developer Express Edition and Microsoft
Frontpage fit into the picture?

It seems there are a bewildering array of choices in creating websites
using Microsoft tools.

It's even more bewildering when you consider non-MS tools such as
Dreamweaver or Cold Fusion.

vbscript is used in "classic" asp, which this newgroup hierarchy covers.
VB.Net is used in ASP.Net, which is a completely different technology
covered by newsgroups in the "dotnet" hierarchy, specifically
microsoft.publi c.dotnet.framew ork.aspnet, as well as the forums at
www.asp.net

The differences? I'll start with the languages: vbscript is a limited
scripting language. VB.Net is a full-blown object-oriented language.

Classic ASP is essentially server-side code which generates html which is
passed to the client. The only interaction with the client is done via the
Request object which has collections (Request.Form and Request.Queryst ring)
containing data passed from the client via form submissions, and the
Response object which is use to pass html to the client browser. So there is
a definite line of demarcation between asp server-side code and client-side
dhtml code. We try to concentrate on server-side coding questios in this
group, directing client-side scripting questions to
microsoft.publi c.scripting.jsc ript. Here is a link to the ASP Scripting
documentation:
http://msdn.microsoft.com/library/en...f33a651779.asp

ASP.Net is more interactive. It provides gui controls that can trigger
events in server-side code via postbacks. So the line between server-side
and client-side events is definitely blurred. Compiled code has performance
benefis compared to the interpreted vbscript code.

Frontpage, which many of us don't even use, is intended to be used to create
html pages in a wysiwyg environment. The reason most of us don't use it is:
1. earlier versions would mess up our asp server-side code
2. it creates crappy, bloated, nonstandard html
3. it prevents developers from learning html, which is really an essential
skill, especially in the classic asp world (don't get me wrong: it is still
essential in the ASP.Net world) Here are some grojups that concentrate on
HTML and CSS: http://groups.google.com/groups/dir?sel=33584039
I cannot think of a reason to use Frontpage for ASP.Net development: in
fact, MS is phasing the product out

VWD can be used with both classic ASPand ASP.Net applications, but is
definitely more geared toward ASP.Net.
IMO, ASP.Net was intended to bring the website development experience closer
to the VB5/6 application development experience, so you would probably be
better off starting with ASP.Net rather than classic ASP.

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[brooksr]

Thanks so much for that post, Bob, it's excellent. Probably going to
take some time for me to absorb it all.

Let me ask some follow up questions:

So VBScript and (plain) ASP are 'classic ASP', while VB.NET and ASP.NET
are 'modern' ASP?

I understand that VB.NET is a part of Visual Studios and that a free
version, VB Express, is available for download and may meet many
developers' needs ...

So server side code resides on a web hosting site that I would use. If
you are not using FP, how do you get the code onto the server? Do you
still 'publish' it somehow?

When you speak of client side, you basically mean a user accessing the
internet via a browser, like IE, correct?

I read that many VB developers and even some book authors were angry at
how Msft changed VB in moving from VB6 to VB.NET, but it seems like a
moot point not worth wasting time on. Also, maybe drastic changes were
necessary to move to a full internet environment ...

So is ASP.NET a language? Does it have a wysiwyg interface that can
replace FP's? If not, what is a good substitute for FP? (I own the 97
and 2000 versions of it).

I'm still a little unclear how VWD and VBE relate to one another? If I
learn VWD do I still need VBE? If I need both, which should I learn
first?

What is dhtml and how does it differ from html?

Brooks

[brooksr]

A few more questions ...

Not to be a wise guy, but if you feel VBScript and classic ASP are
inferior to ASP.NET, why would you spend your time in this forum? Is
it because of legacy code?

Why should client side scripting be written in jscript? Isn't jscript,
just the C/C++/Java version of VBScript?

We try to concentrate on server-side coding questios in this
group, directing client-side scripting questions to
microsoft.publi c.scripting.jsc ript.

Brooks

[Bob Barrows [MVP]]

brooksr wrote:

A few more questions ...

Not to be a wise guy, but if you feel VBScript and classic ASP are
inferior to ASP.NET, why would you spend your time in this forum? Is
it because of legacy code?

I never said they were inferior. The right tool for the job ... and what you
are used to. I recommended ASP.Net to you, because I feel there would be
less of a pardigm shift for you since you are coming from a VB/VBA
background.

But, yes, I do have a lot of legacy code I still need to maintain, as do the
other users of this newsgroup. There is no way I would have the time to
convert all that legacy code to .Net. And there is no reason to.

>
Why should client side scripting be written in jscript? Isn't
jscript, just the C/C++/Java version of VBScript?

No. jscript is the MS implementation of javascript, which actually came from
something called ECMAscript. All browsers support javascript/jscript. Only
IE natively supports vbscript, although I understand other browsers will
support it if add-ins are installed. Nevertheless, if you want your
client-side code to work in all browsers, use javascript.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Bob Barrows [MVP]]

brooksr wrote:

Thanks so much for that post, Bob, it's excellent. Probably going to
take some time for me to absorb it all.

Let me ask some follow up questions:

So VBScript and (plain) ASP are 'classic ASP', while VB.NET and
ASP.NET are 'modern' ASP?

Pretty much, yeah.

>
I understand that VB.NET is a part of Visual Studios and that a free
version, VB Express, is available for download and may meet many
developers' needs ...

So server side code resides on a web hosting site that I would use.
If you are not using FP, how do you get the code onto the server? Do
you still 'publish' it somehow?

I do intranet development, so I simply use Visual Interdev to work with my
pages on servers that have Frontpage Server Extensions installed, and simple
filesystem copy/paste for servers that don't. I have heard people saying
they use FTP to publish files to internet web servers. I haven't used VWD (I
use Visual Studio) but I think I heard that it has a publish-via-ftp
function builtin.

>
When you speak of client side, you basically mean a user accessing the
internet via a browser, like IE, correct?

Exactly. The browser is the client.

>
I read that many VB developers and even some book authors were angry
at how Msft changed VB in moving from VB6 to VB.NET, but it seems
like a moot point not worth wasting time on. Also, maybe drastic
changes were necessary to move to a full internet environment ...

No. MS responded to the demads for a more object-oriented VB for VB7, but
found that they could not deliver it without sacrificing backward
compatibility. That is why there was no VB7: it is practically a new
language. Code that worked fine in VB6 will break if attempted to be run
without modification i VB.Net. This is what so many developers are still
upset about: millions of lines of existing codebase, with millions of
dollars in both time and money, is in jeopardy. Sure, people can still use
VB6 to maintain that code, and, while MS has made a commitment to making
sure the VB runtimes will continue working in new operating systems, the
trust has been broken

>
So is ASP.NET a language?

No. Neither classic ASP nor ASP.Net is a language. They are both "platforms"
that support the use of multiple languages, providing interfaces and classes
(Server, Application, Session, Request and Response objects) that can be
used by these languages. Classic ASP supports the use of scripting languages
such as vbscript, jscript and perlscript. ASP.Net is provided by the .Net
framework and supports the use of any .Net language. You should go to
www.asp.net to read more.

Does it have a wysiwyg interface that can
replace FP's?

WMD has a wysiwyg interface, as does Visual Studio 2005 if you can afford
it.

>
I'm still a little unclear how VWD and VBE relate to one another? If
I learn VWD do I still need VBE? If I need both, which should I learn
first?

WMD provides wizards and functionality to make ASP.Net develpment easy. Any
..Net language can be used. I think VBE is an IDE for VB.Net develpment.
You'll need to ask the experts at www.asp.net.

>
What is dhtml and how does it differ from html?

html is static markup language.
dhtml = dynamic html. It is a library (actual many libraries) provided by
browsers to provides interfaces for working with html elements in
client-side scripting code. There is a standard DOM (document object model)
library published by the w3c body, but different browsers may or may not
adhere to this standard DOM. IE is notorious for its lack of adherence to
standards. IE7 is suppoed to be better, but they did not want too many
things that worked in IE6 to break in IE7. However, due to security
improvements, many appplications that worked in IE6 need to be rewritten to
work in IE7.
Here is a link to the MS DHTML reference:
http://msdn.microsoft.com/workshop/a...iews_entry.asp
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Mike Brind]

"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:uk******** *****@TK2MSFTNG P03.phx.gbl...

brooksr wrote:

ASP.Net is more interactive. It provides gui controls that can trigger
events in server-side code via postbacks. So the line between server-side
and client-side events is definitely blurred.

I'm not sure I agree with this. The "gui controls" are rendered as html
elements. VS provides an easy way to create code to be run for the client
side event that triggered the postback. I see no difference between this
and Classic ASP, except that you don't get any help wiring together a client
side event and server side code in Classic ASP. You can create ASP.Net
pages in Notepad, for example, and similarly do not get the same help that
VS provides. Server side code and client side events are as separate under
dotnet as they are for classic ASP, cold fusion, php, java server pages or
any other server-side web technology.

But, as you alluded to in another part of your post, ASP.Net has definitely
been designed to make Win App developers feel more at home. My brother is a
Delphi developer, and never ventured into web apps until the DotNet
framework permitted him to use Delphi.Net to create them. The IDE he uses
is so consistent with his Win App development experience that he found the
transition to web apps a trivial one. The OP should find the transition to
ASP.Net a lot easier than classic ASP.

--
Mike Brind

[Bob Barrows [MVP]]

Mike Brind wrote:

"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:uk******** *****@TK2MSFTNG P03.phx.gbl...

>brooksr wrote:

ASP.Net is more interactive. It provides gui controls that can
trigger events in server-side code via postbacks. So the line
between server-side and client-side events is definitely blurred.

I'm not sure I agree with this. The "gui controls" are rendered as
html elements. VS provides an easy way to create code to be run for
the client side event that triggered the postback. I see no
difference between this and Classic ASP, except that you don't get
any help wiring together a client side event and server side code in
Classic ASP.

That "wire-up" is what I was talking about as blurring the line. Of course,
I don't see "blurring" to be the same as "eliminatin g". In effect, we have
client-side objects initiating server-side event-handlers. Of course, this
is entirely due to the wiring-up, but, to me, this is definitely a blurring
of the line.

You can create ASP.Net pages in Notepad, for example,
and similarly do not get the same help that VS provides.

But the wiring up is still done ... it's now done by the coder instead of
the ide.

Server side
code and client side events are as separate under dotnet as they are
for classic ASP, cold fusion, php, java server pages or any other
server-side web technology.

True (and I did anticipate receiving a little flack about this)), but you
have to admit that the xmlhttp object started to make the line a little
"hazy" in classic asp. Ajax is continuing that trend in asp.net.

Of course, the line will never be truly eliminated: it is unlikely that
server-side code will ever have direct access to client-side DOM (objects,
properties and methods): these objects would have to be marshalled and
passed back to the server code and back - without some major compression and
decompression technology, this seems very unfeasible.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Mike Brind]

"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:ek******** ******@TK2MSFTN GP03.phx.gbl...

Mike Brind wrote:

>"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:uk******* ******@TK2MSFTN GP03.phx.gbl...

>>brooksr wrote:

ASP.Net is more interactive. It provides gui controls that can
trigger events in server-side code via postbacks. So the line
between server-side and client-side events is definitely blurred.

I'm not sure I agree with this. The "gui controls" are rendered as
html elements. VS provides an easy way to create code to be run for
the client side event that triggered the postback. I see no
difference between this and Classic ASP, except that you don't get
any help wiring together a client side event and server side code in
Classic ASP.

That "wire-up" is what I was talking about as blurring the line. Of
course, I don't see "blurring" to be the same as "eliminatin g". In effect,
we have client-side objects initiating server-side event-handlers. Of
course, this is entirely due to the wiring-up, but, to me, this is
definitely a blurring of the line.

I must be missing something - I still don't see any difference between
dotnet and other server-side frameworks in this respect. Whether the
client-side event is triggered by a button being clicked or eg a
jscript/javascript onBlur() or onChange() event being fired and submitting
an XmlHttpRequest GET or POST, code is still written server-side to identify
and respond appropriately to the event.

>

>You can create ASP.Net pages in Notepad, for example,
and similarly do not get the same help that VS provides.

But the wiring up is still done ... it's now done by the coder instead of
the ide.

<% If Request.Form("S ubmit") = "Submit"...%isn 't "wiring up" then?

>

> Server side
code and client side events are as separate under dotnet as they are
for classic ASP, cold fusion, php, java server pages or any other
server-side web technology.

True (and I did anticipate receiving a little flack about this)),

I would hate to disappoint :-)

but you

have to admit that the xmlhttp object started to make the line a little
"hazy" in classic asp. Ajax is continuing that trend in asp.net.

Hmmm.... Ajax threw me a little at first - purely because I was hazy about
the difference between the client-side stuff and the server-side. Then I
mentally separated the two, and all was a lot clearer.
--
Mike

[brooksr]

Bob,

What is WMD?

Brooks