barry - boy do I feel your pain!
I have been using an "ajax" like approach to a very similar problem
since about 2001. I was able to refine it a bit this year (thanks to
other browsers finally supporting xmlhttpRequest) but in general, it
is still a somewhat clunky process.
However, I was able to move all business logic to the server and only
presentation logic exists in the javascript now.
On the form I'm thinking of in particular we have about 30 controls.
At least 15 of them have some effect on one or more other controls on
the page (either changing select list contents, enabling/disabling
other fields, un/requiring fields etc...)
The javascript has to deal with some flags that are passed back in the
XML but it's all contained in one helper JS file that is specific to
that page.
I use a customtag to capture all of my javascript calls for the
particular page, put them in the request scope, then am able to put
all of the javascript up in the <head> part of the layout template.
Of course, each year the rules change :O) and I have to support every
past year, so I just create a new version of my "rule" JS file and I
dynamically include the right one based on the year of data they want
to see.
I doubt if this helps you much - but at least you are not alone!
Bill
On 9/13/05, Barry Beattie <[EMAIL PROTECTED]> wrote:
> hi all
>
> we've been getting great traction using UI controls (custom tags) and
> "pagelets" in abstracting the HTML generated in the views.
>
> BUT...the problem we're facing now is providing specific "flags"
> (simple boolean values returned with the entity data) that turn on/off
> validation or required or even show/hide. These flags are the result
> of lots of "micro-logic" run off specific data returned and is the
> result of having both model-level business logic and UI business
> logic.
>
> it's so incidious that it comes down to, say one field/control on a
> page or perhaps another's value affecting another: ("if this value =
> 'E' then that control is required")
>
> if this was flash and cairngorm, I'd guess we'd need a "view helper".
> We're filling up the main pages and pagelets with these flags with
> more to come.
>
> there are two "levels" this occurs in: server-side (CFMX) with page
> render and totally client side (JS) and sometimes it's setting CF
> values directly inside JS for the client-side logic. Unfortunatly,
> with up to 30 queries just for the page to render (worst case) doing
> it all server-side (like ASP.NET) is not on. In desperation we call in
> AJAX remote calls to help out.
>
> do anyone else have similar experiances? any suggestions to stop being
> burried under more and more "flags"?
>
> thanx
> barry.b
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> (www.cfxhosting.com).
>
> CFCDev is supported by New Atlanta, makers of BlueDragon
> http://www.newatlanta.com/products/bluedragon/index.cfm
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
