RE: Blackstone summary
> Presumably by writing Java or some other non-CF code, yes? > Correct. > I agree - and Ben Forta's tour report mentioned the ability to access > CFCs from Java. My reading of that is that such functionality would be > separate from the event gateway (but I don't have insight into the > product team's features so I may be off-base). It seems to me that the > ability to access CFCs from Java is a pre-requisite for event gateways > and I'd be very surprised if the only way to access CFCs from Java was > via the event gateway framework! > Ah, but just being able to call CFCs from Java may not be enough, which is why I specified other protocols than HTTP. For example, if you could call CFCs from Java, but you need a reference to the PageContext then things would still be tied to HTTP or more specifically, Servlets. > I hope you're right. I don't see how it could be anything but > beneficial for CF to have community-developed protocol adapters - > either through the event gateway or separately. If the community does > a better job at creating a "gateway" framework than Macromedia, CFers > will have more choice and the bar will have been raised even further. > In what way is that a bad thing? > As long as Macromedia doesn't constrain 3rd party implementations through frameworks and/or assumptions. > This is a good point and something I'm currently wrestling with as I > try to drive a Fusebox 4 application from the event gateway. However, > there are very good arguments for using CFCs: > - a CFM page does not have an easily identifiable Java 'handle' > (class) by which to manipulate it > - a CFM page does not have a well-packaged way to pass in arguments or > return data > - a CFC maps easily to a class with a set of callable methods > - CFC methods have a well-defined interface that accepts arguments of > arbitrary types and can return an object of an arbitrary type > I'm not saying it can't be done with CFM pages, just that for a 'first > cut' implementation, it makes more sense to use CFCs. > There is no argument that CFCs are better than CFMs in this particular case. However, it could be straight forward enough to do message passing via a scope. > The same issue arises with Flash Remoting - in order to use a natural > calling interface in ActionScript, you need to connect to a CFC which > exposes a method-based interface. > Ah, but with Flash Remoting you can call CFMs and pass data via the flash scope. > I'm trying to find some interesting ways to make it realistic to > interact with CFM-based applications using the event gateway and, yes, > right now I'm "forced" to use a CFC to wire them together... > That isn't good. > What if, indeed? Use the underlying Java / CF API that I would expect > to be there based on the information publicly available about > Blackstone... > Again, if the Java API assumes a PageContext reference this will be hard. > As someone who is using Blackstone's event gateway, I can attest that > the framework adds value that makes using the protocol adapters > easier. I can't say any more than that due to the nature of alpha/beta > programs and NDAs but I hope that others will agree with me once > Blackstone is available to all CFers... > Most frameworks do add value, but the also force constraints. This is why it is nice to be able to pick and chose frameworks as opposed to them being mandated by the vendor. -Matt [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
Re: Blackstone summary
On Aug 20, 2004, at 9:29 AM, Sean Corfield wrote: > > > To me, it seems the missing piece is the ability to > > invoke CFML from other sources than an HTTP request. > > I agree - and Ben Forta's tour report mentioned the ability to access > CFCs from Java. My reading of that is that such functionality would be > separate from the event gateway (but I don't have insight into the > product team's features so I may be off-base). It seems to me that the > ability to access CFCs from Java is a pre-requisite for event gateways > and I'd be very surprised if the only way to access CFCs from Java was > via the event gateway framework! > > > While the event gateway > > will provide that, it seems it will also provide more than that. > > Yes, that is my reading of what has been said publicly too. > > > 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. > > I hope you're right. I don't see how it could be anything but > beneficial for CF to have community-developed protocol adapters - > either through the event gateway or separately. If the community does > a better job at creating a "gateway" framework than Macromedia, CFers > will have more choice and the bar will have been raised even further. > In what way is that a bad thing? I agree and support the above paragraphs -- the event gateway will provide an easy way to expand the use of CF to address a larger portion of the total IT pie & play nicely within the j2ee environment (and take on a bigger roll). With the availability of a well-defined event gateway interface, Java programmers will be able to extend or refine this method of invoking CF code. With the availability of a well-defined Java API, Java programmers should be able to write a portion of their Java applications using CFML -- this can only benefit both the CF and Java communities. As an interesting aside, with both of the above, the use wouldn't necessarily be limited to Java -- other languages/environments could take advantage of the interface. Dick [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
Re: Blackstone summary
On Wed, 18 Aug 2004 13:12:11 -0400, Matt Liotta <[EMAIL PROTECTED]> wrote: > I figured I would summarize my position to avoid being > misinterpreted. Good summary - and hopefully this will bring the discussion back on track (it certainly provides a cleaner framework discussion for some points I want to make!). > With that in mind, I think the new cfdocument tag and rich forms > functionality is of huge value to the CFML community. Agreed. > I have integrated > CFML-based web applications in the past with a variety of protocols without > the support of an event gateway. Presumably by writing Java or some other non-CF code, yes? > To me, it seems the missing piece is the ability to > invoke CFML from other sources than an HTTP request. I agree - and Ben Forta's tour report mentioned the ability to access CFCs from Java. My reading of that is that such functionality would be separate from the event gateway (but I don't have insight into the product team's features so I may be off-base). It seems to me that the ability to access CFCs from Java is a pre-requisite for event gateways and I'd be very surprised if the only way to access CFCs from Java was via the event gateway framework! > While the event gateway > will provide that, it seems it will also provide more than that. Yes, that is my reading of what has been said publicly too. > 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. I hope you're right. I don't see how it could be anything but beneficial for CF to have community-developed protocol adapters - either through the event gateway or separately. If the community does a better job at creating a "gateway" framework than Macromedia, CFers will have more choice and the bar will have been raised even further. In what way is that a bad thing? > 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? This is a good point and something I'm currently wrestling with as I try to drive a Fusebox 4 application from the event gateway. However, there are very good arguments for using CFCs: - a CFM page does not have an easily identifiable Java 'handle' (class) by which to manipulate it - a CFM page does not have a well-packaged way to pass in arguments or return data - a CFC maps easily to a class with a set of callable methods - CFC methods have a well-defined interface that accepts arguments of arbitrary types and can return an object of an arbitrary type I'm not saying it can't be done with CFM pages, just that for a 'first cut' implementation, it makes more sense to use CFCs. The same issue arises with Flash Remoting - in order to use a natural calling interface in ActionScript, you need to connect to a CFC which exposes a method-based interface. I'm trying to find some interesting ways to make it realistic to interact with CFM-based applications using the event gateway and, yes, right now I'm "forced" to use a CFC to wire them together... > 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? What if, indeed? Use the underlying Java / CF API that I would expect to be there based on the information publicly available about Blackstone... > 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. As someone who is using Blackstone's event gateway, I can attest that the framework adds value that makes using the protocol adapters easier. I can't say any more than that due to the nature of alpha/beta programs and NDAs but I hope that others will agree with me once Blackstone is available to all CFers... -- Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
Re: Blackstone summary
>>you want ti invoke a CFM or CFC directly. from outside CFMX without the indirection/overhead of listening for and triggering an event. What would much more intersting IMHO would be the contrary: Invoke external functions from CF just like if it was a CF function. Yes, there are CFXs, but having extra libraries of functions that could just be added to the basic library would be great. You could just install a DLL like for a CFX, and all the functions it contains are automatically callable, with no need to include the source. And functions could be developped in any language, including CF. Third parties could be more interested in developing tools since they would only have to give the executable. I duno, but this feature was definitely one of the key factors in the popularity of a language like Clipper, and a hudge advantage over dBase some 10 years ago. Clipper was so popular, because many third party tools were availaible on the marked. -- ___ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: [EMAIL PROTECTED]) Thanks. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
Re: Blackstone summary
On Aug 18, 2004, at 11:43 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: > To state the obvious, I would urge caution on pre-judging Blackstone > before it's released. What has been talked about is just the surface > of this release. > Well, the autumnal equinox is Sept 22-23, so Fall 2004 is coming soon... That's when the Blackstone beta is supposed to hit -- maybe a public beta :) Dick [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
RE: Blackstone summary
To further that, I have no inside knowledge about Blackstone and my perspective is completely based on public information. While all this is purely speculation at this point it should at least give something for Macromedia to think about, which in the end should benefit us all. -Matt > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] [EMAIL PROTECTED] > Sent: Wednesday, August 18, 2004 2:43 PM > To: CF-Talk > Subject: Re: Blackstone summary > > To state the obvious, I would urge caution on pre-judging Blackstone > before it's released. What has been talked about is just the surface of > this release. > > Regards, > > Damon > > [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
Re: Blackstone summary
To state the obvious, I would urge caution on pre-judging Blackstone before it's released. What has been talked about is just the surface of this release. Regards, Damon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
Re: Blackstone summary
On Aug 18, 2004, at 10:12 AM, Matt Liotta wrote: > 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. Ahhh... I understand what you are saying -- you want ti invoke a CFM or CFC directly. from outside CFMX without the indirection/overhead of listening for and triggering an event. That's certainly valid! I can think of several places where this approach would be superior. But that doesn't negate the value of an event gateway. That said, it should be possible to implement Both ways of invoking a CFC/CFM--- Isn't what you want an API that provides the same interface that (part of) the event gateway uses to invoke the CFC? If so, I suspect that it would be relatively easy (from a technical standpoint) for Macromedia to provide that API. Whether that is in Macromedia's best interest is a consideration. Because what you are asking for is the ability to incorporate CFML Classes (CFCs, CFMs) into a Java (or other) program. Does that mean that your package includes: 1) Your Java app 2) Your CFMs & CFCs 3) The CFMX/Blackstone Redistro jar I can see this as being viable as long as the manufacturer (Macromedia in this case) can make acceptable income on 3. > 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. True, but... There are are a series of events that occur within the CFMX system, itself. Logically, it seems that it would be easier to process these with an enternal event gateway, rather that attempt to do this from outside the system. The set of applications that monitor things internal to CFMX and application activity come to mind. Consider that you you could write a fantastic performance monitoring/tuning/debugging tool. Certainly you could that external to CFMX, but it would likely be easier with an event gateway (where you could intercept events without consuming them). And, yes, you would need to write some Java code to do this ... unless we have something like cfmessage that allows us to setup the listener - processor linkage. > > 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. > > Let's see if we can convince them to do both! Dick [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
Blackstone summary
The recent Blackstone thread on CF-Talk did what long threads often do on 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]
