Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ColdFusion Programming Methodologies?

Cliff posted more than 11 years ago | from the preventing-uncontrolled-fusion dept.

Programming 40

lars-o-matic asks: "I work at a small (dozen people) company doing quite well building small-to-medium sized sites on the ColdFusion platform and the Fusebox architecture (which also has PHP and JSP versions). With our growth, increasing demand for Flash apps, new features of CFMX, and wanting to take on larger projects, we are researching methodologies. We like Fusebox3 for CF but worry it does not leverage the new object-like CF Components, web services, Flash remoting etc. and wonder if some kind of model-view-controller approach would help separate presentation from business logic. And there's structured documentation, re-usability, maintenance and yes, performance to consider. We're happy with the platform, which suits our project scale. We're not (yet) building a Google or an Amazon.com. It's methodology we need. How have the Slashdot CF users out there scaled from 2 to several coders and from little sites to larger ones?"

cancel ×

40 comments

Sorry! There are no comments related to the filter you selected.

SUCK MY PUSSY (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4430898)

BULLSHIT!!! (-1, Offtopic)

palad1 (571416) | more than 11 years ago | (#4431099)

What do I win? :)

http://216.239.39.100/search?q=cache:UPan4L0ukpk C: research.soc.staffs.ac.uk/~rimmer/knowledge/misc/l oto.pdf+bullshit+loto&hl=en&ie=UTF-8

Hah (0, Troll)

