[Javascript] server-side:client-side workload ratio

[David Lovering]

In response to your closing comments, yes -- I do many of the sort of
"data-massaging" things you cite (front-end validation, formatting, field
splitting, etc.) in the client-side Javascript modules.  However, I also
have a server-side routine at the top of each block of code (XML or
whatever) which explicitly checks to ensure that Javascript is enabled.  If
it isn't, it pukes out a nastygram and shuts the page build down at the
start.

Unfortunately, this does not address the more cunning situation where the
build is commenced (presumably with Javascript turned on), only to have the
user turn it off after the page build is completed.  This is why I also have
a "back-end" check for Javascript built in to the server-side routines, so
that I have somewhat greater confidence that the first-stage validation has
been completed.

To clarify your final point -- the client-side scripts I use are
predominantly "process-handlers" that prepare data for issuance from the
client to the server, whereas the server-side scripts are of two kinds:
post-processing the validation of the fields being submitted by the client,
or else preparing new page content and performing computational tasks with
data to which the client is not privy.  This approach has several
advantages, notably (a) it greatly diminishes CPU load on the server, and
(b) it allows rapid-response to changing user inputs on the client-side as
the Javascript works nearly instantaneously.

I was once a devoted Java fan for doing this sort of thing, but the
variation in the different Java engines and the huge latency/load delays at
the start eventually turned down my enthusiasm a notch.  [I still use Java,
but only for things that only Java can do].

Hope that explains my approach a bit better.

-- Dave Lovering

----- Original Message ----- 
From: "Paul Novitski" <paul at dandemutande.org>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Sunday, March 21, 2004 8:07 PM
Subject: Re: [Javascript] server-side:client-side workload ratio


