[thelist] CF: Passing structures to custom tags - and more.

Oliver Lineham oliver at lineham.co.nz
Tue Sep 26 01:43:27 CDT 2000

I have questions about some more CF aspects that seem really stoopid to 
me  - bear in mind I come from an OO C++/Java/Perl etc 
background.  Probably someone with a similar OO background might be able to 
give me help, as you'll know where I'm coming from with hierarchies and 
encapsulation and the like.  This time it's structures.  This is somewhat 
of a rant.  On with the show.

1.  First, why can't I make a scoped variable a structure?  That is,
	somevar = StructNew()
is fine, but
	somescope.somevar = StructNew()
is not.  Nuts.
Same problem with somevar["somekey"] - it must be initialised with 
ArrayNew(), which doesn't like working within a scope.

2.  Can anyone tell me why, if you want to pass a structure to a custom 
tag, (i) you can only pass a maximum of one structure (via 
ATTRIBUTECOLLECTION), and (ii) all contents of the structure get copied 
into the ATTRIBUTES scope within the tag?  That's crazy.

3.  Assuming you've justified the crazy stuff above, can someone tell me 
the sensible way we are expected to do all of the following:

  (i) Collect related variables together in a structure more than 1-deep. 
For example, you might have a structure called people, and one thing all 
employees have is an address - which is another structure, containing house 
number, street, etc.   It seems impossible to do this.

  (ii) Pass multiple structures to a custom tag.  For example, you might 
want to pass a tag three distinct structures: employee, product, 
vegetable.   They're all quite different things. They should stay apart, 
passed as separate structures.

  (iii) Pass structures to custom tags without all their contents being 
dumped, like a items from a broken grocery bag, into the global scope 
within the tag.  If I've passed a structure, it's because its data is meant 
to be distinct from the other attributes I'm passing.  It should stay that way.

Note that an appropriate solution is not "Oh, just use CFINCLUDE instead of 
CFMODULE and then access anything you like". (By that reasoning, all C++ 
programs should use global variables and nothing else. Yeah, right)

Here's an example:

You have your tag which takes the structures: employee, product, and 
vegetable. Your tag is supposed to display the data in some sensible way. 
But, there are three possible ways we might want it displayed - so to 
distinguish them we will pass the attribute "displaytype".  For example, 
displaytype="summary", or displaytype="detailed".

  (a) We want the structures to stay separate within the tag because they 
are distinct data and need to stay that way .. both vegetables and 
employees have names, we need to know them both, they need to stay separate.
If we are really smart, we might pass the vegetable structure straight on 
to some other template which knows how to display vegetables. We can't do 
this if the vegetable structure doesn't stay in its structure form.

  (b) The displaytype attribute is only relevant to this tag (and that's 
why we use CFMODULE not CFINCLUDE). We shouldn't have to CFSET a 
displaytype variable just so we can use a CFINCLUDE as though it were a 
Furthermore, we will want to use this display template in multiple places 
through the site - and we cannot guarantee that the three structures will 
always have the same name.  In the area where we are adding a new employee, 
it might be called newemployee.  In the area where we are making employees 
fight, it might be called contestantone.  Who knows.  The display template 
shouldn't have to care though, so long as it's passed one employee.

Yuck.  What an insane language.  I think it was invented by a GW-BASIC 
coder from way back.   And while I'm in this bout of code-rage (why don't 
they make computers with horns to toot?), I have to say that Allaire's 
documentation is pathetic.



     v i b e   m e d i a    http://www.vibe.co.nz/
  po box 10-492              wellington, new zealand
  phone +64 21 210-7845         oliver at lineham.co.nz

More information about the thelist mailing list