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

[Oliver Lineham]

At 16:53 26/09/00 -0700, you wrote:

>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: 1.  First, why can't I make a scoped variable a structure?
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>you can.  i do it all the time.
>
>session.styles = StructNew()
>session.styles.body = StructNew()
>session.styles.body.margin = '0px'
>session.styles.body.border = '0px'
>session.styles.table = StructNew()

Ah. I see.  You have to StructNew() everything.  Of course, you can ignore 
StructNew() completely and just use the dot notation straight away which 
appears to work almost identically, except that you can no longer pass the 
structure to a customer tag (CF complains that it is "unable to determine 
the value of the parameter").  Hmm.

>(ii) why wouldn't you want all contents of a structure to be copied into the
>attributes scope within the tag?  how else do you propose to access the
>values if they're not in the attributes scope?

I think we're at cross-purposes here.

If you have a struct called foobar and pass it using attributecollection, eg:
<cfscript>
foobar=structnew();
foobar.mork = 1;
foobar.mindy = 2;
</cfscript>
<cf_mycustomtag attributecollection="#foobar#" something="else" peas="carrots">

Within mycustomtag.cfm, the following variables are now set:
attributes.mork, attributes.mindy, attributes.something, attributes.else

IOW all the contents of the foobar structure have been dumped into the same 
scope as everything else and there is no way to deal with as a discrete unit.

As you've shown, there are other ways to pass the structure.  But now I'm 
left wondering what the point of attributescope is at all.

><!--- call custom tag "mycustomtag.cfm" --->
><cf_mycustomtag attribute1="#struct1#" attribute2="#struct2#">
>
><!--- mycustomtag --->
><cfparam name="attributes.attribute1" default="">
><cfparam name="attributes.attribute2" default="">
>
><cfset mystruct1 = Evaluate('caller.' & attributes.attribute1)>
><cfif IsStruct(mystruct1)>
>   do stuff to your struct here
></cfif>
>
><cfset mystruct2 = Evaluate('caller.' & attributes.attribute2)>
><cfif IsStruct(mystruct2)>
>   do stuff to your struct here
></cfif>

I'm not sure it's this complicated - I've just been playing with this stuff 
recently and the contents of both structs is accessible within the custom 
tag via attributes.attribute1.somevariable.  I'm not trying to modify the 
contents of the original variables in the caller (although it's nice to 
know how to do it), that would break encapsulation.


Sideline here while we are talking about evaluate():  I got sick of using a 
dozen cfparam tags and Trim()'s when bringing in long form data. Can you 
see any reason why the following is a bad idea?  It can save many lines of 
code.

<cfset formfields="form,username,password,foo,bar,pinky,brain">
<cfloop index=thefield list="#formfields#">
         <cfparam name="Form.#thefield#" default="">
         <cfset "Form.#thefield#" = trim(Evaluate("Form.#thefield#"))>
</cfloop>


>i'm not sure where you get the idea that a structure that's brought into a
>custom tag has it's data dumped in with everything else within the tag.
>it's assigned to a single attributes scoped variable.  does what i've
>supplied help address this concern?

Yes, the reason I was having trouble bringing structures in before using 
anything other than attributescope is that I hadn't used StructNew(), I had 
simply used the dot notation directly.

>no, that's not a valid solution to the problem.  of course, i'm not sure
>that the use of cfmodule to call a custom tag is the solution either.  i
>personally prefer the cf_ method of calling a custom tag as shown above.

I preferred cf_ until I found I couldn't access custom tags that aren't in 
the current directory.

What would be the equivalent cf_ version of doing <cfmodule 
template="../tag.cfm">?

Bearing in mind that I don't have access to the CF installation to use the 
customtags directory.

>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: Yuck.  What an insane language.  I think it was invented
>: by a GW-BASIC coder from way back.
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>speak poorly of it all you want (i understand that's easy to do when you're
>frustrated), but the reality is it's extremely powerful and will let you do
>most anything, provided you have a solid understanding of it's strengths and
>weaknesses, advantages and disadvantages, features and limitations, etc.

Regardless, its structure (bad choice of word, sorry) it smells of early 
HTML standards where not enough thought went into naming conventions.

That said, PHP is just as bad.  And I'm used to languages (like C) which 
have had a long history of evolution to get to the relatively clean state 
they are in now.

>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: And while I'm in this bout of code-rage, I have to
>: say that Allaire's documentation is pathetic.
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>i've seen plenty of doco (for all sorts of languages) in my journey to this
>point and i'd have to say there isn't much out there that's on par with
>allaire's cold fusion documentation.

I have to disagree, I think it some of the worst I've seen.  Badly 
structured, badly written.   Again though, I'm used to "big" languages 
where concise documentation is essential.  I also suspect the OO nature of 
these other languages demands well structured documentation.


Incidentally, I had four main reasons for dropping PHP:
1.  A lack of a resident server version (rather than the php executable 
being called each time)
2.  Inefficient session variables (saved to a text file), because of number 1.
3.  Lack of genuine object orientation (the inheritance model is 
incomplete, and you run into real trouble when trying to inherit from a 
derived class)
4.  Messy functions collection (see the functions quickref)

1. and 2. I understand should be solved shortly.  4. I can put up with.  3. 
however looks to remain unsolved, as the creators haven't shown much concern.

CF isn't genuinely OO either as far as I can tell, it just feels that way 
because of all the includes and custom tags.  In reality, that can be done 
with PHP or Perl except the code just *looks* so much less pretty.

I wonder what ASP is like. I haven't seen much of it at all.

Oliver.
*sometimes i wish i'd just become a plumber*

____________________________________________________
     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