Anonymous Coward | more than 11 years ago | (#4431115)

"We're not (yet) building a Google or an Amazon.com."

Nope, and you won't be w/ CF! When you begin getting a little more visitors to the site, and when the site becomes a bit larger, CF will be out of the game! Use a real language, drag n' drop programming is for M$ weenies who can't use real languages!

Re:Hah (0)

Anonymous Coward | more than 11 years ago | (#4433815)

Its painfully obvious that this person is acting out an old christmas song

Troll the Ancient Yuletide carol.

In other words you don't know anything about CF, and this is a mere blind rant.

FB is it (3, Informative)

mgkimsal2 (200677) | more than 11 years ago | (#4431187)

For CF, FB is about it. Not that it's bad, but you don't really have anything else to point to re: a structured, methodical approach to web development. Mind you, what's there is pretty good, if still a bit sketchy in some areas.

It doesn't leverage whatever OO might be available in CF. It can't, because FB has a history, and the latest CF is, well, the latest. FB will eventually catch up - I've heard the core fusebox team is working on this issue. Timeframe to 'recommended' specs? Dunno. If you're sticking with CF, stick with FB, or come up with something else which suits you better. If you want to migrate to PHP, consider having us come out and give your developers some custom courses in PHP, suited to the topics you need to brush up on. (subtle plug, but what the hey!) :)

FuseBox? Blech. (3, Insightful)

il_diablo (574683) | more than 11 years ago | (#4431523)

personally, i can't stand fusebox. it's an artificial construct attempting to impose order on what is, essentially, a scripting language. a powerful one (i've been building fairly large scale applications in it for ~5 years), but a scripting language nonetheless. it's just not MEANT to have that kind of structure/organization.

or at least, that's what it was LTE CF5. (as a disclaimer, i have NOT worked with MX.)

with the advent of CFMX, it may get better, but most likely it won't be more than a set of rules for including files to simulated separating business logic from presentation, and "virtual code reuse".

as a corollary, i end up developing a set of my own "code management" rules. develop them inhouse, publish the document, and give a copy to your developers when they're new hires. you can customize it to the way your own shop works, and not be constrained by the artificial rules of another development shop. and hey, you can publish that document and call it "FooBox" (or whatever) and pick up some cash.

Re:FuseBox? Blech. (5, Informative)

Tablizer (95088) | more than 11 years ago | (#4432447)

i can't stand fusebox. it's an artificial construct attempting to impose order on what is, essentially, a scripting language. a powerful one (i've been building fairly large scale applications in it for ~5 years), but a scripting language nonetheless. it's just not MEANT to have that kind of structure/organization.

There is nothing wrong with scripting languages and scaling. However, it does depend on your design style. I try to use the database to manage over-all structure, and not so much programming code. More on this at:
[geocities.com]
http://www.geocities.com/tablizer/misclang.htm#d ef ine

The most annoying thing I found about ColdFusion was it's lack of first-class functions/subroutines and funky variable scoping rules. You can get subroutine-like structures using custom tags or the scripting syntax, but they are just not "full citizens". There are certain things you cannot do with or in them. Thus, one tends to end up with long "main" scripts. I want full-blown subroutines.

On the plus side, it has something that PHP and ASP do not have: named parameters.

I looked at fusebox a bit, but found it not very adaptable. It seemed to force pages into one of a predefined set of categories and I needed a finer control for the more complex pages which did not neatly fit into a category or spanned multiple.

Personally, I would totally overhaul the way many biz-centric web forms are typically handled in web scripting languages. There needs to be a "view buffer" IMO on the server side, and one talks to that view buffer instead of to HTML directly. The view buffer is then echoed at the end of the script task to the client (after being converted to HTML), but does not disappear. It would make development more GUI-like. Complex form validation and lookup fields would be much easier because you don't have to keep redrawing the HTML from scratch each time with subtle changes.

Microsoft's dot-net stuff comes a bit closer, but they admittedly convoluted their approach for speed purposes. This is a mistake for most biz apps. The best techniques and optimization profile for building eBay and building an intranet are very different. MS sold out to the benchmark wars IMO. More about this at:

http://www.geocities.com/tablizer/webstif.htm [geocities.com]

Re:FuseBox? Blech. (1)

Atabian (615819) | more than 11 years ago | (#4441683)


ahem [macromedia.com]

Tablizer wrote:

The most annoying thing I found about ColdFusion was it's lack of first-class functions/subroutines and funky variable scoping rules. You can get subroutine-like structures using custom tags or the scripting syntax, but they are just not "full citizens". There are certain things you cannot do with or in them. Thus, one tends to end up with long "main" scripts. I want full-blown subroutines.

Re:FuseBox? Blech. (1)

lo_fye (303245) | more than 11 years ago | (#4456834)

Fuxebox doesn't organize or change the code, per se. It is a *way of coding* and structuring sites, so that everyone codes the same way. Thus, any member joining the team, or joining a project half way through can just pick it up and immediately understand the architecture and logic, because it is the standard fusebox architecture and logic.

Yes, fusebox is imposing order on the chaos of scripting languages, but I'm betting that it doesn't impose nearly as much on neat/tidy coders as it does on sloppy coders.

The problem with developing your own 'in house' rules is that no one on the outside knows them... so you can't hire someone who already knows 'your' rules.

CF Market Growth? (2)

n-baxley (103975) | more than 11 years ago | (#4431567)

This is slightly offtopic, but I'm curious what the market for CF development is like. I LOVE developing in CF but lately have been stuck in ASP and Java development. CF seems to have slipped in its prevalenca and I'm hoping that the new MX version will give it new life. Do you find that you have to push CF on people or are they coming in asking for it?

Re:CF Market Growth? (1)

il_diablo (574683) | more than 11 years ago | (#4431590)

It's not like people are beating down the door for web development of any stripe (except Java/J2EE, and you have to have a TS/SCI with lifestyle poly from the NSA, but we'll get into THAT somewhere else).

My day job is crappola (please note that I'm posting during work hours...), but I do CF dev on the side. I've found that the preponderance of clients don't give a rat's butt what you use, as long as you can support it. Of course, if they already have a hosting solution selected (or host in-house), you may be stuck with doing the application in whatever they have available. As for me, I have a close relationship with my (former) partners in business, and they offer hosting for my clients. I do they app, they get the hosting fees.

Re:CF Market Growth? (3, Interesting)

rednox (243124) | more than 11 years ago | (#4431869)

I work at an even smaller shop than Lars, and we develop 90% of our web sites using ColdFusion.

For the smaller clients, they don't even ask what programming language we're going to use. We host most of the sites ourselves, but when a client has their own host, we are finding more and more ISPs waking up to CF and providing it.

A lot of our medium-sized clients are getting in to hosting their sites on their own boxes, and they are definitely interested in what software will be running the site. Once the benefits of ColdFusion are explained to them, they're happy to use it. The fact that the server software is so inexpensive doesn't hurt either. We usually also sell them on the fact that the development will cost less, since developer productivity is excellent with CF.

For the larger clients, I have to do a lot of talking. They sometimes run other sites/applications on the same web server, so they are very careful about what to install. That's one reason I'm very happy CFMX will now install on top of Java Application Servers like Websphere/etc. Larger clients also want to know how this will fit in with the scope of their larger development strategy. Is it a good choice for other applications? (usually) Does it run on our platform of choice (usually yes since it runs on windows, Solaris, Linux, etc.) Is there a large pool of CF development talent to draw on? (yes) Is high-quality tech support and training available. (yes)

On the other hand, although we can convince people to use it, nobody comes and asks for a site to be developed in CF. It's just not a buzzword right now. Everyone is talking about Java and JSP. We are moving towards JSP ourselves, but the environment needs to become more robust before we can make the switch. Coldfusion MX will help with this a lot, since it supports JSP as well.

Re:CF Market Growth? (1, Informative)

Tablizer (95088) | more than 11 years ago | (#4432643)

We usually also sell them on the fact that the development will cost less, since developer productivity is excellent with CF.

Although it is quick at basic stuff, IMO CF does not scale in complexity very well (for reasons given in other message).

Is there a large pool of CF development talent to draw on? (yes)

In this anti-tech economy, just about *any* language/tool will have plenty of people who used it before and are available.

It's just not a buzzword right now. Everyone is talking about Java and JSP.

Fricken Java. The greatest Bloat-A-Tron in modern history. Its the New COBOL. It makes developers *look* productive by the shear amount of code it takes to do something, and makes otherwise simple things into tangled webs of GOF-gone-mad spehgetti.

Can I hire a Saprano to thunk it off in a dark alley?

Re:CF Market Growth? (2, Interesting)

madstork2000 (143169) | more than 11 years ago | (#4433180)

What are the benifits of CF as opposed to an open and freely available tool like PHP or PERL? What do you tell potential customers to have them choose your CF development over another companies PHP development? Does CF support rival the near ubiquitous support for PHP and PERL? Do you feel at all locked into the proprietary software module (i.e. do you feel forced to upgrade when a new version comes out?) Do you feel confident security issues will be resolved in a timely manner (and what is the track record for CF security)?

I've used PHP and PERL for several years, I also have used proprietary web scripting tools like Progress WebSpeed, but since I am now working for myself full time, I'm interestedd to know what else is out there. And how it stacks up compared to the tools I am familiar with.

Thanks,
MS2k

CFMX advantages (2)

GCP (122438) | more than 11 years ago | (#4443045)

If you build sites that need to scale multilingually, you'll find CFMX dramatically better than PHP or Perl because it's based on Java (therefore Unicode) strings.

It gives you the convenience of tag-based scripting, like PHP, with the internationalization power of Java.

This isn't likely to matter if your client is a local shoe store, but for larger clients it does, even if the client doesn't realize it.

Market? (3, Insightful)

budalite (454527) | more than 11 years ago | (#4431783)

Well, judging from the # of posts here, either this ain't the place for CF posts or the market isn't too hot. Shame, too. CF4 did exactly just about everything that a developer of small to medium web-apps. needed or wanted to do. CF4 worked very well with Apache. As the market for small to medium web apps went towards the gutter, so did CF, I guess. Turns out the web wasn't as popular among the basic small- to medium-sized businesses in the business world was (and amazingly still is) thought.

CFMX, as far as I can tell, is the Allaire boys (after selling out to Macromedia) and CFMX trying to be the all-purpose IDE for all dev. environments, instead of just doing its own thing, which got it where it was. Those that try to please everybody generally just please no one. Oh, well. It was really fun while it lasted.

(whatever)

Re:Market? (2)

greenhide (597777) | more than 11 years ago | (#4431965)

Well, the truth is there aren't all that many stories on ASP either, and when they are they usually fall into the "My isn't Microsoft just about the most evil/least competent software manufacturer out there?"

Slashdot is really big on Open Source software, but is not quite as keen on proprietary software. And a license ColdFusion, until recently, wasn't cheap--it started at above the $1k mark. Now, a license for ColdFusion MX can be had for as "little" as $500 or so, I think.

I am an ardent ColdFusion programmer, by the way, and I have noticed, if anything, that use of ASP has dropped while ColdFusion is showing up in more and more sites as people discover just how easy and powerful it is.

I don't think you need to worry about ColdFusion losing its relevance. Every advance in ColdFusion has lead to greater use despite the possibility of more complexity.

This is because the starting level has remained the same throughout. Thus, it isn't necessary to use CFCs or any of the complex constructs that are now available. One of the strengths of ColdFusion is that you can pretty much take any book ever written about ColdFusion from '98 onward and with it create a working web application. So, it is incredibly easy to learn. So, I don't think that the newest changes are going to decrease its popularity.

Re:Market? (2, Informative)

Tablizer (95088) | more than 11 years ago | (#4432761)

I am an ardent ColdFusion programmer, by the way, and I have noticed, if anything, that use of ASP has dropped while ColdFusion is showing up in more and more sites as people discover just how easy and powerful it is.

I think one of its strengths is in how easy web masters can relate to it because of it's HTML-like syntax and its vendor-neutral database wrappers. A web master that has a lite programming background will find it much more approachable than server-side Java.

And, one of the reasons for ASP slowdown is that MS is *changing* everything to support dot-net. Existing ASP code will not work directly on dot-net and original ASP support will probably dwindle over time. Thus, rather than starting over with MS, they would rather start over with PHP, CF, or Java because they are pissed over MS's heavy-handed switcheroo.

Re:Market? (0)

Anonymous Coward | more than 11 years ago | (#4433720)

Slashdot's never been a place for the CF-Community. On the other hand, check out the lists on House of Fusion (www.houseoffusion.com/cf_lists) and you'll see a LOT of traffic.

Don't (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4432083)

Don't

FuseQ (2)

greenhide (597777) | more than 11 years ago | (#4432087)

You might look into FuseQ [techspedition.com] . It's being developed by John Quarto-vonTivadar (and perhaps others?) at Techspedition [techspedition.com] . One of FuseQ's goals is to become the basis for the MCV model within Fusebox [techspedition.com] . See also this article [techspedition.com] .

One of the other guys at techspedition is Hal Helms [halhelms.com] , one of the early embracers/gurus of Fusebox. The current Fusebox 3 standard is based heavily on many of his ideas, including circuits and FuseDoc. He has written a book called Discovering CFCs (ColdFusion MX Components). Thus, I'm guessing that he is working hard to integrate CFCs into Fusebox.

Fusebox is relatively young, and still very flexible. It's very likely that the new features in ColdFusion MX will be incorporated into newer versions of Fusebox. After all, they need to return the favor--Macromedia/Allaire actually incorporated a tag developed by Fusebox developer Steve Nelson [secretagents.com] into ColdFusion 5: <cf_bodycontent>, with some variations, became <cfsavecontent>.

misuse of terms (3, Informative)

DevilM (191311) | more than 11 years ago | (#4432132)

First, Fusebox isn't an architecture. Second, MVC isn't a methodology.

Any good methodology wouldn't be specific to a programming language. A good architecture for Web applications would also not be specific to a programming language. MVC is a design pattern that can be applied to be different architectures and programming languages. About the only specific thing you really need for CF is an application framework. Fusebox is an application framework; it just isn't very good.

CFO Bjects (0)

Anonymous Coward | more than 11 years ago | (#4432152)

Personally I wrote a specification for in-house. This was for a shop that went from a primary developer and a secondary (not really ful-time) to about 15 developers. I looked at Fusebox, and I was coding in PHP at the time, I also came across CFObjects around then. I drew on all of these including my C++ background to write the spec. Then I had something that tried to make CF scripting saner, while still allowing it to be what it was a scripting language.


I haven't seen MX cause I am now working for a company that is PHP only. I suggest you get your experienced coders to throw ideas around, having something that is sane and them is invaluable. I would still have input from your "non-geek" coders, but you really want the guys who eat, breath the web to formulate your spec, cause they have more to draw on.


BTW I was the secondary coder originally, because I was still in high school at the time, but I understood a lot more about coding standards and what was structuring, but not limiting to what I want to do.

You are doomed (3, Interesting)

Hard_Code (49548) | more than 11 years ago | (#4432282)

Gah. The web is just the WRONG paradigm (can I say that?) to use for complex interactive applications. When you purchase a car, does it come with a "page-based" interface metaphor? Are there "steering-wheel-emulation" frameworks for emulating a steering wheel on a piece of paper? Yet that is what all these MVC frameworks which attempt to emulate an interactive stateful application on the client side propose to do.

It's just wrong wrong wrong wrong wrong. The web is great for displaying PAGES, not applications.

For the complicated applications people are trying to shove on the web, we need a new solution. Something in between a standalone fat application, and completely server-rendered pages (web). Something like cURL, or XULUX, or (choke) XUL + scripting glue.

When you try to add complicated statefullness and interactivity to the page-based server-based metaphor, complexity scales exponentially...it's just crazy. Your app just becomes a Big Hairy finite state machine DSP.

Re:You are doomed (1)

bitpusherdotorg (544243) | more than 11 years ago | (#4433509)

Isn't this what "web services" is all about, using emerging technoligies like SOAP to create robust protocols supporting more complicated web based applications?

Re:You are doomed (2)

Tablizer (95088) | more than 11 years ago | (#4434292)

Isn't this what "web services" is all about, using emerging technoligies like SOAP to create robust protocols supporting more complicated web based applications?

No, web services is more of a server-to-server communication issue (which I think is overhyped. HTTP plus some XML wrappers is sufficient for most IMO). The poster is talking about mostly client-side and UI protocol issues (in my interpretation).

I agree though that for biz form-intenstive applications, current web protocols suck eggs. The web is optimized for e-brochures, and NOT e-data-entry. However, I would prefer a slightly different solution type, such as XWT (www.xwt.org) or SCGUI (my own pet protocol for such).

Re:You are doomed (2)

rycamor (194164) | more than 11 years ago | (#4435907)

Hey Tablizer,

I have recently become very interested in XUL/XPCOM, which seems to have matured a lot in the past year. I actually read with interest your SCGUI concepts a few months ago, and I think its quite possible that this could be implemented in the Mozilla XUL/XPCOM framework.

I agree that the term "webservices" is just a way to overhype what is essentially a very simple concept. The only real complexity comes from the laughable attempt to turn XML into both a database platform and a programming language, when it is really just a data interchange format (and an inefficient one at that). As Fabian Pascal says, this is what you get when you have a protocol "Invented by text publishers without any understanding of database management."

But anyway, It seems that XUL is one of the few good examples of a use for XML: custom tags to create truly functional GUI components. The only thing it is lacking is your concept that each element should be able to "requery" it's status from the server, without downloading the whole document again. Well, I have already implemented that capability with simple Javascript and regular HTML, so I doubt that it would really be a challenge to to it with Mozilla/XUL, which is in many ways more Javascript-friendly.

Your thoughts?

Re:You are doomed (1)

Tablizer (95088) | more than 11 years ago | (#4437919)

(* Well, I have already implemented that capability with simple Javascript and regular HTML, so I doubt that it would really be a challenge to to it with Mozilla/XUL, which is in many ways more Javascript-friendly. *)

Do you have a demo screenshots of it by chance?

I prefer not to rely on JavaScript for a final product. That opens the door to interpreter bugs, version differences, and lots of viruses. I like to say that I prefer something that is "Turing INcomplete". Or, at least be able to run without the need for downloading app-specific scripts, even if scripting is an available option.

Then again if you are using the JavaScript to implement a "demo browser" as a proof of concept rather than as part of the protocol, then I have no complaints.

I am glad to see people are exploring options. Even if SCGUI is not "it", the current approach to web biz forms has gotta go regardless.

Bosses, users, and network managers want real GUI's over HTTP. The biggest issue seems to be how fat the client (protocol) has to be to be usable. IMO scripting is not necessary for most needs, and at the very least the protocol should work satisfactorily without Turing-able scripting if need be. The new push for more security will hopefully make people realize this.

Imagine how all the current "web-based applications" will look obsolete if a good web GUI solution/protocol becomes common-place :-)

Re:You are doomed (2)

rycamor (194164) | more than 11 years ago | (#4439511)

I really think Javascript is an under-appreciated resource. Your reservations about intepreter bugs, version differences, etc... all apply to any distributed application. If the client is version X.1, and you upgrade all clients to X.1.1, but one person misses the upgrade, what do you do? You detect when that person finally logs in, and instruct him/her to get the upgrade.

And since we are not talking about an attempt at cross-browser Javascript, I foresee even less difficulty.

Anyway the Javascript feature to update form elements is the oldest, most _core_ part of Javascript, ever since Javascript first came out. Any browser from Netscape 2 to Internet Explorer 3 supports that basic ability.

I don't have screenshots of my implementation at the moment, but I explain a very basic example: I had a client who wanted to implement a browser-based chat system (I know... ugh..). I know most of these involve auto-refresh headers, and the cleverer ones separate out the non-updating parts with frames. I took it one step further. I used three frames. The top frame was the entry , and the bottom frame was the output area, which contained the text from both participants. The third frame was hidden, and had absolutely no HTML for display, just a basic refresh meta-tag, and a section. The block simply received the latest incoming chat text, set it as a javascript variable, and called a javascript function in the upper frame, which appended it to the element in the lower frame. Most requests in that hidden frame were tiny, averaging about 120 bytes, getting nothing more than the raw text of the message, plus about 40 bytes of HTML/Javascript.

Extremely simple, but effective. I have since worked on some other ways of communicating between the server-side and Javascript _without_ even requiring a hidden frame. See my comments as member 'rycamor' at this Devshed thread: http://forums.devshed.com/showthread.php?s=&thread id=16326

I'll email you to discuss this further ;-).

Re:You are doomed (2)

DevilM (191311) | more than 11 years ago | (#4434597)

Let's not forget the Rich Internet Application paradigm suggested by Macromedia.

Flash front-end + Web services backend = RIA

Re:You are doomed (1)

Tablizer (95088) | more than 11 years ago | (#4435207)

(* Let's not forget the Rich Internet Application paradigm suggested by Macromedia. Flash front-end + Web services backend = RIA *)

I could not find any info on the protocol/API. It appears vendor-locked at this stage.

Re:You are doomed (2)

DevilM (191311) | more than 11 years ago | (#4436215)

Flash can use SOAP or AMF as the marshalling protocol. SOAP is quite open as it is a W3C standard.

Re:You are doomed (1)

Tablizer (95088) | more than 11 years ago | (#4437860)

(* Flash can use SOAP or AMF as the marshalling protocol. SOAP is quite open as it is a W3C standard. *)

Why not HTTP? SOAP is a little hard to configure. If something can use HTTP, then you save a lot of setup effort on both sides (client and server). Fire-walls can be picky and admin-intensive to do anything non-HTTP. My hacky SCGUI demo uses HTTP, BTW.

(I know that SOAP has HTTP wrapper options, but you don't need that many levels IMO.)

Re:You are doomed (2)

DevilM (191311) | more than 11 years ago | (#4439330)

HTTP is not a marshalling protocol, which is why a marshalling protocol like SOAP is often used on top of HTTP. In fact, Flash can only use SOAP over HTTP.

Based on this comments and others I think you need to read up on Web services and get a better understanding of them because you seem misinformed.

Re:You are doomed (but at least you're organized) (0)

Anonymous Coward | more than 11 years ago | (#4437897)

In the absence of alternatives, MVC as implemented in the fusebox framework is fine for most scripting languages.

On the plus side, the fusebox framework brings some organization to what would otherwise be a collection of interconnected pages of script. Fusebox is fairly straightforward and a developer can use it with a single day of instruction, so it can be a very useful application development tool.

OTOH the resulting application is usually a single large executable which handles all functions (and pages). This is not in itself a bad thing, but appears to be precariously close to the Big Ball of Mud [laputan.org] methodology of software development, although it really isn't.

Until something better comes along for scripting languages complex applications can be organized using fusebox. And at that time it shouldn't be difficult to refactor an application from the fusebox framework to another, better methodology.

The REST [conveyor.com] methodology approaches applications development from another perspective and is grounded in the structure of the WWW: it may be the next place to look for organizing WWW applications development.

Re:You are doomed (0)

Anonymous Coward | more than 11 years ago | (#4438234)

Flash/ActionScript powered apps are the way to go! You can lighten the load on your servers by reducing the number of server hits using a Flash movie as your interface. I've done this with *excellent* results. I wrote my own app server in Java to help me out. Works well. I'm going to GPL it as soon as I write some docs for it. Encouragment to get me to finish sooner to bg at traqer dot com.

Re:You are doomed (2)

ProfKyne (149971) | more than 11 years ago | (#4440298)

For the complicated applications people are trying to shove on the web, we need a new solution. Something in between a standalone fat application, and completely server-rendered pages (web). Something like cURL, or XULUX, or (choke) XUL + scripting glue.

Yeah! They should develop something like that -- it wouldn't quite be a full application, but would have a lot more to offer than the standard web browser feature set. They could call it an applet or something.

For the last time... (2)

aquarian (134728) | more than 11 years ago | (#4439584)

...a way of going about something is a *method*, not a "methodology." Yeah, I know, everyone uses it, but it's still wrong. Don't they teach English in college these days?

Best Coldfusion Programming Practice (1)

SPiKe (19306) | more than 11 years ago | (#4451680)

Don't do it kids, mmmmmmk?

<CFINCLUDE TEMPLATE="dsp_fuseboxSucks.cfm"> (0)

The_Rippa (181699) | more than 11 years ago | (#4456403)

I'm being forced to develop a LARGE scale app using Fusebox. I've been programming CF for a little over five years now and developed my own standard I called "pseudobox" because it implemented the GOOD qualities of fusebox and left room to be creative. I hate the fact everything has to fall under dsp, act, qry, etc. In the app I'm building right now, that's not enough. And I don't like the fact that I have to post the form action a fuseAction to the index.cfm file...why can't a form just post to itself? I've worked at a lot of different types of software houses in the past that consisted of mainly knowledgeable web developers and we all agreed that fusebox is most definitely not the way to go...too bad the morons in management at my new place don't share the same opinion.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?