Spike wrote:
As evidenced by reading Tim Buntel's blog, Macromedia have done a lot of work with the forms, but I bet there will be situations where you still won't want to use them.
CFFORM to date, has been useless simply because its too blackboxed. Try overloading the validation methods or extending them, and you aren't as agile. CFFORM with FLash capabilities, is great step forward but they too are limited in functionality thus i get the feeling they'll be a sore point. Point is, if you going down that path, allow the developer more ability to poke holes in it if need be (thus release the source code instead of it being closed off tag - ie much like CFDUMP tag).
If the solution was as simple as you are proclaiming, it would already have been done. That hasn't happened, so the solution must be a bit harder than that.
Macromedia has produced a solution to part of the problem with Flex and guess what their market research tells them...
It is worth a hell of a lot more than CFMX to anyone who really wants it. Anyone who doesn't want to pay up is welcome to build equivalent functionality themselves.
Thats the key, money, MM know its a "oooh i'd love that" request, and being a large corporation and time invested so far, they go for the big bite - cool, its the way of life. Personally i think they could achieve more returns with a lesser price tag.
FLEX IS A dynamic enough solution. You will always get people who feel they can do better, hell i have that attitude at times. If FLEX or Longhorn do come to our tables, i'd not push them away because they don't do a specific UI concept that i've wanted. In both products you can combine core elements to build your specific UI, but within a SOE technology. That in lies another problem, building a UI to be accessible accross all technologies (browsers/operating systems - it was what HTML was intended in many ways to evolve to?).
Simple concepts like "Editable combo box", "data grids sortable by headers", "tabbed forming", "client-side remoting" all typical UI concepts we take for granted in client-side technology yet always expect to emulate web-side).
They have no real special attributes and capabilities attached to them, and typically most applications you build in a web-based format would use the above. Yet no such luck in being able to use them with a product like CFMX unless you roll your own.
I propose a core framework be built, they gives you the above concepts. If you then want to come up with your own style accordion panel tree component, you can do so without having to build it from the ground up.
In flex last week i had a need for a specific menu component, inside an accordion panel. It wasn't a typical UI concept, and was custom. I managed to roll my own inside FLEX with minmal effort, simply by using the given ingredients (pre-built controls). If i wanted to go further and add in my own events etc, i could, but i wanted it tag based for now. Point is, it was a dead easy concept and was achieved in minimal time thanks to the core framework.
HTML is our core framework to date, its got some usefulness but its also been done in a limited fashion and the overall controls are too black boxed *ie like CFFORM*. The key to giving a developer a succesful UI, is allowing them to insert custom logic within a combo box if need be, but also giving it to them in a default state (ie if they want to add icons to a combo box, simply extend that control and overload the methods etc).
The fact that you are working on a project that is a mess doesn't change any of the above, but it certainly seems to have you pointing fingers and yelling at anything you can to apportion blame. The bottom line is that no matter how much you dislike it, the project will not get better by complaining about what Macromedia should or shouldn't be doing. It may get better if you try to come up with a salvage plan that is actually workable.
This hasn't really anything to do with given project, the UI on my "world of pain" *current project* isn't the problem, its more so Server-side. I'd like to devote more focus on that then UI, but our UI concepts are actually streamlined due to us rolling the XML solution. I bring this all up as a big "why", simply because to me, its a solution that i've heard many a developer go "that'd be really cool and i'd use that" whenever i preech my theory to them. That and its like the 5th time/project i've personally would of used. Now, i'm not a cluey guy, so i'm wondering why the hell no1 else has done it (other then FLEX)? R&D is minimal effort, as all you have to is ask the following question:
"What do you hate about HTML controls"
Jot down those answers and make controls that fix those solutions, and you've got a very good start.
To proove that, simply look at CFFORM in blackstone (again its blackboxed) but its a start in the right direction.
Scott
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
