Lee Borkman wrote:
> Of course, we were using this idea long before FB3, with Steve's
> CF_BodyContent tag.
Yep, and I still have that sort of thing going on as well. One of my
objectives with the community app is to max out the performance for
smaller communities that are forced to rely on Access... so I've got a
much-modified CF_BODYCONTENT that works like a smarter version of
CFCACHE, stuffing chunks of HTML into WDDX packets and writing them to a
cache directory.
The basic process looks something like this:
- a "generic" dsp_ creates a struct full of data
- a fuseaction-level tmp_ pours that data into an HTML "mold"
- a skin-level tmp_ wraps that output and/or caches the result
- an app-level tmp_ then wraps and perhaps caches *that* output... I
have a CF_BODYCONTENTPARAM tag that toggles caching off depending on the
fuseaction, the user's settings, and security status
> But it sounds like you are going a step further, in that you are
> explicitly populating a some kind of content structure in your
> fuseactions, as opposed to a single variable, and then you are invoking
> some display template to re-purpose the content for the desired
> skin/medium, etc.
That pretty much sums it up. My dsp_ files sift through queries and user
info to generate (in theory) every piece of data a "skin circuit" could
want from that dsp_. The skin is then free to pick and choose which bits
of data it needs.
There will be a bunch of skins available when I'm done... linear,
threaded, a hybrid of the two, weblog, and even an Everything2/Wiki
skin. All of those obviously have substantially different needs when it
comes to presenting data, but they will all get that data from a single,
small set of dsp_ files.
> In recent weeks, we have had a few discussion on the "role" of "the
> fuseaction", my view being that is creates content and metadata only.
I agree to a large extent... in my own FBMe kinda way. :)
I view dsp_, act_, and qry_ files as components or functions of a
sort... they generate and return various forms of structured data. The
fuseaction can return that structured data to its caller, along with an
HTML-formatted, display-ready version when needed.
(Given what Allaire has stated publicly about Neo, this whole process
should only get easier.)
So while I don't want to restrict fuseactions to *only* returning
content and metadata, I think that should certainly be one of their
primary jobs.
> Is there any chance we could see an example?
Lemme see if I can piece together some pseudo-code here...
index.cfm (for skin #1 and #2)
=============================================
<cfcase value="dothing">
<cfset fusebox.xfa.viewnextmsg = "dootherthing">
<cfinclude template="#fusebox.app.dsp#dsp_dothing.cfm">
<cfinclude template="tmp_dothing.cfm">
</cfcase>
dsp_dothing.cfm
===============
<!--- BASIC VARS --->
<cfset bodycontent.fromid = fusebox.qryMessage.fromid>
<cfset bodycontent.groupid = fusebox.qryMessage.groupid>
<cfset bodycontent.urlnext = fusebox.app.rootpage & "fa=" &
fusebox.xfa.viewnextmsg & "msg=" & fusebox.qryMessage.id>
<!--- PREFAB BUTTON IN CASE A TMP_ WANTS IT --->
<cfsavecontent variable="bodycontent.buttonnext">
<cfoutput>
<cfif nextMessageExists>
<input type="button" name="next" value="Next >"
onclick="goThere('#bodycontent.urlnext#');">
</cfif>
</cfoutput>
</cfsavecontent>
tmp_dothing.cfm (skin #1)
=========================
<cfoutput>
<b>group</b>: #request.bodycontent.groupid#<br>
<b>from</b>: #request.bodycontent.fromid#<br>
<form>#request.bodycontent.buttonNext#</form>
</cfoutput>
tmp_dothing.cfm (skin #2)
=========================
<cfoutput>
<b>Who cares about group ids?</b><br>
<b>posted by this guy:</b> #request.bodycontent.fromid#<br>
<a href="#request.bodycontent.urlnext#">
Next Message
</a>
</cfoutput>
> This is using your variation on FB-Classic, is that right?
Yep... the app and the methodology behind it pre-dates the existence of
FB3. In fact, there have been so many iterations now that I think the
thing may actually pre-date the existence of me. :)
> I wonder, though, if you might not find that you can now achieve your
> aims within FB3...
I don't think that would work. The only thing FB3 could bring to the mix
is standardization... and stuff that I insist upon, like my "sacred"
attributes scope, my "fusebox" inter-fuse communication scope, and so on
would render my work quirky at best, and completely non-compliant at
worst. My personal FB3 objections aside, it just wouldn't make technical
sense for me.
--
Roger
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
