mailing lists; it went off in various tangents making it hard to understand
what was being argued and what each person's respective position was. In
light of that, I figured I would summarize my position to avoid being
misinterpreted.
Blackstone has many new features that are going to impact the CFML community
in a variety of ways. Some of these features have been disclosed and I
suspect still others have not been. Some features will provide new
capabilities and others will change how we work. New capabilities are always
interesting, but features that change how we work can both be liberating and
scary at the same time. Sometimes changing how we work might even be a bad
idea. I think it is important, healthy, and interesting to debate the merits
of Blackstone's new features as well as their implementation even though at
this point many of us aren't aware of the implementation.
With that in mind, I think the new cfdocument tag and rich forms
functionality is of huge value to the CFML community. The fact that the
cfdocument tag will allow you to create a PDF file using HTML as input is
quite valuable. While we have long had the ability to produce PDF documents
using a variety of technologies both commercial and open source, it appears
cfdocument will provide not only a more accessible route, but will also
avoid the 3rd party technology analysis and integration required currently.
Rich forms I believe are even more important since forms are used in almost
every web application. Again, we can do rich forms today using _javascript_,
DHTML, Flash, Java, or a combination of the various technologies. However,
the amount of worked required to successfully implement rich forms that work
across browsers is pretty high. W3C has answered with XForms, but browser
support doesn't exist and the knowledge level required is quite a bit higher
than HTML forms. Macromedia has done us a huge service with their
implementation of rich forms. Not only have they kept the knowledge level
low by providing tags that work very similar to HTML forms, but they have
also embraced XForms at the same time. This allows us to easily create rich
forms that work with today's browsers via Flash as well as support future
browsers that implement XForms. Further, it should be relatively easy to
conditionally serve different forms based on the user agent ensuring the
forms to be accessible as well.
This brings me to the event gateway, which is supposed to liberate CFML from
HTTP. Sure there are tons of reasons why you would want to have a CFML-based
web application integrate with protocols other than HTTP. I have integrated
CFML-based web applications in the past with a variety of protocols without
the support of an event gateway. Certainly it would have been easier and
more elegant with an event gateway, but I am not so sure the event gateway
is the missing piece. To me, it seems the missing piece is the ability to
invoke CFML from other sources than an HTTP request. While the event gateway
will provide that, it seems it will also provide more than that.
Do we really need a whole bunch of infrastructure to allow invocation of
CFML from other sources? I don't think we do. The reason I feel that way is
because I think it is far too easy for the community and 3rd party companies
to provide various protocol adapters. With a simple Java API for the
invocation of CFML it would be quite easy for someone with Java experience
to write these adapters. Whether Macromedia or someone else supplies event
gateways or protocol adapters is of little importance to the average CFML
person. In either case, someone with Java expertise must create them and
your average CFML developer will just make use of them.
The real difference is constraints placed on the implementation by the event
gateway. We have already heard that the event gateway will invoke CFC
methods. What if we don't want CFC methods to be invoked? Will we have to
write CFCs that then in turn call CFMs? What if the event gateway framework
makes assumptions that aren't true for all protocols thus making it hard or
impossible to implement some other protocol Macromedia didn't think about?
All of these problems go away if there is a simply Java API for the
invocation of CFML. Heck, Macromedia can even supply a bunch of protocol
adapters if they want; they just don't need to create a framework and force
it on others. Not only that, but if Macromedia didn't spend time on building
stuff the community is perfectly capable of doing they might have time to
work on other things the community can't deliver.
-Matt
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
