Tag: ColdFusion

Those of you that have heard me talk at User Group tour talks, or at yesterday’s Online ColdFusion Meetup have heard me use the phrase “RAD without Rules.” It’s been going through my mind ever since I started using ColdFusion Builder and ColdFusion 9 together.

You see, ColdFusion was built as a Rapid Application Development tool for the web and for many of us it was alone in that space. However, it would be disingenuous of me to not acknowledge that there are tools that have stolen the spotlight away from ColdFusion. For me, this release of ColdFusion is about getting that spotlight back.

I was thinking about the phrase “convention over configuration” which seems to be the prevailing philosophy behind other RAD tools, like Ruby on Rails, Grails, Zend, etc. To me it means, “Code the way we tell you to, and we’ll make it fast.” It’s hard to tell tone here, but I’m not trying to knock this. A lot of smart people have done some awesome work with this mindset.

However, it never really fit with me, both when I was using frameworks and when I was writing them. People almost always chafe at the conventions. People always think they themselves can do things better then someone else. Not just me, in this case, but the people I was trying to get to use conventions. Some of that thinking is misguided. Some of it is “Not Invented Here” thinking. But at the end of the day, you’re always going to be more productive using something you believe in, rather than something you’re somehow compelled to use.

This leads me to the features of ColdFusion 9 and ColdFusion Builder.

ColdFusion Builder comes with extensions that generate code for you. Want to quickly generate code for viewing information in your database? You can do that. Hate the code we generate? You can completely change it. It’s written in CFML, and completely visible/editable to you.

Want to quickly build a modern, responsive HTML UI? You can use our built in UI components. Want to hand-code your front end using a JavaScript framework? Here’s CFAjaxProxy and our JSON features from ColdFusion 8 for you.

Want to do your front end in Flex? You can have it faster. Want to use ColdFusion in Flex quickly? You can use Exposed Services.

Want to work with PDFs? You’ve had that. Want to work with Office files? Now you can do that too.

We’ve added Hibernate ORM to ColdFusion. Want to wire up an object model in ColdFusion, and just have the CFCs define the database? You can do that. Want to model an existing database ignoring its structure, and instead building proper objects regardless of underlying structure? Guess what? Doable. Want to just provide CRUD for your existing database without writing a lot of code? You can just leave your ORM CFCs blank, and we’ll take care of that for you.

Don’t like ORM? That’s fine, CFQuery isn’t going away. We’ve tweaked it a bit, to use the application.datasource by default. Also, the code generation tools we provide will generate CFQuery code for you instead of ORM code. Don’t like the code we generated… you should get the point by now.

The point being this: instead of saying “Code the way we tell you to and we’ll make it fast” ColdFusion is saying “Code the way you want, we’ll make it fast.” That is what I mean by RAD without Rules.”

 

I just got done with the longest (hyperbole), and highest attended (293) Online ColdFusion Meetup ever. Here’s the URL for the recording if you missed it.

https://admin.na3.acrobat.com/_a204547676/p53217737/

We’ve been promising this one for awhile, but today we deliver. We have released a public bug tracker for ColdFusion and ColdFusion Builder. Now you can track both your bug reports and enhancement requests. You will also be able to vote for other people’s bugs (or drum up support for yours.)

These will probably not be the final URLs for these trackers, but they’ll work in the meantime.

• ColdFusion 9
• ColdFusion Builder

We’d also like to thank the following developers for working so hard on it:

• Raymond Camden – http://www.coldfusionjedi.com/
• Brian Rinaldi – http://www.remotesynthesis.com/
• Anirudh Sasikumar – http://anirudhs.chaosnet.org/
• Sujit Reddy G – http://sujitreddyg.wordpress.com/

So the ColdFusion 9 public beta has been released, and now everyone can play with it. I’m excited to hear what the community as a whole has to say about it. One of my favorite features is ORM or Object Relational Mapping.

As I’ve been traveling around for the user group tour, I’ve heard a few questions about it, and I wanted to share these thoughts.

Are you forcing us to use ORM?

Absolutely not – cfquery and its related tags aren’t going away. ColdFusion is about making what you want to do easy. If you want to work with queries, work with queries–we’ve made it pretty easy, as I’ve said before. But a number of customers wanted to work with databases in an easier, object-oriented way. A lot of developer effort has gone into doing that with various ColdFusion Open Source projects. It makes sense then that we would strive to make this easy too. That’s “too” as in “also,” or “additionally,” or “alternatively.” Or in other words, if you think ORM might have value, use it; if not, keep working the way that works for you because you are not required to use it.

In fact, we were actually able to expand the features of cfquery when we added ORM. In order to use ORM you have to add a datasource to the This scope in your application.cfc. Well when you do that, any cfquery in that application without a datasource tag will use the application.datasource. Very cool.

Why do I have to set all of these properties? Can’t ColdFusion just look at the database and create an ORM object?

