views:

329

answers:

6

I am a coldfusion programmer, and yes I know there are a lot of great coldfusion frameworks out there.

However because of the way the company I work for, code is styled and structured, I want to create a stepping stone framework, that gradually over time moves them to some current coding styles and standards..

But to get there, and our need for customizable design with consistent business logic and rules..

I need to slowly move them into a seperate of display and logic...

I have zero interest in any flame wars, of what framework to use etc etc...

What I am, are interested, in what are the most important features in creating your own web framework?

Here are some of my issues I hope to resolve:

  1. A Debugger/Server Monitor that works on dev and production, even thought we are using Coldfusion 8 Standard, on dev we can use the cf server monitor, but on production we can not. So I am looking to include some free or open source debugger/server monitor...

  2. I want to include a good cross-script protection, so that I can move us away from cfqueryparam, and allow us to use cachedwithin, since our version does not support cfqueryparam and caching in the query.

  3. Being able to switch styles, for pages, and/or change layout of content...I have done some work with Wordpress, and love it's theme framework, but hate it's performance/load time.

See I know that major redoing of a corporate site takes a long time, and prolly induces more bugs than then we want..

Which is why i want to create a framework, that in small steps allows us to keep current logic/functionality, but allows seperation of display and logic.

  1. Figuring out my folder/url structure that makes seo sense, and is human-readable, I have worked with Able Commerce in the past, and have hated it's url structure.

Sorry for the long-winded question, and I am not expecting you to do my work :) But some logical suggestions, pointers to good articles on creating frameworks...I have googled....

Thank You.

+7  A: 

Apart from the obligatory "You use coldfusion?!? ... ha" here you go:

  1. URL handling, turning /a/b/c into a call to your application
  2. Input (GET, POST, PUT, DEL) parsing into native structures
  3. Cookies and session management (SQL session storage / Dep-injected sessions / pluggable)
  4. Automagic service creation (RESTful/SOAPy) whatever

They would be my top 4. Then:

  1. MVC abstractions as core framework features (I know!)
  2. ORM (I hate it, but for little things it is alright)
  3. Automagic input validation, autofixups of controls to GET/POST/DEL
  4. Authentication mechanisms

Then if you are bored:

  1. CRM and templating

Of course, getting these things stable and scalable is probably not worth the time reinventing the wheel (and yes I have tried, and I still commit to that repo).

Don't bother unless you have some great new way of approaching it.

Aiden Bell
Why do you hate ORM?
Diadistis
I just don't think that the overhead can compete with hand-rolling. But for alot of things it is ok. I just dislike that it is sometimes the goto solution for people too lazy to think through database architecture.
Aiden Bell
I can't see how ORM frameworks reduce database architecture while I can clearly see how they minimize grunt work. And yes it's slower, but not as much as you may think :)
Diadistis
I will keep that in mind.
Aiden Bell
You shouldn't automatically parse PUT/DELETE. Good explanation: http://groups.google.com/group/django-developers/msg/b5a73fd98848ff9b
ShZ
@ShZ, I just ment plonking the key=>val data into an object. Not necessarily doing anything with it. You can do this on-demand however.
Aiden Bell
Ah, gotcha. Misunderstood that bullet point.
ShZ
What about my obligatory response? You have to insult and be rude to everyone who doesn't use what you use?
crosenblum
@crosenblum, have a sense of humour will you!
Aiden Bell
I do, but I try to accept it, but it get's tiring of people being rude or insulting of whatever technology I use. You could say something like, "I don't use coldfusion, but here's what I'd do." I mean do you really like it when people are constantly insulting/slamming whatever you are using?I am honestly sick of it...I'll be nice, but I don't think you know how rude a joke that really is..
crosenblum
@Aiden - You make some good points, other than the ignorant comment about CF of course. But as you actually knew how to spell it, I will let it slide .. this time ;)
Leigh
+3  A: 

My first thought is to do it over time and almost without intending to create a framework.

  • Look at what you repeat often and build wrappers for that.
  • Look at any patterns that you use and factor them in.
  • Look at any code generation that you want to use.

Build this up and then refine over many sites.

ridecar2
Isn't this how Django was created?
Hooray Im Helping
I'm not sure, but it is how Rails was done.
ridecar2
+1  A: 

I wrote my own CF framework as well. It was worth it because the framework does exactly what I want, how I want, and is very flexible. Here's what I recommend:

  • Create a UDF library so you can use CFScript wherever possible.
  • Have a debug template that pretty-prints all important data and queries at the bottom of every HTML response. I also use my debug template to email user-generated errors to myself with all relevant request, history and query data.
  • have a function that lets you do queries inside CFScript. Have companion functions to protect the string from SQL injection attacks (sample below).
  • Divide each request into an area and a path (eg. /area/path/to/template). This lets you do custom logic based on where in the site the user is. It's amazing how useful this locality information can be to customising a site.
  • Don't do like Mach-ii and setup the site in an XML file. Just put templates in the relevant place and load them from index.cfm based on the request.
  • On any page that uses more than a couple of lines of setup code put all the code in a seperate template and cfinclude it at the top of your page. This means you can give the page to a graphic designer with less risk of them screwing it up or getting lost.
  • Include the entire framework with every site. It's tempting to try and link individual sites to a common framework directory (ie, via symlinks, aliases or service calls) but in practice your framework will evolve along different paths as clients will want specific customisations that would break your other sites.
  • Always make simplicity paramount. You don't want to mangle the environment so much that you can't include templates from other projects (like the connectors that come with WYSIWYG editors). Your rule of thumb should be that another Coldfusion programmer could begin using your framework within an hour without you holding their hand.
  • Put ALL your framework variables into a single struct so you don't pollute your scopes with framework vars. It also helps other users know the difference between a framework variable and a template variable. I use fw.scope.varname for every single variable that will be visible from a page template (ie, request and variable scopes).
  • Use CFC's! I can't begin to tell you how much they assist in keeping your code organised. I generally instantiate all my CFC's at the start of every request so I can easily access their their members from CFScript using the form fw.mycfc.mymethod()

CFScript SQL function example:

sql("SELECT * FROM "#fsafe(this.table)#" WHERE "#fsafe(my.field)#"='#vsafe(my.value)#';", my.cache_mins);

Where fsafe protects table/field names and vsafe protects strings from SQL injection (by escaping double or single quotes)

SpliFF
Can you share any additional details about your ideas?
crosenblum
A: 

Firstly there are plenty of great, existing frameworks for ColdFusion. However, I do understand the desire to roll your own. I agree with some of the statements above where they talk about identifying what is important to you, and to keep it simple.

Having been in an organization that had no framework, and attempting to write one and slowly bring it to standard, be prepared for slowly to really mean SLOWLY. Adoption is not quick due to the fact that oftentimes large, older applications have TONS of existing business logic that can be difficult to separate out into "concerns", which is of course what most frameworks do well. I also found it challenging because most devs are too busy actually doing their day-to-day job, and have little time to learn something new, especially with looming deadlines.

Good luck in your efforts!

Adam Presley
Well said, and I agree, I know it's going to take time, to polish and refine the framework so it's easy to use/learn and does all the things I want it to do...Which is why I am doing a test-case on just doing 1 page for our site, then we can see pro's/cons..Thanks
crosenblum
A: 

Regarding #3, one of Coldfusion's strengths are Custom Tags which will work nicely for custom templates and styles. I store my page options/attributes and content in SQL or Memcached and then use custom tags to merge the template to the content and options. It's fast and easy to manage.

cf_page is an example custom page we use to abstract the html template away from the content, js, and page theme.

<cfset page = getPage(cgi.script_name)>
<cf_page title="#page.title#" theme="#page.theme#" pageLayout="[two column]" js="[list of js files to load]" jqueryVer="1.3.2" css="[list of css files to load]">
    Page content, additional custom tags, and/or cfincludes
</cf_page>

*It would be easier to break this topic up into smaller sub-questions.

Dan Sorensen
That's the difficult part for me, I want to seperate display from logic, but not so that that I add much to the loadtime of the page...Has to be a good and fair balance..
crosenblum
Are you saying that the custom tag will add more load time to a page than another method?
Dan Sorensen
+1  A: 

why don't you look at eh feature sets of the frameworks out there and just break out what you need from them to create your own.

rip747