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

[Oliver Lineham]

At 16:41 27/09/00 -0700, you wrote:

>yes, precisely.  how else would the cold fusion server know you were
>creating structures except to implicitly tell it?
[..]
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: 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
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>that's because without initializing each structure, you're just creating
>individual variables that just happen to have dots within the variable name.

This is where my confusion arose.  Pretty much all other programming 
languages don't let you use special operators like '.' as part of the 
variable name if '.' also means something like accessing a structure's 
member.  This also does away with the need for a StructNew() function 
altogether.

Why would you want a dot in a variable name, out of interest?

[attributecollection]
>since it creates a variable for every key in the structure in the attributes
>scope within the custom tag (and also will most likely only handle
>single-level structures), i would recommend that you abandon it's use.

Which is pretty simple to do, since I never started using it! ;)

>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: 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.
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>is it working for you to do this when initializing each level of the
>structure or are you simply using dot notation?

Yes, I am initialising every level of the structure. Here's a sanitized 
version of my code:

<!--- caller.cfm --->
<cfscript>
         something = StructNew();
         something.firststruct = StructNew();
         something.firststruct.a = 50;
</cfscript>

<cf_callee first="#firststruct#">


<!--- callee.cfm --->
<cfparam name="attributes.first">

<cfoutput>#attributes.first.a#</cfoutput>



This does display "50" as expected.

>the solution i posted above was necessary to copy a query into a custom tag.

That's not surprising.  CF's queries work similar to things like queries, 
files, and streams in other languages - you have a variable containing the 
query "handle", not the query itself.  When you pass the query, it's 
actually just the query handle string.

It makes complete sense (from a security perspective) to not allow custom 
tags to see the queries of the caller, even if it knows the query 
handle.  It also makes sense to avoid namespace conflicts.

>structures may behave slightly differently (makes even less sense for the
>special attribute, attributescollection, now), although i doubt it.  if i
>have some time to play around with some examples i will try to confirm or
>deny this behavior.

Rather than using Eval()'s to pass the query, I'd probably just loop over 
the query results in the caller to copy the data into a Struct, then pass 
the Struct to the callee.  The code would just be cleaner, IMO.

There would be a little duplication of data though - which I guess could be 
an issue if you were pulling MB's out of the database in each record..

>furthermore, why are you even bothering with altering form data when 
>paraming it?

Because, in many cases, every single field needs to be param'd AND 
trimmed.  If everything needs trimming, then it makes sense to do it all at 
once. If I have 50 fields, that's 100 lines of code.  When I could do it 
with 5.

I haven't got any diagnostic stuff for windows (and don't have CF for 
linux) to find out exactly how heavy the performance hit is.  I suspect not 
much.

>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: 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.
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>not a problem.  it's a hack, but one that could be used by anyone that's in
>a shared hosting environment.  just put all your custom tags in a single
>directory.  then, in any directory where you need to call that custom tag
>just place a file with the same name as the custom tag, except it's only
>contents will be a cfinclude with a relative path to the actual custom tag
>file.  works like it's in the same directory but you can keep them all in
>one place and use them in more than one directory with no maintenance
>issues.

Umm, I think I'd rather stick to cfmodule!

>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: Regardless, its structure (bad choice of word, sorry) it
>: smells of early HTML standards where not enough
>: thought went into naming conventions.
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>i'm not sure i see your point here.  combing through my cf book, i'm not
>finding anything that isn't self-explanatory as to it's purpose simply from
>it's name, whether it be a tag, a scoping variable, a function, you name it.
>can you give some examples?

For example, the <cfparam> means one thing, <cfmailparam> quite 
another.  I'm not sure why they decided to call it cfmailparam.  They are 
on different sides of the fence in terms of whether a parameter is being 
passed or received.

And the dot notation thing.. I would be interested to see a very early 
version of CF. I suspect structures were left out originally, and the dots 
being allowed in variable names is a backwards compatibility thing.

>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>: 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.
>:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>you've just explained why there isn't a single language that was developed
>in the last 5 or so years that you would be happy with.  rather unfair to
>compare such development time disparate languages don't you think?

Yes, entirely.

Just because I criticise something doesn't mean I can't see the reasons it 
is the way it is.

>: 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.
>again, same comment about development time as above.  now - show me any
>other language with roughly the same length of development time and i'm
>confident you won't be able to say the same thing.

I've found PHP's documentation a relatively more helpful.  It's had a 
similar (if not shorter) gestation period.  Quite a different approach 
though - where the docs lack, the user annotations fill in the gaps.

Oliver.

____________________________________________________
     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