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.
Don
Ted Husted wrote:
On 8/30/06, Don Brown <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
