Dynamically creating a CF Tag

[NoonEclipse]

Greetings,

I would like to dynamically determine what attributes are present in a ColdFusion tag. I have done the following to test the theory:

<cfset inputAttr['name'] = "tControlName">
<cfset inputAttr.label = "Control Label">
<cfset inputAttr.value = "Some string value">
<cfset inputAttr.type = "text">

<cfform name="fTest" method="post" action="">
<cfset tagAttr = "<cfinput ">
<cfloop collection=#inputAttr# item="attr">
<cfset tagAttr = '#tagAttr# #attr#="#inputAttr[attr]#"'>
</cfloop>
<cfset tagAttr = "#tagAttr# >">
<cfoutput>#tagAttr#</cfoutput>
</cfform>

If I look at the source for the page it is correct, but no input is creates. If however I change it to "<input" instead of <cfinput" it works fine. Unfortunately I would like to use attributes like validate that are only available in <cfinput>.

I assume that the stuff within the <cfoutput> tags are bding sent directly to the browser and bypassing the processing be CF. So I have tried leaving out the "<cfinput " and ">" from the tagAttr and using the following:

<cfinput "#tagAttr#" >

in a variety of forms but keep getting an error of one sort or another.

Am I missing something or is this not possible?

Thanks for your help.

[Newsgroup_User]

Am I missing something or is this not possible?

Thanks for your help.

What you are attempting to do is very unnatural. Why it works with
<input...> is that is HTML, and what CFML does is create HTML, or
JavaScript, or CSS, or other CLIENT side technologies.

You are attempting to create CMFL. This is not a very native thing to
do. One way I have seen it successfully attempted is to create the
entire <cfinput ...> tag as a string, write that string to a file and
then <cfinclude...> that file later on for processing.

But one really has to question the requirements when something like this
is attempted. What is the purpose? Maybe there is a better way to
accomplish the requirement that is not so klugy sounding.

[NoonEclipse]

Thanks for your input.

It does seem to be unnatural in CF, and I will probably abandon this approach.

There is a reason for doing it. It may not be as important in CF as other technologies. The intent is to minimize the number of times I have to enter certain infomation. For example, I can declare the form control name, the label, the database column, and other information in one place. Then when I create the form, I can have a function that takes the information and creates the control. When the form is submitted, it uses the same control name and knows the database column so can store the data in the db, or retrieve it from the db. This has saved me a huge amount of time using other technologies.

For example there might be 10 statement required to test that a sql query was successful. That all goes in one function, which can be done in CF. But I still have to remember the control name and the column name, and type them correctly every time I use them, and make the proper conversions. In the past 5 years my memory has deteriorated and I make more errors. And some times it isn't easy to figure out where the error is - script,. JavaScript, sql, or html?

It is true that CF makes it easier to do some of the tasks that I did using objects in other technologies, so I may not save as much time. For example CF generates JS validation code. One less thing for me to worry about. But it is still boring to write another sql insert or update statement.

I am looking at other alternatives to accomplish the goal in CF.

Thanks again for your help.

[Dan_Bracuk]

Try this:

<cfset x = 'value="Dan is smart"'>
<cfform>
<cfinput #x#>
</cfform>

If that works, apply the same concept to what you are really trying to to.

[NoonEclipse]

Thanks for the suggestion Dan.

It was one of the first things I tried. It gives the following error:

<b>Invalid CFML construct found on line 57 at column 18.
ColdFusion was looking at the following text:

#

The CFML compiler was processing:

* a cfinput tag beginning on line 57, column 10.

</b>

Thanks agian for your help.

[Dan_Bracuk]

Put it in quotes.

[NoonEclipse]

Thanks you once again Dan.

That was the second thing I tried. It gave the following error:

Invalid token '"' found on line 57 at column 18.

That was when I started making more complicated statements.

Thanks again for the suggestion.

[Newsgroup_User]

There is a reason for doing it. It may not be as important in CF as
other technologies. The intent is to minimize the number of times I
have to enter certain infomation. For example, I can declare the form
control name, the label, the database column, and other information in
one place. Then when I create the form, I can have a function that
takes the information and creates the control. When the form is
submitted, it uses the same control name and knows the database column
so can store the data in the db, or retrieve it from the db. This has
saved me a huge amount of time using other technologies.

