-- Topica Digest --
RE: Dynamically build a variable name
By [EMAIL PROTECTED]
RE: Content Management schema
By [EMAIL PROTECTED]
RE: Dynamically build a variable name
By [EMAIL PROTECTED]
Re: Content Management schema
By [EMAIL PROTECTED]
RE: Dynamically build a variable name
By [EMAIL PROTECTED]
OT -- New Fusebox Mascot
By [EMAIL PROTECTED]
URL fuses
By [EMAIL PROTECTED]
Re: Fusedoc advice please!
By [EMAIL PROTECTED]
Re: Fusedoc advice please!
By [EMAIL PROTECTED]
RE: Content Management schema
By [EMAIL PROTECTED]
RE: URL fuses
By [EMAIL PROTECTED]
Re: OT -- New Fusebox Mascot
By [EMAIL PROTECTED]
RE: URL fuses
By [EMAIL PROTECTED]
Re: URL fuses
By [EMAIL PROTECTED]
Re: Content Management schema
By [EMAIL PROTECTED]
RE: Content Management schema
By [EMAIL PROTECTED]
Re: Content Management schema
By [EMAIL PROTECTED]
RE: Content Management schema
By [EMAIL PROTECTED]
------------------------------------------------------------
Date: Fri, 28 Jun 2002 00:05:38 +0000
From: Nando <[EMAIL PROTECTED]>
Subject: RE: Dynamically build a variable name
Thanks guys ... i got it working.
Erki Esken wrote:
> <cfset "foo#bar#" = value>
>
> or
>
> <cfset SetVariable("foo" & bar, value)>
>
> The first one is usually faster.
>
> .erki
>
>
>
------------------------------
Date: Fri, 28 Jun 2002 00:11:05 +0000
From: Nando <[EMAIL PROTECTED]>
Subject: RE: Content Management schema
Just for the record, this is what worked to set the variables. Hadn't
done this before, so my syntax was wanked.
<cfoutput query="getTexts">
<cfset temp = SetVariable('strTextBlock#getTexts.CurrentRow#',
#getTexts.strTextBlock#)>
<cfset temp = SetVariable('idText#getTexts.CurrentRow#',
#getTexts.idText#)>
</cfoutput>
As a start, it seems to work ok.
Nando wrote:
> I was wondering if anyone who has worked with this could comment on how
> they approached a database schema problem for an FB3 content management
> app. Maybe i'm missing the obvious here ... Here is the situation.
>
> First, a page request is always to a specific circuit.action, so it
> makes sense to me that each editable page element is related to a single
>
> circuit.action record. so i started with a simple table called
>
> tblCircuitAction
> fields
> * idCircuitAction
> * strCircuitAction
>
> Then the query to obtain the data for a particular page request is a
> join with the fully formed fuseaction at it's heart.
>
> Then there can be different types of editable content on each possible
> page view. To keep it simple, lets say we have just text and images.
>
> tblTexts
> fields
> * idText
> * idCircuitAction
> * strTextBlock
> * bitPublish
>
> tblImages
> fields
> * idImage
> * idCircuitAction
> * strImageName
> * bitPublish
>
> Now, as long as there is a one to one relationship between
> tblCircuitAction and tblTexts / tblImages, it's a no brainer. the cfcase
>
> includes a join query and a display file, and somewhere in the display
> file there is a single #strTextBlock# and a single #strImageName#
> (inside in image tag, of course). But of course, this is not what is
> really needed.
>
> Obviously, we need to accomodate more than one editable image or text
> block per page, indicating that the relationship between
> tblCircuitAction and tblTexts or tblImages is actually one to many. Now
> we're in a bit of a jam.
>
> Let's say i have 2 text blocks on a particular page. I run my query, it
> returns 2 records from the text table. Now what? In the display file,
> these 2 blocks of text mostly likely need to have uniquely defined
> positions, (we cannot count on outputting them with a loop, for
> instance) which suggests that they each need to be defined with uniquely
>
> named variables. Let's say our site administrator decides they want to
> add 20 text blocks to a particular page and our system allows that.
> Normalization here makes complete sense. But how to deal with the fact
> that normalization will not return the unique variable names we need to
> lay the page out as we might want. Seems like we need to assign variable
>
> names to the textBlocks on the fly.
>
> I have an idea how to accomplish this by placing something like this at
> the top of each display page:
>
> <cfloop index="i" from="1" to="#getTexts.RecordCount#">
> <cfset strTextBlock = 'strTextBlock#i#'>
> <cfset idText = 'idText#i#'>
> </cfloop>
>
> If i was smarter than i am, maybe something similar could be written
> into the query (or SP)
>
> Then i would have unique variable names assigned to each text block and
> it's id (so the admin of the site can click on an icon and edit it.) The
>
> only problem with assigning the variable names on the fly like this is
> that the locations on the page would then be interdependent with the way
>
> it was sorted. So i think the query would need to sort the records by id
>
> so you always get a consistently ordered result.
>
> My hack until today has been to create extra fields for the number of
> anticipated text blocks, strTextBlock1, strTextBlock2, etc - but what i
> don't like about this solution is that it gets messy for the person
> editing the site. it kind of forces me to present the admin user with
> more than one text entry box on their editing form. They click on the
> icon for textBlock1 and they see all the textBlock forms for that page.
> It's confusing. And of course, it's not very scalable.
>
> Does anyone have any comment here on how they would resolve this issue?
> I've been rolling this scenario around in my mind for quite some time.
>
> Nando
>
> * by the way, sorry for posting this to the fusebox list, but the
> community list seems to have been nuked.
>
>
>
------------------------------
Date: Thu, 27 Jun 2002 21:42:55 -0400
From: [EMAIL PROTECTED]
Subject: RE: Dynamically build a variable name
This is where I would opt for an array. Those Evaluate() functions are slow.
So I'd do this:
<cfset aryTextBlock = ArrayNew()>
<cfset aryIDText = ArrayNew()>
<cfloop index="i" from="1" to="#pages.RecordCount#">
<cfset aryTextBlock[i] = strTextBlock>
<cfset aryIDText[i] = idText>
</cfloop>
Then to output them:
<cfoutput>
<cfloop index="i" from="1" to="#pages.RecordCount#">
#aryTextBlock[i]#<br>
#aryIDText[i]#
</cfloop>
</cfoutput>
- Jeff
On 27 Jun 2002 at 17:38, Shannon Hicks wrote:
> And, on the flip side, if you wanted to output it...
>
> <cfoutput>
> <cfloop index="i" from="1" to="#pages.RecordCount#">
> #evaluate("strTextBlock#i#")#
> #evaluate("idText#i#")#
> </cfloop>
> </cfoutput>
>
> -----Original Message-----
> From: Shannon Hicks
> Sent: Thursday, June 27, 2002 5:36 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Dynamically build a variable name
>
>
> I'm sure I'll be the 18th response, but here:
>
> <cfloop index="i" from="1" to="#pages.RecordCount#">
> <cfset "strTextBlock#i#" = strTextBlock>
> <cfset "idText#i#" = idText>
> </cfloop>
>
>
> -----Original Message-----
> From: Nando [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 27, 2002 5:34 PM
> To: [EMAIL PROTECTED]
> Subject: Dynamically build a variable name
>
>
> Hi all,
>
> Anyone have any idea how to dynamically build a variable name?
>
> These throw errors but you get the idea from these examples:
>
> <cfloop index="i" from="1" to="#pages.RecordCount#">
> <cfset strTextBlock&#i# = strTextBlock>
> <cfset idText#i# = idText>
> </cfloop>
>
> i'm trying to assign each instance of strTextBlock to a unique variable,
> so i can use it wherever i want in the layout.
>
> Nando
>
>
------------------------------
Date: 27 Jun 2002 22:56:11 -0400
From: Russ Johnson <[EMAIL PROTECTED]>
Subject: Re: Content Management schema
I am quite fond of Allaires method of Content Management. The Content
Object Model has worked very well for me for the last couple of years in
my fusebox applications. You can find a version of this concept in the
ColdFusion sample apps. There is a good bit of documentation and an
Access database included. The only modifications I made to the database
when I moved it to SQL Server was to change the page field in the
instances table to a fuseaction field. Works like a charm!
Check it out, its very flexible.
Russ
On Thu, 2002-06-27 at 16:59, Nando wrote:
> I was wondering if anyone who has worked with this could comment on how
> they approached a database schema problem for an FB3 content management
> app. Maybe i'm missing the obvious here ... Here is the situation.
>
> First, a page request is always to a specific circuit.action, so it
> makes sense to me that each editable page element is related to a single
> circuit.action record. so i started with a simple table called
>
> tblCircuitAction
> fields
> * idCircuitAction
> * strCircuitAction
>
> Then the query to obtain the data for a particular page request is a
> join with the fully formed fuseaction at it's heart.
>
> Then there can be different types of editable content on each possible
> page view. To keep it simple, lets say we have just text and images.
>
> tblTexts
> fields
> * idText
> * idCircuitAction
> * strTextBlock
> * bitPublish
>
> tblImages
> fields
> * idImage
> * idCircuitAction
> * strImageName
> * bitPublish
>
> Now, as long as there is a one to one relationship between
> tblCircuitAction and tblTexts / tblImages, it's a no brainer. the cfcase
> includes a join query and a display file, and somewhere in the display
> file there is a single #strTextBlock# and a single #strImageName#
> (inside in image tag, of course). But of course, this is not what is
> really needed.
>
> Obviously, we need to accomodate more than one editable image or text
> block per page, indicating that the relationship between
> tblCircuitAction and tblTexts or tblImages is actually one to many. Now
> we're in a bit of a jam.
>
> Let's say i have 2 text blocks on a particular page. I run my query, it
> returns 2 records from the text table. Now what? In the display file,
> these 2 blocks of text mostly likely need to have uniquely defined
> positions, (we cannot count on outputting them with a loop, for
> instance) which suggests that they each need to be defined with uniquely
> named variables. Let's say our site administrator decides they want to
> add 20 text blocks to a particular page and our system allows that.
> Normalization here makes complete sense. But how to deal with the fact
> that normalization will not return the unique variable names we need to
> lay the page out as we might want. Seems like we need to assign variable
> names to the textBlocks on the fly.
>
> I have an idea how to accomplish this by placing something like this at
> the top of each display page:
>
> <cfloop index="i" from="1" to="#getTexts.RecordCount#">
> <cfset strTextBlock = 'strTextBlock#i#'>
> <cfset idText = 'idText#i#'>
> </cfloop>
>
> If i was smarter than i am, maybe something similar could be written
> into the query (or SP)
>
> Then i would have unique variable names assigned to each text block and
> it's id (so the admin of the site can click on an icon and edit it.) The
> only problem with assigning the variable names on the fly like this is
> that the locations on the page would then be interdependent with the way
> it was sorted. So i think the query would need to sort the records by id
> so you always get a consistently ordered result.
>
> My hack until today has been to create extra fields for the number of
> anticipated text blocks, strTextBlock1, strTextBlock2, etc - but what i
> don't like about this solution is that it gets messy for the person
> editing the site. it kind of forces me to present the admin user with
> more than one text entry box on their editing form. They click on the
> icon for textBlock1 and they see all the textBlock forms for that page.
> It's confusing. And of course, it's not very scalable.
>
> Does anyone have any comment here on how they would resolve this issue?
> I've been rolling this scenario around in my mind for quite some time.
>
> Nando
>
> * by the way, sorry for posting this to the fusebox list, but the
> community list seems to have been nuked.
>
>
------------------------------
Date: Fri, 28 Jun 2002 03:18:06 +0000
From: Nando <[EMAIL PROTECTED]>
Subject: RE: Dynamically build a variable name
Hey, that's the ticket! Elegant and efficient. Thanks for the
suggestion, Jeff. I'm embarrassed how obvious that actually was. ;-) n.
Jeff Peters wrote:
> This is where I would opt for an array. Those Evaluate() functions are
> slow.
> So I'd do this:
>
> <cfset aryTextBlock = ArrayNew()>
> <cfset aryIDText = ArrayNew()>
> <cfloop index="i" from="1" to="#pages.RecordCount#">
> <cfset aryTextBlock[i] = strTextBlock>
> <cfset aryIDText[i] = idText>
> </cfloop>
>
> Then to output them:
>
> <cfoutput>
> <cfloop index="i" from="1" to="#pages.RecordCount#">
> #aryTextBlock[i]#<br>
> #aryIDText[i]#
> </cfloop>
> </cfoutput>
>
> - Jeff
>
>
> On 27 Jun 2002 at 17:38, Shannon Hicks wrote:
>
> > And, on the flip side, if you wanted to output it...
> >
> > <cfoutput>
> > <cfloop index="i" from="1" to="#pages.RecordCount#">
> > #evaluate("strTextBlock#i#")#
> > #evaluate("idText#i#")#
> > </cfloop>
> > </cfoutput>
> >
> > -----Original Message-----
> > From: Shannon Hicks
> > Sent: Thursday, June 27, 2002 5:36 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Dynamically build a variable name
> >
> >
> > I'm sure I'll be the 18th response, but here:
> >
> > <cfloop index="i" from="1" to="#pages.RecordCount#">
> > <cfset "strTextBlock#i#" = strTextBlock>
> > <cfset "idText#i#" = idText>
> > </cfloop>
> >
> >
> > -----Original Message-----
> > From: Nando [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 27, 2002 5:34 PM
> > To: [EMAIL PROTECTED]
> > Subject: Dynamically build a variable name
> >
> >
> > Hi all,
> >
> > Anyone have any idea how to dynamically build a variable name?
> >
> > These throw errors but you get the idea from these examples:
> >
> > <cfloop index="i" from="1" to="#pages.RecordCount#">
> > <cfset strTextBlock&#i# = strTextBlock>
> > <cfset idText#i# = idText>
> > </cfloop>
> >
> > i'm trying to assign each instance of strTextBlock to a unique variable,
> >
> > so i can use it wherever i want in the layout.
> >
> > Nando
> >
> >
>
>
>
>
------------------------------
Date: Fri, 28 Jun 2002 03:31:14 +0000
From: Nando <[EMAIL PROTECTED]>
Subject: OT -- New Fusebox Mascot
http://www.koor.org/stuff/fun/movies/swf/go.swf
------------------------------
Date: Fri, 28 Jun 2002 12:49:13 +0900
From: =?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?= <[EMAIL PROTECTED]>
Subject: URL fuses
Hello.
I am curious about URL fuses and how they should be used. If I
understand correctly, their main purpose is to "jump" to another URL,
being particularly useful when following a form "post" or a modifying
action, by avoiding multiple occurrences of such requests.
Most URL fuses will contain a single <cflocation> tag and here comes the
first question: should the destination be hardcoded or specified through
an xfa? If the answer is the latter, than why not have a single, generic
URL fuse that jumps to a specified xfa destination?
E.g.
<cfset xfa.destination = "orders.view">
<cfinclude template="urlJumpTo.cfm">
Hum... I am not sure. Maybe the reason is because URL fuses can include
more than just code to jump, such as logic to decide where to jump to.
In that case, I repeat the question: should destinations be specified
through xfas or hardcoded in the URL fuse? I think that hardcoding the
destinations inside the URL fuse can make the circuit's flow harder to
follow, since one has to look inside the fuse to know the possible
destinations.
I seek advice and arguments on the proper usage of URL fuses. Your input
and answers to my queries will be much appreciated.
Thank you,
--
Ney Andr� de Mello Zunino
Media and Technology Laboratory
Campus Computing Centre
United Nations University
------------------------------
Date: Thu, 27 Jun 2002 22:55:26 -0500
From: "Keith Young" <[EMAIL PROTECTED]>
Subject: Re: Fusedoc advice please!
Ahhh.... I work in PHP, not CF :)
So, from a PHP perspective I am pretty confident that arrays are the answer.
And actually the application works amazingly well. Its been in acceptance
testing all week, and only 5 (very small) bugs have been found.
And really, I give a big nod to Fusebox for making the coding so easy for
the app.
Now if only I had done the Fusedoc first :)
Cheers,
Keith.
>From: Steve Nelson <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: Fusedoc advice please!
>Date: Wed, 26 Jun 2002 21:05:16 -0400
>
>This is just a personal preference, but I can't stand arrays. From what it
>sounds like you're doing, I'd most likely use grouped recordsets, then use
>the
><cfoutput group="field"> to output them. Although, I'm having a hard time
>picturing what you're trying to do. Can you post a URL to the prototype
>page? If
>you can show me that, i'll show you a very simple way to create fusedocs
>from
>your prototype page.
>
>Steve Nelson
>
>Keith Young wrote:
>
> > Hi all,
> >
> > I am trying to figure out the best way to Fusedoc a page with a lot of
> > dynamically built fields and dynamically built field names.
> >
> > A quick rundown of the page I am trying to Fusedoc:
> >
> > A row of 5 textboxes named dynamically based on the 5 previous years
>from
> > the current year. Before anyone notes the examples below aren't
>'current'
> > year, for the application it is :)
> >
> > The textbox names are basically this:
> >
> > wizpage3[pym][1996]
> > wizpage3[pym][1997]
> > wizpage3[pym][1998]
> > wizpage3[pym][1999]
> > wizpage3[pym][2000]
> >
> > So they will be an array when submitted.
> >
> > Next there is a statically named field
> > wizpage3[pct]
> >
> > And then several more dynamic rows each row containing 6 year boxes (5
> > previous years, plus current year):
> >
> > wizpage3[item1][1996]
> > wizpage3[item1][1997]
> > wizpage3[item1][1998]
> > wizpage3[item1][1999]
> > wizpage3[item1][2000]
> > wizpage3[item1][2001]
> >
> > wizpage3[item2][1996]
> > wizpage3[item2][1997]
> > wizpage3[item2][1998]
> > wizpage3[item2][1999]
> > wizpage3[item2][2000]
> > wizpage3[item2][2001]
> >
> > There are about 7 rows like that.
> >
> > And THEN, there are the 'dynamic' rows...basically, similar to above,
>except
> > the user selects items from a DDLB and can add as many of these dynamic
>rows
> > as needed, and the DDLB is built from a DB call, where the item1 name
>above
> > is more 'static':
> >
> > wizpage3[dyn_row][dr_item1][1996]
> > wizpage3[dyn_row][dr_item1][1997]
> > wizpage3[dyn_row][dr_item1][1998]
> > wizpage3[dyn_row][dr_item1][1999]
> > wizpage3[dyn_row][dr_item1][2000]
> > wizpage3[dyn_row][dr_item1][2001]
> >
> > wizpage3[dyn_row][dr_item2][1996]
> > wizpage3[dyn_row][dr_item2][1997]
> > wizpage3[dyn_row][dr_item2][1998]
> > wizpage3[dyn_row][dr_item2][1999]
> > wizpage3[dyn_row][dr_item2][2000]
> > wizpage3[dyn_row][dr_item2][2001]
> >
> > Now, to top it off, the user can use the next/previous buttons of the
> > application to travel from the next page (wizpage4) back to this one.
> >
> > However, from a Fusedoc perspective I don't think that is an issue, I
>would
> > just repeat the same data in two different scopes.
> >
> > But, I am unsure how to Fusedoc this page. The year is dynamic, so how
>do I
> > reflect that in a Fusedoc? I don't want to put a Fusedoc entry for
>every
> > dynamic row, since the rownames could change based on the database
>updates.
> >
> > Does anyone have suggestions on how to FD this mess?
> >
> > The application already runs, but I want to make sure there are proper
> > Fusedocs for it. (Actually a combination of Fusedocs and phpDocs). Man,
> > next time I'll do the Fusedoc first ;p
> >
> > Thanks in advance for any help/suggestions.
> >
> > Cheers,
> > Keith.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at
>http://explorer.msn.com/intl.asp.
> >
>
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
------------------------------
Date: Thu, 27 Jun 2002 22:56:51 -0500
From: "Keith Young" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Fusedoc advice please!
This is a good idea! I think I will do something very similar to this!
Cheers,
Keith.
>From: Jeff Peters <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: Fusedoc advice please!
>Date: Wed, 26 Jun 2002 23:01:54 -0400
>
>When I do dynamic variable names, I do it like this:
>
><string name="myField%number%"
> comment="One or more instances; %number% represents an integer
>sequence number" />
>
>In your case, it looks like you're using a structure, so all you need to do
>is
>this:
>
><structure name="wizpage3">
> <structure name="%item%" comments="one or more instances; %item%
>is a string item number">
> <string name="%year%" comments="One or more instances; %year% is
>a four-digit year" />
> </structure>
></structure>
>
>OTOH, if your bracket notation simply indicates the variable portions of
>your
>hard variable names, you'd do something like this:
>
><string name="wizpage3%item%%year%" comments="one or more
>instances; %item% is a string identifier and %year% is a four-digit year"
>/>
>
>- Jeff
>
> > Keith Young wrote:
> >
> > > Hi all,
> > >
> > > I am trying to figure out the best way to Fusedoc a page with a lot of
> > > dynamically built fields and dynamically built field names.
> > >
> > > A quick rundown of the page I am trying to Fusedoc:
> > >
> > > A row of 5 textboxes named dynamically based on the 5 previous years
>from
> > > the current year. Before anyone notes the examples below aren't
>'current'
> > > year, for the application it is :)
> > >
> > > The textbox names are basically this:
> > >
> > > wizpage3[pym][1996]
> > > wizpage3[pym][1997]
> > > wizpage3[pym][1998]
> > > wizpage3[pym][1999]
> > > wizpage3[pym][2000]
> > >
> > > So they will be an array when submitted.
> > >
> > > Next there is a statically named field
> > > wizpage3[pct]
> > >
> > > And then several more dynamic rows each row containing 6 year boxes (5
> > > previous years, plus current year):
> > >
> > > wizpage3[item1][1996]
> > > wizpage3[item1][1997]
> > > wizpage3[item1][1998]
> > > wizpage3[item1][1999]
> > > wizpage3[item1][2000]
> > > wizpage3[item1][2001]
> > >
> > > wizpage3[item2][1996]
> > > wizpage3[item2][1997]
> > > wizpage3[item2][1998]
> > > wizpage3[item2][1999]
> > > wizpage3[item2][2000]
> > > wizpage3[item2][2001]
> > >
> > > There are about 7 rows like that.
> > >
> > > And THEN, there are the 'dynamic' rows...basically, similar to above,
>except
> > > the user selects items from a DDLB and can add as many of these
>dynamic rows
> > > as needed, and the DDLB is built from a DB call, where the item1 name
>above
> > > is more 'static':
> > >
> > > wizpage3[dyn_row][dr_item1][1996]
> > > wizpage3[dyn_row][dr_item1][1997]
> > > wizpage3[dyn_row][dr_item1][1998]
> > > wizpage3[dyn_row][dr_item1][1999]
> > > wizpage3[dyn_row][dr_item1][2000]
> > > wizpage3[dyn_row][dr_item1][2001]
> > >
> > > wizpage3[dyn_row][dr_item2][1996]
> > > wizpage3[dyn_row][dr_item2][1997]
> > > wizpage3[dyn_row][dr_item2][1998]
> > > wizpage3[dyn_row][dr_item2][1999]
> > > wizpage3[dyn_row][dr_item2][2000]
> > > wizpage3[dyn_row][dr_item2][2001]
> > >
> > > Now, to top it off, the user can use the next/previous buttons of the
> > > application to travel from the next page (wizpage4) back to this one.
> > >
> > > However, from a Fusedoc perspective I don't think that is an issue, I
>would
> > > just repeat the same data in two different scopes.
> > >
> > > But, I am unsure how to Fusedoc this page. The year is dynamic, so
>how do I
> > > reflect that in a Fusedoc? I don't want to put a Fusedoc entry for
>every
> > > dynamic row, since the rownames could change based on the database
>updates.
> > >
> > > Does anyone have suggestions on how to FD this mess?
> > >
> > > The application already runs, but I want to make sure there are proper
> > > Fusedocs for it. (Actually a combination of Fusedocs and phpDocs).
>Man,
> > > next time I'll do the Fusedoc first ;p
> > >
> > > Thanks in advance for any help/suggestions.
> > >
> > > Cheers,
> > > Keith.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
>http://explorer.msn.com/intl.asp.
> > >
> >
> >
>
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
------------------------------
Date: Fri, 28 Jun 2002 04:33:27 +0000
From: Nando <[EMAIL PROTECTED]>
Subject: RE: Content Management schema
Russ, thanks for the tip ... where did you find this? I looked through
what i had on my HD under CFDOCS and couldn't find it. i also searched
on Macromedia ... should i be looking on the CFAS 4.5 installation CD?
I'm using version 5.
n.
Russ Johnson wrote:
> I am quite fond of Allaires method of Content Management. The Content
> Object Model has worked very well for me for the last couple of years in
> my fusebox applications. You can find a version of this concept in the
> ColdFusion sample apps. There is a good bit of documentation and an
> Access database included. The only modifications I made to the database
> when I moved it to SQL Server was to change the page field in the
> instances table to a fuseaction field. Works like a charm!
>
> Check it out, its very flexible.
>
> Russ
>
>
> On Thu, 2002-06-27 at 16:59, Nando wrote:
> > I was wondering if anyone who has worked with this could comment on how
> > they approached a database schema problem for an FB3 content management
> > app. Maybe i'm missing the obvious here ... Here is the situation.
> >
> > First, a page request is always to a specific circuit.action, so it
> > makes sense to me that each editable page element is related to a single
> >
> > circuit.action record. so i started with a simple table called
> >
> > tblCircuitAction
> > fields
> > * idCircuitAction
> > * strCircuitAction
> >
> > Then the query to obtain the data for a particular page request is a
> > join with the fully formed fuseaction at it's heart.
> >
> > Then there can be different types of editable content on each possible
> > page view. To keep it simple, lets say we have just text and images.
> >
> > tblTexts
> > fields
> > * idText
> > * idCircuitAction
> > * strTextBlock
> > * bitPublish
> >
> > tblImages
> > fields
> > * idImage
> > * idCircuitAction
> > * strImageName
> > * bitPublish
> >
> > Now, as long as there is a one to one relationship between
> > tblCircuitAction and tblTexts / tblImages, it's a no brainer. the cfcase
> >
> > includes a join query and a display file, and somewhere in the display
> > file there is a single #strTextBlock# and a single #strImageName#
> > (inside in image tag, of course). But of course, this is not what is
> > really needed.
> >
> > Obviously, we need to accomodate more than one editable image or text
> > block per page, indicating that the relationship between
> > tblCircuitAction and tblTexts or tblImages is actually one to many. Now
> > we're in a bit of a jam.
> >
> > Let's say i have 2 text blocks on a particular page. I run my query, it
> > returns 2 records from the text table. Now what? In the display file,
> > these 2 blocks of text mostly likely need to have uniquely defined
> > positions, (we cannot count on outputting them with a loop, for
> > instance) which suggests that they each need to be defined with uniquely
> >
> > named variables. Let's say our site administrator decides they want to
> > add 20 text blocks to a particular page and our system allows that.
> > Normalization here makes complete sense. But how to deal with the fact
> > that normalization will not return the unique variable names we need to
> > lay the page out as we might want. Seems like we need to assign variable
> >
> > names to the textBlocks on the fly.
> >
> > I have an idea how to accomplish this by placing something like this at
> > the top of each display page:
> >
> > <cfloop index="i" from="1" to="#getTexts.RecordCount#">
> > <cfset strTextBlock = 'strTextBlock#i#'>
> > <cfset idText = 'idText#i#'>
> > </cfloop>
> >
> > If i was smarter than i am, maybe something similar could be written
> > into the query (or SP)
> >
> > Then i would have unique variable names assigned to each text block and
> > it's id (so the admin of the site can click on an icon and edit it.) The
> >
> > only problem with assigning the variable names on the fly like this is
> > that the locations on the page would then be interdependent with the way
> >
> > it was sorted. So i think the query would need to sort the records by id
> >
> > so you always get a consistently ordered result.
> >
> > My hack until today has been to create extra fields for the number of
> > anticipated text blocks, strTextBlock1, strTextBlock2, etc - but what i
> > don't like about this solution is that it gets messy for the person
> > editing the site. it kind of forces me to present the admin user with
> > more than one text entry box on their editing form. They click on the
> > icon for textBlock1 and they see all the textBlock forms for that page.
> > It's confusing. And of course, it's not very scalable.
> >
> > Does anyone have any comment here on how they would resolve this issue?
> > I've been rolling this scenario around in my mind for quite some time.
> >
> > Nando
> >
> > * by the way, sorry for posting this to the fusebox list, but the
> > community list seems to have been nuked.
> >
> >
>
>
>
>
>
------------------------------
Date: Fri, 28 Jun 2002 12:39:10 +0800
From: "Kay Smoljak" <[EMAIL PROTECTED]>
Subject: RE: URL fuses
Hi Ney,
I like your questions, they are generating a lot of interesting
responses. I'm sure this one will too!
I don't use url fuses - I put my cflocations and any conditionals into
the switch itself.
<cfcase value="deleteRecord>
<cfinclude template="act_deleteRecord.cfm">
<cfif isNew>
<cfset xfa.redirect = "#fusebox.thisCircuit#.listNewRecords">
<cfelse>
<cfset xfa.redirect = "#fusebox.thisCircuit#.listOldRecords">
</cfif>
<cflocation url="#baseURL##self##xfa.redirect#">
</cfcase>
This helps makes my switch file a map of the application. If there was a
*lot* of conditionals to decide where to cflocate to, I might consider
using a url fuse.
Kay.
> -----Original Message-----
> From: Ney Andr� de Mello Zunino [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 28 June 2002 11:49 AM
> To: Fusebox mailing list
> Subject: URL fuses
>
>
> Hello.
>
> I am curious about URL fuses and how they should be used. If I
> understand correctly, their main purpose is to "jump" to another URL,
> being particularly useful when following a form "post" or a modifying
> action, by avoiding multiple occurrences of such requests.
>
> Most URL fuses will contain a single <cflocation> tag and
> here comes the
> first question: should the destination be hardcoded or
> specified through
> an xfa? If the answer is the latter, than why not have a
> single, generic
> URL fuse that jumps to a specified xfa destination?
>
> E.g.
>
> <cfset xfa.destination = "orders.view">
> <cfinclude template="urlJumpTo.cfm">
>
> Hum... I am not sure. Maybe the reason is because URL fuses
> can include
> more than just code to jump, such as logic to decide where to
> jump to.
> In that case, I repeat the question: should destinations be specified
> through xfas or hardcoded in the URL fuse? I think that
> hardcoding the
> destinations inside the URL fuse can make the circuit's flow
> harder to
> follow, since one has to look inside the fuse to know the possible
> destinations.
>
> I seek advice and arguments on the proper usage of URL fuses.
> Your input
> and answers to my queries will be much appreciated.
>
> Thank you,
>
> --
> Ney Andr� de Mello Zunino
> Media and Technology Laboratory
> Campus Computing Centre
> United Nations University
>
> >
------------------------------
Date: Thu, 27 Jun 2002 23:26:11 -0700
From: "Douglas Brown" <[EMAIL PROTECTED]>
Subject: Re: OT -- New Fusebox Mascot
Man that is just toooo friggin cool. Somebody must have had alot
of time on their hands....
Douglas Brown
Email: [EMAIL PROTECTED]
----- Original Message -----
From: "Nando" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 27, 2002 8:31 PM
Subject: OT -- New Fusebox Mascot
> http://www.koor.org/stuff/fun/movies/swf/go.swf
>
>
===
>
>
------------------------------
Date: Fri, 28 Jun 2002 03:12:36 -0400
From: "Timothy Heald" <[EMAIL PROTECTED]>
Subject: RE: URL fuses
I do the same thing, only I don't use CF redirection, I use javaScript :)
Tim
-----Original Message-----
From: Kay Smoljak [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 28, 2002 12:39 AM
To: [EMAIL PROTECTED]
Subject: RE: URL fuses
Hi Ney,
I like your questions, they are generating a lot of interesting
responses. I'm sure this one will too!
I don't use url fuses - I put my cflocations and any conditionals into
the switch itself.
<cfcase value="deleteRecord>
<cfinclude template="act_deleteRecord.cfm">
<cfif isNew>
<cfset xfa.redirect = "#fusebox.thisCircuit#.listNewRecords">
<cfelse>
<cfset xfa.redirect = "#fusebox.thisCircuit#.listOldRecords">
</cfif>
<cflocation url="#baseURL##self##xfa.redirect#">
</cfcase>
This helps makes my switch file a map of the application. If there was a
*lot* of conditionals to decide where to cflocate to, I might consider
using a url fuse.
Kay.
> -----Original Message-----
> From: Ney Andr� de Mello Zunino [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 28 June 2002 11:49 AM
> To: Fusebox mailing list
> Subject: URL fuses
>
>
> Hello.
>
> I am curious about URL fuses and how they should be used. If I
> understand correctly, their main purpose is to "jump" to another URL,
> being particularly useful when following a form "post" or a modifying
> action, by avoiding multiple occurrences of such requests.
>
> Most URL fuses will contain a single <cflocation> tag and
> here comes the
> first question: should the destination be hardcoded or
> specified through
> an xfa? If the answer is the latter, than why not have a
> single, generic
> URL fuse that jumps to a specified xfa destination?
>
> E.g.
>
> <cfset xfa.destination = "orders.view">
> <cfinclude template="urlJumpTo.cfm">
>
> Hum... I am not sure. Maybe the reason is because URL fuses
> can include
> more than just code to jump, such as logic to decide where to
> jump to.
> In that case, I repeat the question: should destinations be specified
> through xfas or hardcoded in the URL fuse? I think that
> hardcoding the
> destinations inside the URL fuse can make the circuit's flow
> harder to
> follow, since one has to look inside the fuse to know the possible
> destinations.
>
> I seek advice and arguments on the proper usage of URL fuses.
> Your input
> and answers to my queries will be much appreciated.
>
> Thank you,
>
> --
> Ney Andr� de Mello Zunino
> Media and Technology Laboratory
> Campus Computing Centre
> United Nations University
>
> >
------------------------------
Date: Fri, 28 Jun 2002 17:22:52 +1000
From: "Lee Borkman" <[EMAIL PROTECTED]>
Subject: Re: URL fuses
Hi guys,
To tell the truth, I don't use URL fuses either, but I can see the value if you
have several fuseactions that want to cflocate to the same place. You code the
cflocation into a URL fuse, and then you can change the location for all of the
relevant fuseactions with a single piece of code.
In general, though, I set all my XFAs at the beginning of each fuseaction, and
then I use them later in the fuseaction or in the cfincluded fuses. Eg.,
<cfcase value="insertCustomer">
<cfset XFA.onComplete="customers.listCustomers">
<cfinclude template="qry_insertcustomer.cfm">
<cflocation url="#self#?fuseaction=#XFA.onComplete#">
</cfcase>
This keeps all of fuseactions consistent, so that I can always see all possible
exit points defined right at the top of each fuseaction.
As far as I can see, there is no good reason to define an XFA and then include a
generic urlJumpTo fuse, as in Ney's example.
Whatcha reckon?
LeeBB
----- Original Message -----
From: Kay Smoljak <[EMAIL PROTECTED]>
Hi Ney,
I like your questions, they are generating a lot of interesting
responses. I'm sure this one will too!
I don't use url fuses - I put my cflocations and any conditionals into
the switch itself.
<cfcase value="deleteRecord>
<cfinclude template="act_deleteRecord.cfm">
<cfif isNew>
<cfset xfa.redirect = "#fusebox.thisCircuit#.listNewRecords">
<cfelse>
<cfset xfa.redirect = "#fusebox.thisCircuit#.listOldRecords">
</cfif>
<cflocation url="#baseURL##self##xfa.redirect#">
</cfcase>
This helps makes my switch file a map of the application. If there was a
*lot* of conditionals to decide where to cflocate to, I might consider
using a url fuse.
Kay.
> -----Original Message-----
> From: Ney Andr� de Mello Zunino [mailto:[EMAIL PROTECTED]]
>
> Hello.
>
> I am curious about URL fuses and how they should be used. If I
> understand correctly, their main purpose is to "jump" to another URL,
> being particularly useful when following a form "post" or a modifying
> action, by avoiding multiple occurrences of such requests.
>
> Most URL fuses will contain a single <cflocation> tag and
> here comes the
> first question: should the destination be hardcoded or
> specified through
> an xfa? If the answer is the latter, than why not have a
> single, generic
> URL fuse that jumps to a specified xfa destination?
>
> E.g.
>
> <cfset xfa.destination = "orders.view">
> <cfinclude template="urlJumpTo.cfm">
>
> Hum... I am not sure. Maybe the reason is because URL fuses
> can include
> more than just code to jump, such as logic to decide where to
> jump to.
> In that case, I repeat the question: should destinations be specified
> through xfas or hardcoded in the URL fuse? I think that
> hardcoding the
> destinations inside the URL fuse can make the circuit's flow
> harder to
> follow, since one has to look inside the fuse to know the possible
> destinations.
>
> I seek advice and arguments on the proper usage of URL fuses.
> Your input
> and answers to my queries will be much appreciated.
>
> Thank you,
>
> --
> Ney Andr� de Mello Zunino
> Media and Technology Laboratory
> Campus Computing Centre
> United Nations University
>
> >
------------------------------
Date: Fri, 28 Jun 2002 12:28:24 +0300
From: "Erki Esken" <[EMAIL PROTECTED]>
Subject: Re: Content Management schema
> Russ, thanks for the tip ... where did you find this? I looked through
> what i had on my HD under CFDOCS and couldn't find it. i also searched
> on Macromedia ... should i be looking on the CFAS 4.5 installation CD?
> I'm using version 5.
>
Russ, I've used that same example app to build a content management system,
and yes, it is quite a powerful idea. I think Spectra's roots are in that
content management example app :) Anyway, the idea and example code translate
well into a fusebox app.
Oh, and you can find it in the /cfdocs/exampleapps/ folder if you install
CF4.0x (not 4.5, 5.0 nor MX).
.erki
------------------------------
Date: Fri, 28 Jun 2002 10:37:37 +0100
From: "Neil Clark - =TMM=" <[EMAIL PROTECTED]>
Subject: RE: Content Management schema
Agreed, it is a very powerful OOP style development process... it is
good because it gives a level of abstraction from display and
database...
Neil Clark
Team Macromedia Spectra
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Russ Johnson [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 03:56
To: [EMAIL PROTECTED]
Subject: Re: Content Management schema
I am quite fond of Allaires method of Content Management. The Content
Object Model has worked very well for me for the last couple of years in
my fusebox applications. You can find a version of this concept in the
ColdFusion sample apps. There is a good bit of documentation and an
Access database included. The only modifications I made to the database
when I moved it to SQL Server was to change the page field in the
instances table to a fuseaction field. Works like a charm!
Check it out, its very flexible.
Russ
On Thu, 2002-06-27 at 16:59, Nando wrote:
> I was wondering if anyone who has worked with this could comment on
how
> they approached a database schema problem for an FB3 content
management
> app. Maybe i'm missing the obvious here ... Here is the situation.
>
> First, a page request is always to a specific circuit.action, so it
> makes sense to me that each editable page element is related to a
single
> circuit.action record. so i started with a simple table called
>
> tblCircuitAction
> fields
> * idCircuitAction
> * strCircuitAction
>
> Then the query to obtain the data for a particular page request is a
> join with the fully formed fuseaction at it's heart.
>
> Then there can be different types of editable content on each possible
> page view. To keep it simple, lets say we have just text and images.
>
> tblTexts
> fields
> * idText
> * idCircuitAction
> * strTextBlock
> * bitPublish
>
> tblImages
> fields
> * idImage
> * idCircuitAction
> * strImageName
> * bitPublish
>
> Now, as long as there is a one to one relationship between
> tblCircuitAction and tblTexts / tblImages, it's a no brainer. the
cfcase
> includes a join query and a display file, and somewhere in the display
> file there is a single #strTextBlock# and a single #strImageName#
> (inside in image tag, of course). But of course, this is not what is
> really needed.
>
> Obviously, we need to accomodate more than one editable image or text
> block per page, indicating that the relationship between
> tblCircuitAction and tblTexts or tblImages is actually one to many.
Now
> we're in a bit of a jam.
>
> Let's say i have 2 text blocks on a particular page. I run my query,
it
> returns 2 records from the text table. Now what? In the display file,
> these 2 blocks of text mostly likely need to have uniquely defined
> positions, (we cannot count on outputting them with a loop, for
> instance) which suggests that they each need to be defined with
uniquely
> named variables. Let's say our site administrator decides they want to
> add 20 text blocks to a particular page and our system allows that.
> Normalization here makes complete sense. But how to deal with the fact
> that normalization will not return the unique variable names we need
to
> lay the page out as we might want. Seems like we need to assign
variable
> names to the textBlocks on the fly.
>
> I have an idea how to accomplish this by placing something like this
at
> the top of each display page:
>
> <cfloop index="i" from="1" to="#getTexts.RecordCount#">
> <cfset strTextBlock = 'strTextBlock#i#'>
> <cfset idText = 'idText#i#'>
> </cfloop>
>
> If i was smarter than i am, maybe something similar could be written
> into the query (or SP)
>
> Then i would have unique variable names assigned to each text block
and
> it's id (so the admin of the site can click on an icon and edit it.)
The
> only problem with assigning the variable names on the fly like this is
> that the locations on the page would then be interdependent with the
way
> it was sorted. So i think the query would need to sort the records by
id
> so you always get a consistently ordered result.
>
> My hack until today has been to create extra fields for the number of
> anticipated text blocks, strTextBlock1, strTextBlock2, etc - but what
i
> don't like about this solution is that it gets messy for the person
> editing the site. it kind of forces me to present the admin user with
> more than one text entry box on their editing form. They click on the
> icon for textBlock1 and they see all the textBlock forms for that
page.
> It's confusing. And of course, it's not very scalable.
>
> Does anyone have any comment here on how they would resolve this
issue?
> I've been rolling this scenario around in my mind for quite some time.
>
> Nando
>
> * by the way, sorry for posting this to the fusebox list, but the
> community list seems to have been nuked.
>
>
------------------------------
Date: Fri, 28 Jun 2002 12:43:33 +0300
From: "Erki Esken" <[EMAIL PROTECTED]>
Subject: Re: Content Management schema
> Oh, and you can find it in the /cfdocs/exampleapps/ folder if you
> install CF4.0x (not 4.5, 5.0 nor MX).
Sorry, seems that 4.5 has it too, you can get the code from
/exampleapps/publish/ folder in this zip:
http://www.macromedia.com/v1/documents/cf45docs/compressed/cfdocs.zip
But the Access database is not in that zip, you still have to install
4.5 or 4.0 to get it.
.erki
------------------------------
Date: Fri, 28 Jun 2002 11:13:06 +0100
From: "Neil Clark - =TMM=" <[EMAIL PROTECTED]>
Subject: RE: Content Management schema
Erki,
It�s the otherway around > the example was based on Spectra!!! What you
now know as Spectra was developed by the Allaire bro's a long time ago
to run the Allaire website, it was adapted, increased in size and
functionality, and rebranded Spectra.
If anyone needs any pointers on the Type > Properties > Object > Handler
system feel free to mail me offline as I am not sure if its Fusebox
related!
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Erki Esken [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 10:28
To: [EMAIL PROTECTED]
Subject: Re: Content Management schema
> Russ, thanks for the tip ... where did you find this? I looked through
> what i had on my HD under CFDOCS and couldn't find it. i also searched
> on Macromedia ... should i be looking on the CFAS 4.5 installation CD?
> I'm using version 5.
>
Russ, I've used that same example app to build a content management
system,
and yes, it is quite a powerful idea. I think Spectra's roots are in
that
content management example app :) Anyway, the idea and example code
translate
well into a fusebox app.
Oh, and you can find it in the /cfdocs/exampleapps/ folder if you
install
CF4.0x (not 4.5, 5.0 nor MX).
.erki
------------------------------
End of [EMAIL PROTECTED] digest, issue 840
