struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Raible" <mrai...@gmail.com>
Subject Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Date Wed, 30 Aug 2006 19:20:28 GMT
On 8/30/06, Don Brown <mrdon@twdata.org> wrote:
> I think the bottom line is that you and I disagree on the fundamental
> issue on whether Struts should "just work" or whether it should
> encourage folks to "get to know it better".
>
> In this particular case, I feel since we provide the result in
> struts-extras, we should put the result configuration in the default
> configuration file.  Therefore, all the user has to do is drop in the
> jasperreports jar and they can immediately use the result.  This is
> especially important when they are using some sort of able-style
> autoconfiguration that doesn't require a struts.xml at all.
>
> In the JSF case, we should allow a user that wants to use JSF to get
> started immediately without any hassle.  Sure, the more advanced user
> will want, down the road, to perhaps pick a different JSF
> implementation, and that's fine.  However, for many beginning users, and
> even advanced ones at the start, we should work, out of the box, with as
> little extra effort as possible.  Even for advanced users, this lets
> them not have to learn everything about Struts all up front, but as
> their needs for new interceptors or different JSF implementations come
> up, they will be able to learn and do what they need.
>
> I guess what I'm saying here is that the Struts learning curve should be
> as flat as possible, allowing developers to ease into the framework
> without forcing them to learn about things like custom interceptors and
> results when they don't have the need for them.

IMO, everything should be configured to use JasperReports and JSF
out-of-the-box.  However, they won't be useable until the users
actually add the dependencies.

If you include MyFaces as a default dependency in pom.xml, I think
users will wonder what the heck is going on.

Matt

>
> Don
>
> Ted Husted wrote:
> > On 8/30/06, Don Brown <mrdon@twdata.org> wrote:
> >> As I've said previously, I disagree.  I think we should aim to work 100%
> >> out of the box.
> >
> > But, in the case of JSF and JasperReports, that's not an achievable goal.
> >
> > We can't distribute JasperReports, and I don't think we want to start
> > picking a JSF implementation for people. If they have to go to trouble
> > of obtaining the JARs, they can add a results element to the package
> > that uses the JAR.
> >
> > If we have to display a logging message as to why the result isn't
> > working, it's better to leave out the result, and let the developer do
> > his or her job.
> >
> > Again, we're talking about use case where it does not, and cannot,
> > work 100% of the box.
> >
> >
> >> By minimizing the amount of framework learning
> >> developers have to go through to use Struts, we enable them to get
> >> started quicker and spent more time figuring out how to solve more
> >> important, business problems.  Let's be honest - Struts is just one more
> >> library in probably 40 or 50 that they are using, we shouldn't assume
> >> they have the time or interest to learn all about how it works.
> >> Providing a library that "just works" shows we respect the developer's
> >> time.  Personally, I hate open source libraries that assume I have
> >> nothing better to do than learn their inner workings to make it do the
> >> most simple things.
> >
> > But, we are not talking about core functionality. We are talking about
> > support for third-party libraries, outside of our normal purview.
> >
> >
> >> > We can't distribute the JasperReports JAR, but in the case of JSF,
> >> > this is an ideal opportunity to demonstrate plugging in a new result
> >> > via the showcase application.
> >> The JSF support already has a section in the showcase application.
> >
> > Yes, and I added the JSF result to that package,.
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message