> Dave,
>
> Good points.  When I duplicate input validation on the client side, it's
> mainly for the user's benefit -- so they don't have to wait for a form
> submit & return just to find out they made a typo or left a field
> blank.  Fundamentally it's the server-side script's responsibility to
> validate all incoming data.
>
> In my original posting I focused on page download, not form response, but
> what you say fits in with the general direction I seem to be heading -- 
> dividing an application into two faces, with the server-side script
> handling interaction with databases, web services, and other connectable
> resources, and the client-side script handling interaction with the human
> user.  On the surface that may seem like an inane tautology, but with
> client-side scripts that can see and manipulate the DOM, just where to
> separate various aspects of page rendering is what I'm wrestling with in
> trying to devise my programming policies.
>
> Wanting to accommodate browsers that have disabled client-side scripting
is
> a pretty good reason to amend my prior example -- not to download mere
data
> arrays for the client-side script to format into a table, but instead to
> download the data in an HTML table that works in some rudimentary way even
> in the absence of Javascript.
>
> You said:
> >My litmus test is that any or all information which may still yet be
edited
> >by the user PRIOR to submission is handled by client-side scripting, and
> >anything else is handled by server-side scripting -- including final
> >validation for fields.
>
> This feels like too sweeping a statement for me.  I often process data
> before downloading it to the client, things such as pre-validating fields,
> reformatting them, splitting a date/time field into two separate fields,
> maybe supplying listbox options for certain fields, perhaps concatenating
> first & last name, that sort of thing.  To me it feels like the
> server-script's responsibility to deliver data to the client that's ready
> to view or edit, and the client's responsibility to handle fine details of
> display style and user interaction, including primary validation.  Do you
> ever download raw data and do all your reformatting it in Javascript
before
> presenting it to the user in display or input fields?  Or only in certain
> cases?  I'm curious.
>
> Cheers,
> Paul
>
>
> At 04:40 PM 3/21/2004, you wrote:
> >Typically, those scripts which access things resident on the server (like
> >database information, files in shared distribution libraries, etc.) are
done
> >with server-side scripting -- even when (by some highly questionable and
> >tortuous methods) client-side Javascript could be finagled into doing the
> >same thing.  Remember -- anything on a client machine must and should be
> >regarded as suspect, tampered with, eavesdropped upon, and generally
nasty.
> >Piping it directly into the server application without vetting it first
is
> >not a recommended process.
> >
> >Also, it is important to split the validation process so that everything
> >which MUST be validated on a form submission is done on the server-side.
> >This is done in the instance that the client has disabled Javascript on
the
> >browser, either accidently or deliberately.
> >
> >My litmus test is that any or all information which may still yet be
edited
> >by the user PRIOR to submission is handled by client-side scripting, and
> >anything else is handled by server-side scripting -- including final
> >validation for fields.
> >
> >At least that's my take on the subject.
> >
> >-- Dave Lovering
> >
> >----- Original Message -----
> >From: "Innerlab" <innerlab at hotmail.com>
> >To: "[JavaScript List]" <javascript at LaTech.edu>
> >Sent: Sunday, March 21, 2004 1:31 PM
> >Subject: Re: [Javascript] server-side:client-side workload ratio
> >
> >
> > > Interesting thread. I look forward to read more.
> > > I am not an expert, so I don't think I can contribute much.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Paul Novitski" <paul at dandemutande.org>
> > > To: "[JavaScript List]" <javascript at LaTech.edu>
> > > Sent: Sunday, March 21, 2004 1:51 PM
> > > Subject: [Javascript] server-side:client-side workload ratio
> > >
> > >
> > > > Friends,
> > > >
> > > > As my client-side scripts become capable of performing more complex
> >tasks,
> > > > I'm left wondering how I should split the workload between my
> >server-side
> > > > scripts and my client-side scripts.  What fundamental
characteristics of
> > > > the page-rendering process naturally argue for placement above or
> > > > below?  If you've given this some thought and have come up with some
> > > > conclusions that work for you, please share them.
> > > >
> > > > (For this musing I'm considering "hand-crafted" scripts such as
> >VBscript,
> > > > PHP, and Javascript, bypassing the .Net programming environment that
can
> > > > handle most of the server/client side issues as one integrated
process.)
> > > >
> > > > My initial inclination is to give server-side scripts most of the
> > > > application-specific work and give client-side scripts more generic
> >tasks
> > > > that I can re-use more often, although I don't have a rigorous
argument
> > > for
> > > > that yet.
> > > >
> > > > One area that seems clear concerns download time.  Especially in a
era
> > > when
> > > > so many users are on slow connections, it would behoove us to
minimize
> >the
> > > > size of downloaded pages without sacrificing the complexity of the
user
> > > > interface.
> > > >
> > > > Consider an application that reads a dataset and downloads it to the
> > > > browser for display or editing.  The data need to be massaged before
> > > > presentation in the browser: some fields made into hyperlinks,
others
> > > > reformatted, concatenated, or converted for user friendliness.
> > > >
> > > > Because it's the server-side script's responsibility to read the
dataset
> > > in
> > > > the first place, I'm inclined to give it the job of initial
> >reformatting:
> > > > - selected the desired columns;
> > > > - performing the initial record sort;
> > > > - performing data conversions (enforcing date & time formats,
replacing
> > > > code values with human language words, concatenating fields, etc.);
> > > >
> > > > ... and give the client-side script the work that pertains to the
> >details
> > > > of the user interface:
> > > > - assigning CSS classes & styles;
> > > > - assigning GUI events & hyperlinks;
> > > > - inserting the data grid in the page and organizing its structure,
e.g.
> > > > separating the field name row from the data rows to enable a
scrolling
> > > > dataset with fixed heads.
> > > >
> > > > For fast response time, I'm inclined to keep the size of the
downloaded
> > > > page small and add any necessary redundant bulk with the client-side
> > > > script.  For instance, the server-side script could dictate the CSS
> > > classes
> > > > of each data column in a single row, and the client-side script
could
> > > > assign these to every data row in body onLoad(), resulting in a slim
> > > > download and a fat result.
> > > >
> > > > The server-side script could generate Javascript such as:
> > > >
> > > > var aFieldNames = new Array("Date","Contact","Email");
> > > > var aRowClasses = new
Array("cssFldDate","cssFldContact","cssFldEmail");
> > > > var aRowLinkTypes = new Array("","","mailto");
> > > > var aDataset = new Array();
> > > > aDataset[0] = new Array("03/01/2004","Jo Blo","joblo at thingie.com");
> > > > aDataset[1] = new Array("03/04/2004","Sam
Sham","samsham at froggie.org");
> > > > ...
> > > >
> > > > Javascript could build the actual data grid structure (using table
or
> > > > layers) and assign classes, link structures, and mouse events to
each
> >cell
> > > > of the dataset as it builds them, ultimately generating a structure
much
> > > > wordier than the essential information that's been downloaded.
> > > >
> > > > Any further thoughts anyone has on this topic would be appreciated.
> > > >
> > > > Paul
> > > >
> > > >
> > > > _______________________________________________
> > > > Javascript mailing list
> > > > Javascript at LaTech.edu
> > > > https://lists.LaTech.edu/mailman/listinfo/javascript
> > > >
> > > _______________________________________________
> > > Javascript mailing list
> > > Javascript at LaTech.edu
> > > https://lists.LaTech.edu/mailman/listinfo/javascript
> > >
> > >
> >
> >
> >_______________________________________________
> >Javascript mailing list
> >Javascript at LaTech.edu
> >https://lists.LaTech.edu/mailman/listinfo/javascript
>
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>