This can be done in CF as well. Custom tags and Components come to
mind. But <cfinput ...> in essance already is a control. It creates
blocks of JS and HTML in the output returned to the client.

You are trying to create on the fly CFML and run it at the same time.
Honestly I don't know how to do this in ANY language. If you can show
me some Java, JavaScript, VB or any syntax that creates a line of code
and then runs that line of code, it can probably be done in CF.

[Newsgroup_User]

> <cfset x = 'value="Dan is smart"'>
> <cfform>
> <cfinput #x#>
> </cfform>

Unfortunately Dan is not as smart as he'd have us believe (you left
yourself open for that one, mate).

This won't work for the reason Ian stated: you cannot USE CF code to create
more CF code within the same file.

It's nonsensical, if you stop to think about it. CF does not read the file
in line by line, so you cannot have CFML on line 10 of a file which creates
more code on line 15 which you somehow expect to execute simply because you
output it. Remember: CFML files get COMPILED before they're executed for
one thing. So how can you create code at run-time which needed to already
be there at compile-time to get compiled so it can then be run? Short of
having some sort of CFML Tardis, that is.

Even if that would work, how would you expect just OUTPUTTING something
that looks like code to actually be compiled and then run?

So, yeah: nonsensical.

If you MUST do this, then you have to do what he said: write the CFML to a
FILE, and then <cfinclude> the file.

--
Adam

[NoonEclipse]

Thank you Adam for your comments. I understand what you are saying. But , I believe the following line of code is valid:

<cfinput name="#name#" value="#someValue#">

So how different is it to want to specify the what attributes you might like on the fly?

In the end, it may not be possible. In which case I will take a different approach. But perhaps there is someone out there that can see something I am missing.

[Newsgroup_User]

> Thank you Adam for your comments. I understand what you are saying.

To be frank, I'm not sure that you do. You're misunderstanding a pretty
fundamental way of how compiled(*) programming languages work.


> <cfinput name="#name#" value="#someValue#">
>
> So how different is it to want to specify the what attributes you might like
> on the fly?

But that's not what you're trying to do. You're trying to build the *CFML
statement* at runtime.

