> Bill, can I ask:
>
> - where abouts in your app/framework would you put the CF code for
> the AJAX remote calls?... in a dedicated CFM (per module) as part of
> the view -OR - have the hooks there to call deep into the model?
> - if you had, say 20+ remote calls to deal with _per_page_ or "view",
> would it start getting out of hand?
For the application that I am doing this with (which was initially
developed in CF 4.7) I have an "xml" directory that is defined as the
request.dataisland.root (and is also defined as a global javascript
variable)
All of my remote CF stuff that deals with all these rules, etc are in
that directory. As are the javascript files that contain the handling
information.
I do have some subdirectories. For instance in the xml directory for
the main form I was talking about earlier (there are actually three of
them; sort of sibling forms - the 400a, 400b, and 400i) I have a 400
subdirectory and then a directory under that for each version for past
and current years (the years and their subsequent version numbers are
defined in the database) so under 400 I have directories like 1, 2, 3,
etc..
In these 1 directories I have a 400a.js.cfm (which is the javascript
that populates the form controls, turns them on, set them as client
side required, updates the appropriate hidden field to show that it
needs to be validated on the server side etc) there is also a
400a.xml.cfm which is the file that really does all the work. It
interacts with any customtags, (and now, just this year, some
components), and finally generates the XML structure that the
Javascript uses to flip the switches.
The whole application probably has about 50 forms that are controlled
via similar process but most are a bit simpler than those 400x forms.
So the rest of the forms javascript and xml files are in the root
request.dataisland.root directory (dataisland is a reference to AJAX's
name in 2000).
This year (fairly recently) I replaced ALL of the sites xmlHttpRequest
calls using the SACK ajax class. It is very, very simple. I have it
slightly modified to use my global dataisland root path as the basis
for any calls. This way the javascript that uses the SACK ajax object
doesn't have to know the xml file is actually in the same directory it
just has to know where it is in reference to the dataisland root.
Since, previously, every file was in the root (until I had to start
dealing with changing 400x rules) this always worked nicely since the
javascript just had to say look for the file named
"sameFromName.xml.cfm" and it would send back the appropriate xml.
While the overall setup isn't that great it works pretty well (and has
managed to work as we have convinced the client, albiet slowly, to
upgrade CF version so that they are FINALLY at 6.1 (this year, woo
woo).
So the site structure is kind of like...
site_root/
site_root/xml/ --- this is our dataisland root
site-root/xml/400/n --- where n is a positive integer from 1-y (currently 3)
site-root/xml/400/n/400a.js.cfm
site_root/xml/400/n/400a.xml.cfm
the site does not use any kind of MVC arcitecture at all.. it's sort
of like a fusebox 1 setup that I came up with before I had heard of
fusebox
it was also my very first Coldfusion project (i had just graduated
with my CS degree and came from an Ada, Java, and C++ background) so
while it works pretty well there are tons of things that could be
improved (of course, even when I do something well I think that)
Anyway, I don't know if that helps you at all. I'm kind of rambling sorry.
If I can send you any files to illustrate anything just let me know
and I'll do what I can.
Bill
> - are the AJAX calls all async? (a side issue to be sure but we've
> got so many AJAX calls per page that running async for all is a bit
> tricky....)
>
> Perhaps what's really missing is a UI-based controller (in JS
> perhaps?) that runs the business logic _for_that_page_?
>
> my point is that model-glue, Mach-II, etc have listeners to route
> requests to the model so maybe there's need for a "client-side"
> controller that listens to the UI and the "server-side" controller
> subscribes to that? it sounds like adding another "layer"
>
> I can't help thinking that either the controller/model-glue is too
> server side to help -OR- another similar "thing" is needed more up in
> the view, perhaps as a JS class?
> - any thoughts on that?
>
>
> thanx for your help
> barry.b
>
> On 9/13/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote:
> > 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]
> >
> >
> >
>
>
> ----------------------------------------------------------
> 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]
