Christian,
Do you have another link to
http://barracuda.enhydra.org/Barracuda/docs/tech_overview.html#Event_Delivery_Flow
?
The link on the bottom of the second paged reference to show how Baracuda flow
works, doesn't!
Dave
"Christian Cryder" <[EMAIL PROTECTED]> on 04/12/2001
12:38:07 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: David Hay/Lex/Lexmark)
Subject: RE: A quick Struts project post-mortem
Bryan,
> I am also interested in someone graciously providing a birds-eye view of
> Struts and Turbine, with relative strengths and weaknesses. I'm sure
You might check out these
http://barracuda.enhydra.org/Barracuda/docs/landscape.html
http://barracuda.enhydra.org/Barracuda/docs/events/sample_presentation_flows
.html
but keep in mind they're a little dated and may not provide the level of
detail you're looking for. If anyone can make these better please let me
know and I'd be happy to update it...
> I have a sense that the Java community needs something more than just
> a good MVC system in order to build an elegent (and robust) web
> application.
I would contend that there's a big difference between Model 2 (which is
"MVCish") and MVC (in the Swing sense, where you have strongly typed "model"
interfaces, etc). In Barracuda we're trying to provide both: Model 2 event
dispatching for flow control, plus strongly typed MVC UI components for
actually manipulating/rendering client views. Whether or not it yields
better mileage probably depends on your specific problem domain...
Christian
------------------------------------------------
Christian Cryder
[EMAIL PROTECTED]
Barracuda - Open-source MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 11, 2001 9:12 PM
> To: [EMAIL PROTECTED]
> Subject: A quick Struts project post-mortem
>
>
> I'm just wrapping up a fairly major project which was built on top of
> Struts (thereby giving me a chance to learn it). I'm a little mixed
> about the experience, not being entirely sure the value add was there. I
> definitely feel "helped" by Struts' form validation infrastructure, and
> I would probably appreciate the message resource bundling more if my
> application needed to be internationalized (which it didn't). On the
> flip side, the Action/ActionMapping system, while elegant, only covered
> about half of my application (since I had to write roughly as many
> custom JSP tags as I did Struts actions). Lastly (and this last comment
> is independent of Struts), I've come to the conclusion that a strict
> adherence to the MVC pattern is by no means a magic pill to perfect
> application manageability.. that is, plenty of worms still manage to
> crawl out of the woodwork, and I have a sense that the Java community
> needs something more than just a good MVC system in order to build an
> elegent (and robust) web application.
>
> The application was also based upon EJB, for even more fun and complexity.
>
> On the tags vs. actions dilemma - I took the approach recommended in
> various other publications etc., which is:
>
> 1. if the Java code will alter your Model, then put it in an Action (or
> equivalent).
> 2. if the Java code is only reading your Model to aid in rendering some
> portions of it, the put it in a custom JSP tag.
>
> Some quick metrics and "factoids" about my project:
>
> 1. 19 Struts actions
> 2. 18 custom JSP tags (for which I could find little in Struts to
> add value)
> 3. 15 ActionForms
> 4. 13 database tables
> 5. Since the application uses EJB session beans for all business logic,
> virtually all of the Struts actions as well as JSP custom tags ended up
> being very shallow pass-throughs of parameters to the EJB bean, and
> return values back to the JSP pages.
>
> I'm wondering if there are others out there who have finished projects
> and reached similar conclusions as mine (in particular, about having to
> implement lots of Tags and not finding much value-add in incorporating
> Struts classes into them).
>
> I am also interested in someone graciously providing a birds-eye view of
> Struts and Turbine, with relative strengths and weaknesses. I'm sure
> that, on the whole, Turbine probably has a completely different "central
> focus" than Struts (apples and oranges), but as someone who is just
> coming off a Struts project and is a bit daunted by the Turbine "welcome
> literature" (as I was initially with Struts), I would sure love
> someone's overview from a Struts-centric perspective.
>
> Lastly, I'm not leaving this group, as I am responsible for managing the
> lifecycle of the application I've described above, even though
> development is basically "done" (for now!).
>
> Thanks,
>
> Bryan
>