Yes it can. If you leave your CFC blank, ColdFusion will just map the table that you are pointing to, no questions asked. However, if you want to set any properties manually, you’ll have to set them all. So it’s good for simple prototyping, but if you need to do something more complex, you have to do the work yourself.

Why doesn’t ORM return ColdFusion queries?

Objects and tables don’t always match up. Queries are really good for exposing the results of a Select statement, but they aren’t designed to handle complex sets of data. (Which is different from saying they cannot handle results of complex SQL Select statements, because they can.)

Sometimes you’ve got complex relationships; sometimes you have tables that are set up for one purpose, but used for another; and sometimes you have multiple tables that really should be one object. Queries can certainly accommodate this, but ORM can often do it in a way that makes you more productive. What would be multiple queries that you have to manage and loop through to display using queries, becomes one object in ORM.

Now add to it that you can add business logic to these objects, things like calculations, display formatting, and combined properties… and ORM shows itself to be much more valuable than just another way of handling data.

Okay, and let’s say you REEEAAAAALLLLY want a query. Okay, you can run a function named EntityToQuery that will convert the results of an ORM operation to a query. (Provided that it’s a simple object, with no relationships or other funny business.) (Not valid in Australia, for people named Mark, with or without marsupial pouches.)

Where can I find out more about ORM in ColdFusion 9?

There are a few good blog posts and articles on the subject:

• Ben Forta’s ORM – Rethinking ColdFusion Database Integration
• Mark Mandel’s Introducing ORM in Adobe ColdFusion 9 beta
• What ColdFusion 9’s ORM means for your development

I’ll try to add them as I see them.

 

Just in case you haven’t seen it on Ray’s Blog, or Ben’s Blog, there is a patch and procedure to fix the FCKEditor ColdFusion 8 security bug.

A couple people have told me they had no idea how to report a security issue in ColdFusion. So I figured I would clear it up.

Normally when you have an enhancement request or a bug report, we direct you to the “Go/Wish” page. This is the page for all Adobe products. You choose ColdFusion from the product list and enter your request, which is then emailed out to the product team. (Soon there will be a more public version of this available for just ColdFusion.)

However, if you have a security issue, it makes more sense to report it to the Product Security Incident Response Team. Then the process is a little different. There is a lot more back and forth communication. The actual process is documented publicly. In any case there are two ways to report it:

• Fill out a Security Issue Report
• Or send an email to PSIRT@adobe.com

A number of questions have emerged from the ColdFusion community about the recent FCKEditor security vulnerability in ColdFusion. Hopefully this fills in more information for you.

Before I get into it though, let me just say that this isn’t an attempt to excuse the problems you’ve had. We know that you had a crappy week last week (or this week), and regret it. We do need to review what happened, and determine if we could have done this better. Personally, in hindsight, there’s one decision we should have gone another way on: we should have released the workaround sooner.

Is it true that Adobe had a fix for months and sat on it?

No, the issue was reported to us 7 weeks before exploits hit last week.

The workaround was pretty easy, why did it take you six weeks to come up with?

In this case, the issue was reported by a customer. The customer was not satisfied with just a workaround for several reasons including concern that we were not actually fixing the correct problem. (This concern ended up being true.) Additionally, our security people were also not entirely convinced that the workaround was entirely the right solution. (Although, I need to state here that the workaround that is now circulating does close the security hole.)

For those reasons, a hotfix was the preferred solution. A hotfix takes more time to create. We had to create the hotfix, then test it to make sure it didn’t break anything, and then provide it to the customer for their approval. We also had to communicate with the FCKEditor folks, to insure that we were correct in understanding their code. In short in addition to testing there was a lot of communication between many groups, and that burned up the time.

Now let me be clear here, I’m not casting blame on to the customer or any third party. Communication takes time, and in this case it took a fair amount of time. If you want to know more about this process it’s publicly documented on the PSIRT blog.

Why didn’t Adobe say anything at that time – the workaround was found pretty quickly?

If we acknowledged the security vulnerability and released the workaround we’d be leaving the reporting client in a lurch. There would be public knowledge of a vulnerability, but no acceptable solution for our customer (as they required the hotfix solution.) We made the call to make the fixes privately and announce when we had a solution we were confident in.

In this case it ended up biting us and you. We now know we should have released the workaround as soon as we knew about it.

But honestly I’m personally torn. On one hand, we should have told you guys sooner, as evidenced by the public exploits. On the other hand, we weren’t arbitrarily holding it back, or idly sitting around – the security group was trying to get a proper fix out before an attack occurred. I think we just got some bad luck.

I’m sure you have opinions on this. Feel free to let me have it in the comments.

Did the Adobe shutdown exacerbate this issue?

The security response process was already in progress. Our teams that work on patches were not off that week, so the actual fix was not delayed. The Adobe Security team responded within a day of the reported problem. So I’m not sure the shutdown had a large effect on our official responses.

If you have other questions, please feel free to ask them in the comments.