| This
article targets 'classical' developers wanting to start web development
Or those already there and still a little lost.
Going from WinDev to WebDev should be painless, and on most levels, it
is. One big problem remains: the development philosophy. This can sound
like a big name, but you'll see very fast that looking at things this
way can make you progress fast.
During a classical software development (with WinDev by example), the
developer has everything on hands: the code and the UI are merged and
everything is always accessible
As soon as you open the WebDev code editor, you can see that something
is amiss: browser code on one side, server code on the other, functions
that are available only in one or the other, code execution order
There are enough new things to wonder
And justifiably
WebDev tries to minimize the 'web' development difficulties and succeeds
on many levels (see my article on AWP mode)
But one fact remains:
without a different way of reasoning, your WebDev sites are going to drive
you crazy.
The BIG difference that you have to understand is that a web site is
NOT a piece of software
Even if some code is executed!
A web site is more like a collection of software talking together:
- a big one (it's the server side application)
- a lot of small ones (each html page, executed independently on the client
machine, in Javascript)
If you are able to see things that way, everything is going to be easier:
- all the browser code area of a page are in fact one small quasi independent
program
- the server code area of a page are part of the big server side program
In fact, compared to a traditional software, it's a little like if each
window was compiled in a separate executable, and that all the file access
code (and other) was in a big separate executable. Add communications
between them, et voila
Lets take an example: info("MyMessage") is a very basic instruction
But if you use it without thinking about it in server code, it's not going
to be executed
At least not immediately
It will be executed
only when the next page will be sent from the server to the client machine
where all displays are done!
So, when in WinDev an 'info' is blocking the program execution, it does
not in WebDev server code
Surprise! At least if you continue to
think in terms of standard software development.
On the contrary, if you think in terms of several programs working together,
this behavior becomes normal.
Let's take another example:
In a page, you want to display fields depending of the user actions. To
this point, everything is simple, we are in a case of browser code
But your conditions also depend of the content of some files
This
means that you have to send the user actions (checkboxes values by example)
to the server to verify some file values. We are now talking about server
code.
It's the mixing of both that is troublesome if you don't think about
it the right way
How many times do you see questions on a forum
about how to execute browser code from a server side code?
Here is how things should be done:
- the user clicks on checkboxes
- this information is sent to the server through a submit button or code
hidden in the checkboxes fields themselves
- the server side code goes through the files, compare with the field
values, and decides to make 3 new fields visible, to display a message
in one of them, to send new values to a java applet, etc.
- the server side code prepares everything by setting flags (global variables
by example), storing values to display, etc
- the server display the INITIAL page a second time
- in the page init code, the flags are checks and action are executed
based on them, making the fields visible, etc
Of course, this made the web page flash (you all know what I'm talking
about here)
And the answer to that disgraceful flash is
AJAX
But a little advise
If you still have trouble conceiving
a web site the way I just described, forget ajax for now.
Build your site using the standard way, understand WELL how everything
works, and we'll talk about ajax later
Complicated? Yes and no.. Again, the philosophy of the thing is 'two
programs talking via the web'
Imagine two computers linked via two
modems and you'll get a better understanding of what has to be done where
Let's take another example of the profound differences between a standard
software development and a web site
In standard software, you can
often see a min window opening secondary windows, each of them opening
tertiary windows, and so on
If these windows are modal, the user
can access only one at a time et will have to go back the way he came.
If they are not modal, most of the time the user will be lost and you'll
have to change your UI.
In a web site, you can open multiple browsers (or popup) too
But
there is no MODAL idea at all
this has two consequences:
- the user can act on ANY of the open windows, with the clear risks that
will have on your application
- if he has a choice, the user will go on ANOTHER website instead of yours,
one with a simpler UI
Users just HATE popups
So please think of your web site application like a software having only
ONE window open at a time
Everything necessary for your process
should therefore be in global variable (or classes variable of course)
and in the current window
Don't count on anything else and everything
will be better
|