>
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]
