Javascript(?) Spreadsheet

[Dave_Curry]

All,
I'm developing a web app that:
1)  Has a good bit of data, say 50 items, that the user can futz with.
2)  About 100 small calculations; and state is important.
3)  Sessions last longer than a minute, and 5-10 minutes wouldn't be unusual.
4)  Expecting 1000+ users.

Now, #'s 1 and 2 suggest I want to minimize server transactions.  #'s 3 and 4 tell me I don't want to suck up a lot of server resources.

A javascript (or other?) spreadsheet solution sounds like a reasonable possibility.  I'd like to know what others have done in similar situations, and, if a browser-based spreadsheet solution is the right answer, what products you've used and would recommend.

TIA,
Dave

[Rick-141]

Browser based solutions can be a pain because 1- All the browsers run
Javascript differently, 2- All browsers have different syntax for
Javascript, 3-Developing large apps with scripting languages is a
debugging nightmare, 4- You generally can't control which browser or
version of browser the users employ.

With 1,000 users the transaction rate shouldn't be that high, unless its
an app that all 1000 are using simultaneously.

50 data items is not that much unless some are images or something like
that.  50 text item at 20 characters each is less than 1K of data.

When you say 100 calculations, are those done all at one on a page
submit or does changing cell A affect the value in cell B?

If the latter is the case you can set up the page as a grid of text
boxes (or maybe pull down menus for items that have a fixed,  finite
number of values).

You can use Javascript to do simple, easy to debug calculations to put a
new value in cell "C" if "A" or "B" change.

That avoids the 2 second or so delay that you would get if you use JSF
to do that.  That can be a real pain if you are futzing with 50 boxes
that update after each change.

When you say state is important, what exactly do you mean?


Rick

Dave_Curry wrote:

> All,
> I'm developing a web app that:
> 1)  Has a good bit of data, say 50 items, that the user can futz with.
> 2)  About 100 small calculations; and state is important.
> 3)  Sessions last longer than a minute, and 5-10 minutes wouldn't be
> unusual.
> 4)  Expecting 1000+ users.
>
> Now, #'s 1 and 2 suggest I want to minimize server transactions.  #'s 3 and
> 4 tell me I don't want to suck up a lot of server resources.
>
> A javascript (or other?) spreadsheet solution sounds like a reasonable
> possibility.  I'd like to know what others have done in similar situations,
> and, if a browser-based spreadsheet solution is the right answer, what
> products you've used and would recommend.
>
> TIA,
> Dave
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Dave_Curry]

Rick,
Thanks for the info.  To answer your questions:
I'm expecting that as many as 1000 users could be using the web app/service at the same time.  That's my baseline requirement, anyway.

Most of the data is numeric, with a couple of text and an image.  

The numeric data is highly interdependent, but individual calcs are mostly quite simple.  Changing one value CAN invoke a cascade of most of the calcs, some several times.

By "state", I mean things like user-specific data, program mode, current data values.

Perhaps the above makes it more clear why I'm even considering client-side scripting, but I understand what you're saying about browser-based dependencies (even if I don't understand WHY that has to be the case!).

I've seen components like BlueShoe's javascript spreadsheet, but haven't used them.  I would think such would be less sensitive to the particular browser, since they should be well tested - one can hope.  

Would be nice to know what others' experience has been.

Dave


Browser based solutions can be a pain because 1- All the browsers run
Javascript differently, 2- All browsers have different syntax for
Javascript, 3-Developing large apps with scripting languages is a
debugging nightmare, 4- You generally can't control which browser or
version of browser the users employ.

With 1,000 users the transaction rate shouldn't be that high, unless its
an app that all 1000 are using simultaneously.

50 data items is not that much unless some are images or something like
that.  50 text item at 20 characters each is less than 1K of data.

When you say 100 calculations, are those done all at one on a page
submit or does changing cell A affect the value in cell B?

If the latter is the case you can set up the page as a grid of text
boxes (or maybe pull down menus for items that have a fixed,  finite
number of values).

You can use Javascript to do simple, easy to debug calculations to put a
new value in cell "C" if "A" or "B" change.

That avoids the 2 second or so delay that you would get if you use JSF
to do that.  That can be a real pain if you are futzing with 50 boxes
that update after each change.

When you say state is important, what exactly do you mean?


Rick

[Rick-141]

Hi Dave,

Yeah, the commercial Javascript grids or spreadsheets put a lot of work
into detecting the browser and acting accordingly.  You still have to
worry about new releases, but since you control the Javascript, you can
easily update it when the vendor comes out with a fix.

I used one of the Javascript grid kits in a project about 5 years ago,
but my experience is probably outdated now.  It worked well and looked
good, but the learning curve to do what I needed was a little steep.

They typically obfuscate their Javascript code, so making small
modifications to their code is a big headache.  Sometimes you ca pay
more and get the Javascript code in  un-obfuscated form.  That is
something to look for in whichever kit you choose.

For your project, you might just want to use that and a servlet to
implement your project.

Rick

Dave_Curry wrote:

> Rick,
> Thanks for the info.  To answer your questions:
> I'm expecting that as many as 1000 users could be using the web app/service
> at the same time.  That's my baseline requirement, anyway.
>
> Most of the data is numeric, with a couple of text and an image.  
>
> The numeric data is highly interdependent, but individual calcs are mostly
> quite simple.  Changing one value CAN invoke a cascade of most of the calcs,
> some several times.
>
> By "state", I mean things like user-specific data, program mode, current
> data values.
>
> Perhaps the above makes it more clear why I'm even considering client-side
> scripting, but I understand what you're saying about browser-based
> dependencies (even if I don't understand WHY that has to be the case!).
>
> I've seen components like BlueShoe's javascript spreadsheet, but haven't
> used them.  I would think such would be less sensitive to the particular
> browser, since they should be well tested - one can hope.  
>
> Would be nice to know what others' experience has been.
>
> Dave
>
>
> Browser based solutions can be a pain because 1- All the browsers run
> Javascript differently, 2- All browsers have different syntax for
> Javascript, 3-Developing large apps with scripting languages is a
> debugging nightmare, 4- You generally can't control which browser or
> version of browser the users employ.
>
> With 1,000 users the transaction rate shouldn't be that high, unless its
> an app that all 1000 are using simultaneously.
>
> 50 data items is not that much unless some are images or something like
> that.  50 text item at 20 characters each is less than 1K of data.
>
> When you say 100 calculations, are those done all at one on a page
> submit or does changing cell A affect the value in cell B?
>
> If the latter is the case you can set up the page as a grid of text
> boxes (or maybe pull down menus for items that have a fixed,  finite
> number of values).
>
> You can use Javascript to do simple, easy to debug calculations to put a
> new value in cell "C" if "A" or "B" change.
>
> That avoids the 2 second or so delay that you would get if you use JSF
> to do that.  That can be a real pain if you are futzing with 50 boxes
> that update after each change.
>
> When you say state is important, what exactly do you mean?
>
>
> Rick
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...