ColdFusion Sneak Peak
So I just sat through the ColdFusion sneak peak at MAX, and it was done really fast, so forgive me if I get a few details wrong. The demo involved moving from a CF-based Ajax app to an AIR application. If I saw right, he began by adding a <cfairaccess& tag, and then set a property to CFGRID to mark it as available offline. He views the page in the browser and saves the result as an HTML file. He then uses the normal AIR compiling tools (from what I can tell) to generate an AIR app. It works. Ok - no big surprise there since CF generates HTML, but it is kind of nice as he is now browsing his data in the AIR app.
He then demonstrates how he could add two buttons to set the application in online/offline mode. He showed how the old code uses ColdFusion.Ajax.submitFormat and switched it to ColdFusion.air.submitForm(). He did the trick of save as/AIR compile again and this time the result application was able to detect when the application was offline. He could send mail in offline mode - go online - and see it processed.
It was rather quick and I'm missing a few details (Adobe, consider this your invitation to add details ;) but was really interesting!
Comments
I briefly spoke with Ben and they're still months out from letting testing out internally. There seems to be a 2-3 year cycle between releases so my best GUESS would be we could see CF9 as early as 2009 and as late as 2010. CF9 in 2009 just works so well....
# Posted By Rick Smith
| 10/2/07 10:14 PM
Really needs to be 2 years, as that is how they sell their subs to CF and this used to (Not read it for a while) Says you will get one major upgrade in that time, else there is no point in buying it.
# Posted By Big Mad Kev
| 10/3/07 2:13 AM
There are new things with the subscriptions which mean you ca buy a year at a time or more years if you want. At least thats how it looks now from the UK price list.
# Posted By Kevin Roche
| 10/3/07 3:02 AM
It would be unfortunate if we had to wait until 2009 to get tighter AIR integration with ColdFusion. I think this needs to be released in 2008 to keep us developers happy!
# Posted By Mark Mazelin
| 10/3/07 9:10 AM
Charlie made an interesting comment on Ben's blog. Its like we all keep thinking the next version of CF has to be version 9. Don't forget there was a CF 4.5, CF 6.1... how about a CF 8.5?
This is about pushing AIR also... it would be a shame to let standard dev cycles trump market opportunities! (IMO)
The bigger issue is the need for more robust libraries. Adobe needs to let us create "plugin" form and web object libraries. (Perhaps I am just thrilled wiht CFTags again building COOP... but this could be done so easy.) They also NEED to add setting mappings at application level rather than just at the top of the page if at all possible. Mapping that is in the scheme of CFImport.
This is about pushing AIR also... it would be a shame to let standard dev cycles trump market opportunities! (IMO)
The bigger issue is the need for more robust libraries. Adobe needs to let us create "plugin" form and web object libraries. (Perhaps I am just thrilled wiht CFTags again building COOP... but this could be done so easy.) They also NEED to add setting mappings at application level rather than just at the top of the page if at all possible. Mapping that is in the scheme of CFImport.
# Posted By John Farrar
| 10/3/07 12:19 PM
John - not sure what you mean about setting mappings at the app level. You _can_ do that in CF8 in the App.cfc file.
# Posted By Raymond Camden
| 10/3/07 1:24 PM
You skipped my presentation after you got your pie or you would know! lol
<cfimport prefix="myPrefix" ...>
<myPrefix:myTag ...>
Mapped prefixes. When you map CFC directories that is fine. You could use CFModule... but that is the ugliest way to write code! And CFModule doesn't behave strictly identical to calling the code as <cf_myTag ...> would work. Using the prefix is more elegant and the way to go.
Now... please tell me that I am wrong and you can use a prefix set in application.cfc and dinner will be on me. (Something slightly better than Burger King... but it's a meal just the same!)
<cfimport prefix="myPrefix" ...>
<myPrefix:myTag ...>
Mapped prefixes. When you map CFC directories that is fine. You could use CFModule... but that is the ugliest way to write code! And CFModule doesn't behave strictly identical to calling the code as <cf_myTag ...> would work. Using the prefix is more elegant and the way to go.
Now... please tell me that I am wrong and you can use a prefix set in application.cfc and dinner will be on me. (Something slightly better than Burger King... but it's a meal just the same!)
# Posted By John Farrar
| 10/3/07 4:17 PM
John:
First off, you are wrong. cfmodule acts the same as cf_mytag. There is zero difference.
As for it being more elegant, yes, cf_mytag is shorter, but I use cfmodule for most of my code so it is more portable. For cf8 though I plan to revert back to cf_mytag.
Now - if you are asking about being able to do cfimport in app.cfc - no - you can't. cfimports must be on the page that uses them.
First off, you are wrong. cfmodule acts the same as cf_mytag. There is zero difference.
As for it being more elegant, yes, cf_mytag is shorter, but I use cfmodule for most of my code so it is more portable. For cf8 though I plan to revert back to cf_mytag.
Now - if you are asking about being able to do cfimport in app.cfc - no - you can't. cfimports must be on the page that uses them.
# Posted By Raymond Camden
| 10/3/07 5:13 PM
Ray... if I can show you something above zero difference will you donate a CFUnited Ticket for me to give away at my user group for 2008? :) (Hint: It is more than you will agree with me as a difference.) Let me answer before you goof and take the wager!
1. If you use custom tag paths the first time that tag is found it will run the tag. This is only an issue if you like a member of our user group had someone else on the same shared hosting server with an older version of the same custom tag. (Not to mention that with multiple custom tag paths you could actually do it on your own server also.) This would not happen with CFModule.
2. Before CF8 you had an issue that the "name" attribute was the name of the custom tag. This means that you could not pass the name attribute to a CFModule request as an attribute. Name is actually a pretty common attribute.
So... you are mostly right. I used to use CFModule also. But as a matter of "personal taste" the tag library approach is just the way for me to go. I think the elegant code would catch on fast IF it were something we can set at the application level.
Curiosity... why are you reverting to the original custom tag syntax? I would like to glean any perspective you have on the topic.
1. If you use custom tag paths the first time that tag is found it will run the tag. This is only an issue if you like a member of our user group had someone else on the same shared hosting server with an older version of the same custom tag. (Not to mention that with multiple custom tag paths you could actually do it on your own server also.) This would not happen with CFModule.
2. Before CF8 you had an issue that the "name" attribute was the name of the custom tag. This means that you could not pass the name attribute to a CFModule request as an attribute. Name is actually a pretty common attribute.
So... you are mostly right. I used to use CFModule also. But as a matter of "personal taste" the tag library approach is just the way for me to go. I think the elegant code would catch on fast IF it were something we can set at the application level.
Curiosity... why are you reverting to the original custom tag syntax? I would like to glean any perspective you have on the topic.
# Posted By John Farrar
| 10/3/07 6:47 PM
1) This refers to how tags are found. I don't think it is fair to say it reflects a change in behavior from cf_ to cfmodule. But - it does argue for using cfmodule OVER cf_, as you don't have to worry about 'what will CF find'
2) Ok, not being able to use name is one small point. What I do normally in tags that desire a name attribute is to add a copy, like fooname, so my custom tag can take either.
3) I can return to cf_ syntax since cf8 will let you specifically say where my custom tag paths are.
2) Ok, not being able to use name is one small point. What I do normally in tags that desire a name attribute is to add a copy, like fooname, so my custom tag can take either.
3) I can return to cf_ syntax since cf8 will let you specifically say where my custom tag paths are.
# Posted By Raymond Camden
| 10/4/07 9:09 AM
The only problem I see with CF_MyTag is that in public libraries version control for what other developers might have on a shared server can be risky. It's a point of failure. Now for a controlled environment this is fine. Our focus in what my company is building and sharing is just that... shared. Using a "tag library" enables us to safely control common calling code even on shared hosting servers.
I also agree this is a minor step that has to be repeated for every page by including CFImport calls. It would be great if we could append this functionality to being an application level tag library. Otherwise on a controlled server the CF_ method is the simplest. I am just paranoid about process integrity where the solutions get deployed on shared hosting severs also.
I also agree this is a minor step that has to be repeated for every page by including CFImport calls. It would be great if we could append this functionality to being an application level tag library. Otherwise on a controlled server the CF_ method is the simplest. I am just paranoid about process integrity where the solutions get deployed on shared hosting severs also.
# Posted By John Farrar
| 10/4/07 9:22 AM
Was there a function in CF8 that kept users from re-submitting a form?
I remember seeing this at MAX 2007, just not sure if it was in a session or a keynote.
I remember seeing this at MAX 2007, just not sure if it was in a session or a keynote.
# Posted By Amy
| 10/16/07 11:47 AM
CF7 added this - if you use the CFFORM framework.
# Posted By Raymond Camden
| 10/16/07 11:52 AM
If using cfform do this:
cfinput type="submit" validate="submitOnce" name="sub" id="sub" value="Submit Once"
cfinput type="submit" validate="submitOnce" name="sub" id="sub" value="Submit Once"
# Posted By Sam Farmer
| 10/16/07 12:00 PM
Thanks Sam! That's it!
# Posted By Amy
| 10/16/07 12:53 PM
Was there any word on when would this be available?