The CFML compiler needs a minimum set of rules that it has to be able to
work out how to compile something, and it needs more than just the tag
name. If you read the docs for <cfinput>, you'll see that it requires some
(but not all) of a whole swag of parameters. The parameter VALUES can be
set at runtime, but the parameters themselves are required for the
compilation process to work out what to do ("ah, it's got a 'required'
parameter... I need to call the methods which handle that...', etc). And
which parameters to use need to already be set at compile time, so you
*cannot use runtime values*.

What you're wanting *could* be possible in a theoretical world in which all
CFML tags acted like <cfinvoke>, which takes an argumentCollection
parameter. But note that even then, that cannot contain the native CFML
parameters (component, method, returnvariable or whatever they are), they
are simply the payload for the underlying method call. So in this
theoretical world you could have this:

<cfset stArgs = structNew()>
<cfset stArgs.name = variables.name>
<cfset stArgs.value = variables."#someValue#">
<cfinput argumentcollection="#stArgs#">

But we don't live in that theoretical world. We live in this one, and CF
hasn't been written like that. I presume it would be so dog slow to
accommodate that sort of thing, and there's more expedient ways to skin
that particular cat anyhow, so it's not really necessary.


> In the end, it may not be possible.

It's not: that's why I said "it's not possible". Trust me.



--
Adam

(*) yes, I know in the strictest sense of the term, CFML is not *compiled*,
as in "no a binary", but that's an out of date definition of the
compilation process

[NoonEclipse]

Thank you once again Adam.

You may or may not know what you are talking about. I have been dealing with computers and programming for 40 years. And for you to rudely say that I don't understand what you are saying is just plain arrogant.

Yes there is a difference between generating html on the fly and cfml on the fly. I certainly don't know CF to the point of knowing exactly what it is doing. However, I have worked with enough different languages to understand how many of them work. But I have worked with languages that can alter function calls on the fly. (And I am not talking about altering arguments or parameters). But then maybe I am just a dinosaur that shouldn't be trying to work with new languages.

If I should post anything else to this forum I would appreciate it if you did not bother to post any replies to it as I find you unnecessarily rude.

[Newsgroup_User]

> You may or may not know what you are talking about. I have been dealing with
> computers and programming for 40 years. And for you to rudely say that I don't
> understand what you are saying is just plain arrogant.

Well we can agree to have divergent opinions on that one. I don't think
what I said was rude at all, I was stating my perception of the situation.
That you might not have liked it said about you is an entirely different
thing, but it still doesn't make it rude.

You stated you understood what I was saying, but then continued a line of
"wonderment" (to use a BKBKism) which demonstrated you DIDN'T quite get it,
as if you did you'd not still be wondering along the lines you were. Is
that an incorrect assessment of the situation?


> how many of them work. But I have worked with languages that can alter
> function calls on the fly.

Compiled languages? Could you pls let me know which languages can do that,
and if you have time, dig out some example code of it happening? I'd like
to try to get my brain around that one.

(I'm not taking the piss when I ask that).


> If I should post anything else to this forum I would appreciate it if you did
> not bother to post any replies to it as I find you unnecessarily rude.

I think you should not cut your nose off to spite your face, but I will
take it under advisement. I don't pay a great deal of attention to WHO is
asking the questions, to be honest: if I can answer them, I just do (answer
them, that is). Feel free to ignore me should I accidentally respond to
another one of your issues.

--
Adam

[NoonEclipse]

The language was an obscure one I used in the 70s that is no longer around, and rightly so. It had some problems.

I have also written some functions to which I could pass arguments that contained the name and the value. The function could then parse the infromation and work with it. Of course that is not exactly the same thing either, as it code is not being compiled.

As to exploring options, I find it a good way of learning. I have read a number of tomes on programming where the authors had no clue about how to use the language to its fullest. Or even to a reasonable point. The structure of their code was appalling. Who would recommend writing a function that had 400 lines of code? And then copy it and do a cut and past to do a second page?

I have also worked on other peoples code that had a 700 line function that had 4 blocks of code that were (almost) identical. After spending 2 weeks trying to figure out what the code was supposed to be doing, I determined the the blocks of code should have been the same. Apparently he found a problem in one block and fixed it, then found it in a second block and fixed it differently. This programmer thought he was writing reusable code! Of course we also had an argument about calling an error in a program a bug. (I settled that argument several weeks later when I found him using the debugger. If he didn't have a bug he didn't need to use a debugger.)

I have found beating around the bush helpful at times. If you only go directly to the point, you don't always really understand the point. If you beat around the bush, it helps you to understand what isn't the point, which better defines the point. And sometimes you find that what you thought was the point wasn't. So I keep an open mind.

In the current instance, exploring this approach, which works in other languages, has helped me to learn more of the details of what CF is doing and how it works, which I would not have learned had I not explored it. It also helps me to understand how to structure code in CF. The important lessons are that I will now remember that <cfoutput> sends information to the browser not to the CF server for processing; that CF converts everything to html; that <cfinput> does not get sent to the browser, but is converted to <input> with other information with it. So it was worth it to me to spend a few hours investigating this line of thought.

As to your being rude. Perhaps it is just a difference of how you phrase things, or how they come across in writing. Or the difference between American, English and Australian. They are not the same language. When spoken, I can tell that someone is from Oz and put in a filter that interprets the language differently. That is not so simple in written communication.

In any event, thank you again for you <input>. It has been informative.

[Newsgroup_User]

> I have also written some functions to which I could pass arguments that
> contained the name and the value. The function could then parse the
> infromation and work with it. Of course that is not exactly the same thing
> either, as it code is not being compiled.

If I understand you correctly, you can do a similar sort of thing in CF as
per what I touched on with <cfinvoke argumentCollection="#stArgs#">. In
which the "real" argument is actually the collection, and the other ones
are just "treated" as arguments as part of the compilation process.

In one of the previous CF betas I did lobby for this to be the approach for
all CF tags. I'm not sure if it got addressed as an issue.

As some background, the reason why I lobbied for it was for the exact
reason you have raised: <cfinput>, and doing pretty much what you're trying
to do. I've since worked around it.


One thing you could look @ for these dynamic runtime forms is to have a
gander @ the various CF frameworks out there. You'll probably find the
work's already been done for you. And at the very least you can dissect
the code and see how they've done it.


> As to exploring options, I find it a good way of learning.

No disagreement there. Glad you actually seem to WANT to learn. A lot of
people here don't seem to.


> I have read a
> number of tomes on programming where the authors had no clue [...]

Yes. I'm reading a book that is like that (in peripheral places) at
present. And there is a lot of shite code out there. Then again... look
at your own old code. You probably see a lot of shite there too. I
certainly do when I look @ MY old code (and, cough, some of my new code
too!).


> better defines the point. And sometimes you find that what you thought was the
> point wasn't. So I keep an open mind.

Good thinking. And hence you have situations as per this thread in which
Ian asked what you were actually trying to achieve, as perhaps what you
were asking was not the best question.


> that I will now remember that <cfoutput> sends information to the browser not
> to the CF server for processing; that CF converts everything to html; that

Pretty much. It more sends it to "STDOUT", if I can borrow and absuse a
*nix term... in this case STDOUT generally being the HTTP response, which
finds its way back to a client browser. But that's just *in general*: the
data that CF generates does not need to be text, let alone HTML, and it
does not have to be send to the HTTP response. Indeed it doesn't have to
generate ANYTHING.

Ian touched on the notion of writing your CFML code to a string and then
writing it to a file. There's not response or browser or HTML involved in
that.


> <cfinput> does not get sent to the browser, but is converted to <input> with
> other information with it. So it was worth it to me to spend a few hours
> investigating this line of thought.

Well that's something!


> As to your being rude. Perhaps it is just a difference of how you phrase
> things,

Well I do have a tendency to call a spade a f***ing spade. And then -
sometimes - proceed to hit the person I'm talking to with it.

:-)


> or how they come across in writing. Or the difference between
> American, English and Australian.

Blimin' heck. I hope you're not accusing me of being Australian. That's
not on at all.

--
Adam
(Kiwi)

[NoonEclipse]

Hi Adam,

If I understand you correctly, you can do a similar sort of thing in CF as
per what I touched on with <cfinvoke argumentCollection="#stArgs#">. In
which the "real" argument is actually the collection, and the other ones
are just "treated" as arguments as part of the compilation process.

That is true.

In one of the previous CF betas I did lobby for this to be the approach for
all CF tags. I'm not sure if it got addressed as an issue.

As some background, the reason why I lobbied for it was for the exact
reason you have raised: <cfinput>, and doing pretty much what you're trying
to do. I've since worked around it.

Exactly. So I wasn't so far off in what I wanted to do. From the snippet I included you could see where I was going. Which is something that you had tried to do as well. So had you said this, I would have understood immediately you knew where I was going, that you had been down that path and that it was a dead end. Mind you, then I would not have meandered about for another couple of hours learning interest things.

One thing you could look @ for these dynamic runtime forms is to have a
gander @ the various CF frameworks out there. You'll probably find the
work's already been done for you. And at the very least you can dissect
the code and see how they've done it.

Will do.

Glad you actually seem to WANT to learn. A lot of
people here don't seem to.

Too true.

Yes. I'm reading a book that is like that (in peripheral places) at
present. And there is a lot of shite code out there. Then again... look
at your own old code. You probably see a lot of shite there too. I
certainly do when I look @ MY old code (and, cough, some of my new code
too!).

Too true. Yes my early code was not as good as today. But the tools were not as good as today. (Not that there aren't problems with the tools today. Some have just too much useless stuff that is overkill. Who can learn the 10,000 classes available in .NET?) And I always look at the code i've written, and not where it wasn't very good and how it could have been done better. And then I apply it to the next project.

Then too, I have written some strange code that works and saves time, but was kluged to get around short comings in the language. (That language now allows me to do what I wanted without the work arounds.)

Good thinking. And hence you have situations as per this thread in which
Ian asked what you were actually trying to achieve, as perhaps what you
were asking was not the best question.

Pretty much. It more sends it to "STDOUT", if I can borrow and absuse a
*nix term... in this case STDOUT generally being the HTTP response, which
finds its way back to a client browser. But that's just *in general*: the
data that CF generates does not need to be text, let alone HTML, and it
does not have to be send to the HTTP response. Indeed it doesn't have to
generate ANYTHING.

Agreed. Pardon me for being less than precise.


Ian touched on the notion of writing your CFML code to a string and then
writing it to a file. There's not response or browser or HTML involved in
that.

But it is not elegant and maybe not efficient. Unless one writes out the whole form to one file and then loads it. Hmmm. But not really a good answer I think.


Well I do have a tendency to call a spade a f***ing spade. And then -
sometimes - proceed to hit the person I'm talking to with it.

That's a good description. And I have been there too. But I got away from it, and try to make comments in a positive way. Which has its own problems.

Blimin' heck. I hope you're not accusing me of being Australian. That's
not on at all.

Never! I had intended to include NZ, but it dropped out of my mind. At least I didn't think you were English. (My wife is.) NZ is nice. I have visited Christchurch and Marlborough. And a very brief time in Nelson (I think. I drove from Marlborough to Nelson and flew to Auckland and then back to States.)

Okay. So in the future you can reply to my posts. And I will keep it in mind that you are a Kiwi and filter things appropriately.

[NoonEclipse]

So I was wandering down other paths developing some components to facilitate various functions, when a brick hit me in the head. I wrote the following code:

<cfscript>
inputAttr['value'] = "Some string value";
inputAttr['type'] = "text";
tagAttr = 'tControlName';
</cfscript>
<cfform name="fTest" method="post" action="">
<cfloop collection=#inputAttr# item="attr">
<cfset tagAttr = '#tagAttr#" #attr#="#inputAttr[attr]#'>
</cfloop>
<cfset tagAttr = '#tagAttr#"'>
<cfoutput>#tagAttr#<br /></cfoutput>
<cfinput name="#tagAttr#" />
</cfform>

And lo and behold, it worked.


I am not sure that I will use it. BUT IT WORKS!

[Newsgroup_User]

> And lo and behold, it worked.
>

Well it *kinda* works. The resultant <input> tag is malformed:

<input name="tControlName" type="text" value="Some string value""
id="tControlName" type="text" value="Some string value"" type="text" />

Note the double up of a couple of the double-quotes, which means there is
this bit in the middle of your tag - " id="tControlName" type="text"
value="Some string value"" - which invalidates the mark-up.

If you look at what <cfinput> is doing, it makes a matching NAME and ID
attribute for the <input> out of the NAME attribute of the <cfinput>

So you end up with:

<input
name="
tControlName" type="text" value="Some string value"
"
id="
tControlName" type="text" value="Some string value"
"
/>

Which results in the double-up of attributes, as well as the incorrect
usage of double-quotes. Both these invalidate the tag. I'm actually
surprised it renders. Browsers are forgiving these days. I wonder what
Opera would make of it (as I believe it's a bit less forgiving than IE or
Firefox).


However you CAN achieve a working example of this by "spoofing" one of the
other attributes of <cfinput>, as this example demonstrates:

<cfset spoofSize='40" maxlength="10" value="fieldValue" tabindex="1'>
<cfform name="fTest" method="post" action="">
<cfinput name="formField" size="#spoofSize#" />
</cfform>

So you end up with this:

<input
name="formField"
id="formField"
type="text"
size="
40" maxlength="10" value="fieldValue" tabindex="1
"
/>

This parses as valid HTML.

However this all is no help to you. You were wanting to dynamically set
the specific <cfinput> attributes weren't you (which effect validation and
that sort of carry-on)? Not the basic HTML attributes which are simply
passed-through. If you just wanted to do this with the HTML attributes,
there's not need to be using <cfinput>, and indeed you could dynamically
build your <input> tag thus:

<cfset otherAttributes='size="40" maxlength="10" value="fieldValue"
tabindex="1"'>
<cfoutput>
<input name="formField" id="formField" type="text" #otherAttributes# />
</cfoutput>

This outputs:

<input name="formField" id="formField" type="text" size="40" maxlength="10"
value="fieldValue" tabindex="1" />

You CANNOT spoof <cfinput>-specific attributes such as "required", "mask",
"validate", etc. They'll simply get treated as "noise", and passed through
to STDOUT (to re-use yesterday's euphemism).

Make sense?

--
Adam

[NoonEclipse]

You are correct. I did not check the details. However, I added an id attribute

<cfinput id="someID" name="#tagAttr#" />

which generated the following code:

<input name="tControlName" type="text" value="Some string value" type="text" id="someID" />

So it can work. I am feeling a little rough today so wasn't very careful about checking this out before I posted the forum. I would also take time to test all of the attributes to verify there are not some other anomolies. But by and large I think it is interesting.

I don't thinkit would be difficult for Adobe to make a change to the tag to allow it to accept a garbage collection (uh attribute collection) like you had suggested.

Cheers

[NoonEclipse]

Adam,

Somehow I missed most of your post yesterday. You are absolutely correct. You really know what CF is doing. I am slowly learning.

Thanks for your help.

[BKBK]

> <cfset x = 'value="Dan is smart"'>
> <cfform>
> <cfinput #x#>
> </cfform>
Unfortunately Dan is not as smart as he'd have us believe (you left
yourself open for that one, mate).

Not quite. You could only say because you left out Dan's "Try this:", which declares a venture into the unknown, and "If that works", which tells us Dan is putting forward a hypothesis.

He is well and truly covered. In any case, this forum is not just a place to declare, state and propound, it is also a place to wonder.

[Newsgroup_User]

> Not quite. You could only say because you left out Dan's "Try this:",

Yes, but the OP should NOT have tried that, because it clearly didn't work,
which Dan would have realised had he spent 5min investigating before
suggesting a nonsensical course of action.


> which declares a venture into the unknown, and "If that works", which
> tells us Dan is putting forward a hypothesis.
>
> He is well and truly covered.

Well I don't think Dan's being particularly helpful with his habit of
suggesting things that are plain wrong and will not work.


> In any case, this forum is not just a place to
> declare, state and propound, it is also a place to wonder.

Oh *please*.

If there's any wonderment, then it should be on the part of the person
asking the question; not on the part of the person answering it. Unless
that wonderment is along the lines of "WTF are you on about?" which - I
concede - I do find myself wondering sometimes (although, I hasten to add,
not in this case, as the intent of the OP was clear).

--
Adam

[Newsgroup_User]

> If you can show
> me some Java, JavaScript, VB or any syntax that creates a line of code
> and then runs that line of code, it can probably be done in CF.

You actually CAN do it in JS:

<html>
<head>
<title>Change Me</title>
<script type="text/javascript">
function runTimeJs(){
var s = '<script type=\"text/javascript\">a'+'lert(\"Boo!\");
d'+'ocument.title=\"New Value\";' + '<'+ '/script>';
alert('writing: '+s);
document.write(s);
}
</script>
</head>
<body onload="runTimeJs()">

</body>
</html>


Note that the function body is just writing a string, the string being:
<script type="text/javascript">alert("Boo!"); document.title="New
Value";</script>

I've broken up the JS instructions in the string to demonstrate it's NOT
simply executing the code as it hits it... it's executing the STRING of
code, once it's written to the document.

--
Adam

[monkey_woo_too]

<cfform name="fTest" method="post" action="">
<cfset field = '<cfinput name="wiggy" id="wanky" required="true" />'>
<cf_saveandinclude>
<cfoutput>#field#</cfoutput>
</cf_saveandinclude>
</cfform>

saveandinclude.cfm

<cfif thisTag.executionMode IS "end">
<cfset filename = "#createuuid()#.cfm">
<cfset filepath = expandPath(filename)>
<cffile action="write" file="#filepath#" output="#thisTag.GeneratedContent#">
<cfinclude template="#filename#">
<cffile action="delete" file="#filepath#">
</cfif>

[NoonEclipse]

Thanks Monkey Woo Too,

That is a nice simple solution. Is the file access going to greatly affect the performance? I would call this for each field on the form. There could be 10 or more fields. I could modify the code perhaps to have a tag open the file, a second tab to write to the file, and a third to close, include and delete the file. That might be more efficient.