Well, reducing it to it's simpliest form:
<cffunction name="generateSomeContentBlock" access="public" output="No"
returntype="string">
<cfargument name="findContentBlock" required="Yes" type="query"
/>
<cfargument name="pos" required="Yes" type="numeric" />
<cfargument name="pageState" required="Yes" type="struct" />
pageState is a struct so it's flexible - any keys can be added in or set,
and can collect information from the url and various application parameters
that reflect one state or another. that was the original idea anyway.
pageState is also passed into the findContentBlock method in the gateway.
Each content chunk also has a block of control code, and page state is
passed into that as well.
As things developed, i needed more state information via another gateway, so
i wound up passing that gateway into the display objects. The id of the
content block is passed into the gateway and out pops the state information
needed.
If i were a little smarter, and maybe one day i will be ;), i'd probably
encapsulate all the state stuff into one object and pass that into the
display object. At this point, i think that would be the best way to go.
In regards to caching, i create a display function for each unique content
block, and again the display objects are cached in application scope, along
with any gateways or helper objects needed to determine what gets displayed
when. The output in the display function is captured using cfsavecontent,
stripped of white space as appropriate to the content block, and returned.
<cfsavecontent variable="renderedContent">
content block code and micro logic stuff here depending on pageState,
findContentBlock, etc ...
</cfsavecontent>
<cfset renderedContent = REReplace(renderedContent, "[[:space:]]{2,}", "",
"ALL") />
<cfreturn renderedContent />
The point is that every bit that goes into creating the final layout is
cached. It's read off disk once and is assembled from memory on the fly for
each view. Not the conventional approach, as i understand it, but the
fastest and most flexible one i could come up with.
Now i'd better get back to "work". Thanks for asking tho'. Revisiting this
aspect of the code base gave me some ideas how it could be improved!
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Barry Beattie
> Sent: Tuesday, September 13, 2005 9:28 AM
> To: [email protected]
> Subject: Re: [CFCDev] bring business "micro-logic" to the view
>
>
> thanx Nando
>
> The caching is fine while the data is static and clean and when we're
> closer to finished we'll cache as much gateway data as possible (about
> 40% of the page)
>
> but I'm curious: how do your CFC generated UI controls handle
> micro-logic based on *context*?
>
> *context* for us is that a page (the main CFM that has the pagelets
> which contain the UI controls) can have many "states" or modes:
> "DELETE, ADD, VIEW, EDIT, SEARCH". The user security is tightly bound
> to these modes and there are subtle but important differences between,
> say, displaying data for VIEW vs display for DELETE.
>
> an example from something I was working on earlier: that only in EDIT
> and only when a particular entity variable has a certain value does
> one control become "disabled" and another become "required". Mostly
> this is in the same pagelet continer, but not always...
>
> any suggestions?
>
> thanx
> barry.b
>
>
>
>
>
>
>
> On 9/13/05, Nando <[EMAIL PROTECTED]> wrote:
> > Hmmmm,
> >
> > Not sure if this helps, but i'm generating my pagelets or
> content containers
> > using CFC's at least a similar reason, to have fine grained
> control over the
> > output, in various states. I've got up to 20 queries generating a view,
> > haven't hit 30 yet, but with cached gateways, indexes on the
> DB, and a few
> > DisplayManagers with helpers to handle all the variations the content
> > chunks, all of it cached in application scope, it seems to do very well
> > performance-wise. Surprisingly so, since i barely know what i'm
> doing in the
> > OO design department!
> >
> > Probably the important bit is that all the possible content chunks are
> > cached in memory.
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Behalf Of Barry Beattie
> > > Sent: Tuesday, September 13, 2005 8:48 AM
> > > To: [email protected]
> > > Subject: [CFCDev] bring business "micro-logic" to the view
> > >
> > >
> > > 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]
> > >
> > >
> >
> >
> >
> >
> >
> > ----------------------------------------------------------
> > 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]
>
>
----------------------------------------------------------
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]
