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

[Jeff]

<ol>,

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: From: Oliver Lineham <oliver at lineham.co.nz>
:
: Ah. I see.  You have to StructNew() everything.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.
however, these are individual variables, not keys in a structure.  without
initializing them, notice that even within the same template you can't do
cool things with the struct functions below.

IsStruct(structure)
StructClear(structure)
StructCount(structure)
StructCopy(structure)
StructDelete(structure)
StructFind(structure)
StructInsert(structure)
StructIsEmpty(structure)
StructKeyArray(structure)
StructKeyExists(structure)
StructKeyList(structure)
StructUpdate(structure)

in fact, take one of you dot notation variables and do an IsStruct() on it
and see what the cold fusion server returns.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: >(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,
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ah, i see that you were talking specifically about how the special
attribute, attributescollection, works (or rather doesn't work).

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.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

i would imagine that it would be useful where you were holding all your data
within a structure and had a custom tag that acted solely upon that
structure, possibly sorting it, creating a new query from it, etc.  i agree
that it doesn't seem incredibly useful or intuitive.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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?

the solution i posted above was necessary to copy a query into a custom tag.
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.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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>
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

it saves many lines of code, but at the expense of a list loop - a costly
operation.  furthermore, why are you even bothering with altering form data
when paraming it?  the only time that you should be concerned with trimming
is validation (a given) and when you put it into the database
(insert/update, also a given).  other than that i'd just leave them alone.
cfparam them with their defaults (most likely empty strings) and then don't
touch them until it's time to do one of the aforementioned tasks.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

true.  that's because the dot notation doesn't truly create a structure.  a
structure is only truly created when you initialize it with StructNew()

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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?

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 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?

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: >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.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

hope this has cleared up some concerns and questions you may have.

good luck,

.jeff

name://jeff.howden
game://web.development
http://www.evolt.org/
mailto:jeff at members.evolt.org