Client side versus Server side

Ed Jay wrote:
> GreyWyvern scribed:
>>It all depends on to whom you wish to cater.
>>
>>Increasingly, new web tech depends on JS and simply assumes you have it
>>enabled. AJAX is JS, for example, and it's a big seller these days. So
>>if you are okay with excluding those who don't have JS enabled, then use
>>it, and feel free to use a lot of it. But realize that the only place you
>>have complete command over your data is on the server-side.
>>
>>There is an adage among MMORPG designers which is: "NEVER TRUST THE
>>CLIENT". In gaming terms, this means never trust the remote client to
>>perform game-critical calculations, because devious users can intervene
>>and manipulate these for their own gain. Keep it in mind when designing
>>your JS apps and you should be fine.
>>
>
> Thanks, Grey.
>
> My audience is limited to paying subscribers of a medical AI diagnostic
> service. Our clients will be using a browser supplied by us (Opera), with
> js enabled. They'll be prevented from disabling it as long as they are on
> the site.

Foldera (the company I work for) provides a web application that makes
very heavy use of JavaScript and popup windows. The base website that
people go to in order to learn about Foldera does not. But it is made
clear that in order to use the application, you have to have javascript
and cookies enabled, and permit popups for the site.

Ours is a broader case, but it works decently - especially as it tests
for all of these matters at login and alerts the user - along with
providing instructions as to how to fix the problem.

Will this cost us some users? Possibly. In fact, I am fairly certain
there are some who will, just on principle, not use Foldera. But we will
gain more users by providing a more robust user experience - and our
main site (as I said before) doesn't require anything but the simplest
browser to view.

Interestingly, we had planned on dealing with mobile access in the
future, but it seems that the application actually works with many
mobile devices already. I must have got something right in the basic
design, eh?

All that, ultimately, to say: I think you're probably fine given the
context of your application.
 >> Stay informed about: Client side versus Server side 

hug scribed:

>Ed Jay <edMbj.TakeThisOut@aes-intl.com> wrote:
>
>> Our clients will be using a browser supplied by us (Opera), with
>>js enabled. They'll be prevented from disabling it as long as they are on
>>the site.
>
>How do you prevent them from disabling it as long as they're on the
>site?

Opera allows one to employ js to control Opera's behavior. When on the
site, Opera's options are limited by the js installed in Opera's user
js-control folder.

I think that by the time we're finished, our clients won't even know
they're using a browser. Opera will be skinned and optioned so it looks
like they're using just another application.
--
Ed Jay (remove 'M' to respond by email)
 >> Stay informed about: Client side versus Server side 

"Ed Jay" <edMbj.RemoveThis@aes-intl.com> wrote in message
news:kij7421beqvc94v5b2732kcfqjpts9qnem@4ax.com...
> I've developed an application using Perl and Javascript. SS Perl is used
> to generate the basic HTML page and client-side js is employed to
> dynamically change the page.
>
> I've read many times over that one should not use client side js, but to
> use a SS script (Perl) instead.

Using javascript is fine... the important thing is not to rely solely upon
it so that users who have scripting disabled or whose browser can't work
with scripting can still see your content and use your site.
 >> Stay informed about: Client side versus Server side 

Toby Inkster scribed:

>GreyWyvern wrote:
>
>> There is an adage among MMORPG designers which is: "NEVER TRUST THE
>> CLIENT".
>
>At Uni I was always taught: always assume user input is malicious.

I recall building an interface and striving to anticipate and obviate
every error a user might make. When I finished, I bragged that I had made
a fool-proof interface. My associate laughed and said, "You might have
made it fool proof, but you didn't make it damned-fool proof."
--
Ed Jay (remove 'M' to respond by email)
 >> Stay informed about: Client side versus Server side 

hug scribed:

>Ed Jay <edMbj DeleteThis @aes-intl.com> wrote:
>
>>hug scribed:
>>
>>>Ed Jay <edMbj DeleteThis @aes-intl.com> wrote:
>>>
>>>> Our clients will be using a browser supplied by us (Opera), with
>>>>js enabled. They'll be prevented from disabling it as long as they are on
>>>>the site.
>>>
>>>How do you prevent them from disabling it as long as they're on the
>>>site?
>>
>>Opera allows one to employ js to control Opera's behavior. When on the
>>site, Opera's options are limited by the js installed in Opera's user
>>js-control folder.
>>
>>I think that by the time we're finished, our clients won't even know
>>they're using a browser. Opera will be skinned and optioned so it looks
>>like they're using just another application.
>
>Opera has always been good. I haven't kept up with later releases,
>one of these days maybe I'll upgrade again.
>
>I'm not sure how secure for the client the new Opera control
>functionality is, but chances are it's pretty decent.

Opera is the man! The only problem I have ever had with it is rejection
from some sites testing for IE only. Most that do can be accessed with
Opera's built-in spoofing. The best part for my application is its
customization features. The more I explore the possibilities of using it
as an application shell, the more impressed I become.

Thanks to everyone for your inputs.
--
Ed Jay (remove 'M' to respond by email)
 >> Stay informed about: Client side versus Server side