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]
