[cgiapp] RE: Many HTML <select>'s ... one Data Source

["Kinyon, Rob" <suppressed>]

I have the exact same situation in one of my apps that I've happily
converted to C::A/mod_perl. The trick is to try and cache the possible
options before mod_perl forks. The idea is to avoid as much calculation
as you can per request.

For example, I have a series of drop-downs that both depend each other
as well as on what kind of user you are. Each user has a bunch of
access_levels assigned to them. However, there are a (relatively) small
number of different access_levels, all related to one another. (If you
have A, then you also have B and C, etc.) So, I pre-calculate the
roughly 6k access_levels and all their parent-child relationships, and
it takes about 45-75 seconds at startup. This saves up to 20 seconds per
page hit in the affected area of the app. The only calculation is how to
populate each drop-down based on the prior ones, but that's less than
1/10th of a second. All I'm doing is walking the access_level tree a few
times. If I wanted to drop that, I could optimize it further cause it's
all in one place.

You're right - you have to submit every time because the only thing that
makes decisions is the server. However, have you looked at OpenThought
(www.openthought.net)? That reduces the load back to the server,
speeding up the app. (And it has a bunch of other features.) We're
looking at using it in maybe 6-9 months. There's no discussion as to how
it would work with C::A, but I can't imagine the interface would be very
difficult at all.

Rob

> -----Original Message-----
> From: Bill McCormick [mailto:suppressed
> Sent: Tuesday, February 17, 2004 8:26 PM
> To: Cgiapp
> Subject: OT: Many HTML <select>'s ... one Data Source
> 
> Hi all,
> 
> <flame shields up>
> This is somewhat OT but, since I'm hoping for a solution that involves
> C::A
> and/or some companion template mod, there may be hope.
> 
> <background>
> Some time ago (1/2 year?) I started flirting with the DOM and
JavaScript
> for
> a solution to present a C::A generated form with many HTML <select>'s.
> Since
> these <select>'s have the same (possible large number of) <option>'s
> (pulled
> from MySQL), having to send the actual (B-U-L-K-Y) HTML for each
<select>
> -
> which is the same anyway - seems like a terrible waste. My JS design
> involved the ability to programmatically "link" <select>'s together
and
> change the options of one based on the selection of another - without
> having
> to submit the form. Not having to submit after each user <select>ion
is,
> of
> course, key and I think not possible with just Perl/Apache/MySQL ...
or is
> it? Anyway, I devised (and revised) a JS solution. I fought with it
for
> days
> maybe weeks, finally made it work (mostly), ran into some dang issue
that
> I
> can't even begin to remember now, then had to put it away for some
time to
> work on something else.
> </background>
> 
> Now this swirls in my head like a bad dream and I long for some other
> (necessarily elegant) solution that involves little or no JS; please
just
> good ole Perl, Apache, HTML, or even XML and still able to work nicely
> with
> C::A. So before I dive into this again, I humbly request (from the
great
> C::A list) some ideas that others have had success and happiness
> integrating
> into their C::A framework.
> </flame shields up>
> 
> Thanks,
> 
> 
> Bill
> 
> 
> BULKY:
> Butt Ugly List Killing You
> 
> (I swear I just made that up)


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed