ColdExt goals and future roadmap

I have a few clear goals that I am trying to achieve with ColdExt which will hopefully give you an idea of where I am coming from and where I am heading with development.

First of all, I want you to be able to drop ColdExt into a project without any hassles and without any configuration beyond an Application Name (although a small amount of configuration may be unavoidable for an existing Ext project).

Second, I want the ColdExt API to match the Ext API as closely as possible so that the Ext documentation is entirely relevant to using the ColdExt tags. I also want to retain the power and flexibility of Ext in it's entirety, not have ColdExt force you down some specific path for how your UI must be declared and rendered. For example many component tags should be able to be used stand-alone to simply create JavaScript objects that can be used (and reused) later on in the code; components shouldn't always have to be rendered immediately. (Note that this hasn't yet been achieved in the Alpha 1 release, everything is constructed by config objects at the moment).

Third, I want to provide some default configuration options that will set up the UI controls with consistent display properties Application-wide and allow you to customise these global defaults with your own values if you wish. This can just help to keep to keep your code a bit cleaner by letting you write less and repeat yourself less :) Of course, any global defaults can be overridden at the tag level.

The ultimate goal is to achieve near complete coverage of all Ext features and functionality, so that you don't have to drop back to pure JS to use the more complex or obscure features that Ext has to offer. The ColdExt tags should be useful for the vast majority of cases, and then for any hardcore client-side programming ColdExt can still wrap handlers, listeners and any other pieces of JavaScript.

For the road ahead I also have a few ideas that could make development with ColdExt quite interesting;

  • Built-in handlers for common client-side actions/events
  • Support for ColdFusion Structs/Queries/JSON/XML/Objects(?) when applying values to FormPanel fields (and other types of forms)
  • Form generation/scaffolding of some description (tags make this so much easier, it would be a PITA to do this directly with JS!)
  • Code assistance in CFEclipse

Anyway, if you have any comments or opinions on the direction I'm taking I would like to hear them :)

Comments
Keep up the good work!!!
# Posted By Trond Ulseth | 2/5/08 3:13 AM
Just out of curiosity, is there any reason you and Dan Vega (cfext) aren't collaborating on your projects? Both have the same basic vision, and the two of you together could probably put out some really nice stuff...
# Posted By Steve 'Cutter' Blades | 2/5/08 1:04 PM
@Steve: We have been collaborating somewhat, just not working on the same code base (if you can call that collaborating, hehe) :) Dan has had a copy of my code for 3+ weeks since before I posted my initial blog entry about the potential of a library (http://www.madfellas.com/blog/index.cfm/2008/1/16/...), and we have been chatting over IM pretty regularly the past 4-5 weeks.

We have just been working on our own stuff because we started in different directions; Dan was working on the Window and Message Box, and I was working with Forms because that's what I needed to investigate at the time. There is probably no real reason why the codebases couldn't merge (although there are some minor implementation differences), but I just wanted to get this release out there and get some feedback on the direction!
# Posted By Justin Carter | 2/5/08 3:18 PM
Would like to speak to you regarding some custom development work if you have the time. Could not find your email address.
# Posted By jeff Mayer | 2/20/08 1:24 PM



If you subscribe, any new posts to this thread will be sent to your email address.

BlogCFC was created by Raymond Camden. This blog is running version 5.6.001.