I like your comment on the firewall preventing more of the dynamic type webapps (see my article on XSpot http://www.us-eh.com/craiger/articles/xspot/), it's so true.
<tataryn:craig/>
Dan Connelly wrote:
Okay, that's a good question. Here is my instant analysis of Barracuda v. Struts. ("Instant" and therefore probably worthless. BTW, I haven't used Barracuda. And my experience with Struts is confined to toy applications.) Barracuda has apparently bitten of the Event/Listener model as its top-priority task. Struts has deferred this design decision until a later release. And there certainly are a ton of more mundane concepts to work through. The Event/Listener Model appears on the Struts 1.1 to-do list. My guess is that it will actually not make 1.1, that it will be delayed until 2.0 because of the massive refactoring required. Just guessing. The Barracuda docs say that the Event/Listener Model is the crux of the matter for leveraging MVC on the Web. Yes. Yes. Yes. Very True, IMHO. You screw it up, you lose. But also Very Difficult given the client-server division of labor in HTTP and the on-going Browser War. (Just one war, obviously.) It does seem wise to me that Struts should not make a hasty decision on its Event/Listener Model, but not past the point where it would break everything to put it in. When I worked on MVC apps in C++/Motif, we addressed this issue less generally, as Update Dependencies. We compiled the UD declarations into Mapping objects using a preprocessor. This seemed adequate for building lively apps and gave quite good performance, but Motif widgets had a much finer granularity of interaction in the application logic than do FormBeans. Of course, the Swing-style Event/Listener Model is much more run-time oriented in its approach than is a UD preprocessor. Java favors late binding. C++ favors early binding. It is a continuum. Each Framework needs to pick its spot on this continuum regardless of its implementation language. My guess, and it is just a guess, is that Struts will end up with some flavor of static UDs in the struts-config.xml, and that will be about the best you can do for HTTP Web apps. Barracuda will have to stick its hands very deeply into the DHTML mud to map the client-side events out to server-side objects. This is a mess. Once Barracuda is stuck there, then it falls victim to the "real" barracudas (the proprietary vendor interests) . If you need something very dynamic, very programmatic in your application's Event/Listener Model, then you need a different protocol than HTTP over the wire. Period. IMHO. Surely X-style "GUI Servers" will become part of the Web in due time. Same goes for Critrix-style "Terminal Servers". (Were it not for firewalls, this would already be true.) And if that doesn't happen, then look who's betting on SOAP (nee XML-RPC) to put events (as RPCs) on the wire. Clever marketing can easily morph SOAP into an Event/Listener Model on its own, eventually escaping HTTP altogether. Struts is wise to avoid this fray, for now. But, I'll bet that others in the Struts community feel strongly just the other way, that early engagement would be best. Maybe Barracuda has already done succeeded in mapping client-side events. ?? Dan Connelly ----- Original Message -----From: "Johan Compagner" <[EMAIL PROTECTED]>To: "Struts" <[EMAIL PROTECTED]>Sent: Tuesday, February 20, 2001 7:28 AMSubject: How does Struts compare to Barracuda? > Here is the link:
> http://barracuda.enhydra.org/Barracuda/
>
> Can we learn something from it?
> Is it better or worse?
>
> Johan
>
>
--
I've been trying to change the world for years, but they just won't
give me the source code....
begin:vcard n:Tataryn;Craig tel;home:952-884-6752 tel;work:952-842-5576 x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Division adr:;;3600 West 80th St. Suite 400;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Staff Analyst fn:Craig Tataryn end:vcard
