Since nobody else has replied yet... Frederic Daoud wrote:
In my experience, such attempts using JSP custom tags, JSTL, or whatever, have resulted in components that become too complicated, with a slew of attributes and values for those attributes, special cases, exceptions, etc. And, there is always something particular that isn't there.
That is often true, I agree -- but not always. It is difficult to strike a balance between "enough features to cover most of the use cases" and "few enough features to not scare people away." I guess my big class of counterexamples would be in the GUI world: the vast majority of GUI apps use the platform's menu and toolbar and radio button and scrollbar widgets rather than implementing their own from scratch.
In my opinion a lot of the "this component doesn't do *quite* what I want" reaction is from people building customer-facing web sites. There's a ton of intranet site development where the tolerance for not being able to tweak every microscopic aspect of the component can be a lot higher. In my years of web development I have heard quite a few requests like, "Build this set of web-based reports by the day after tomorrow. I don't care if it's pretty, I just need the numbers." That's the sort of case where you will be glad to save yourself the effort of implementing a sortable table even if it doesn't work exactly the way you'd prefer.
Also, there's some value in getting the ball rolling on a RIFE component library above and beyond the suitability of the components to particular use cases: a big component library is a good selling point for the framework as a whole and, as importantly, serves as documentation by example of how to use various features of the framework. If there are a bunch of well-known components, they can even be referenced from the official documentation as real-world examples, which are always valuable.
I'd just like to hear what others think. Of course, if we attempt such a component for RIFE, it would have to be well designed and easily customizable. At first thought, I would think this would be "easier" to accomplish because there is *more* in Java code than in templates in RIFE. Thus the "burden" of an API is less because of the richer facilities in Java code: Javadocs, auto-completion in IDEs, error detection at compilation rather than at runtime, etc.
The biggie to me is subclassing. I think an interesting design goal for a component would be to break it down into lots of little methods internally so that, if someone wants to customize the behavior of a component in a way that's not supported by its existing configuration options, they just need to override a method or two and implement the behavior they need. That is a technique that is more or less unique to RIFE; you can't really subclass a custom JSP tag in any useful way. I think if there is a set of clean, easy-to-follow examples of component that are customizable via subclassing, it'll get a lot of people's attention.
Of course, for that to be workable, the internals of the components need to be well-documented so that someone knows what the exact contract of each method is supposed to be and what other methods it'll be expected to interact with. Hopefully the code can be structured in such a way that you won't typically need to override core internal methods (main loops or whatever) but can instead mostly override leaf nodes of the method call tree. The burden is really on the people who write the first few components to make sure they get this right; subsequent components will imitate the initial ones. (No pressure!)
Anyway, to sum up, I think building a rich component library is an excellent way to show off RIFE's unique flexibility and make the framework more attractive.
-Steve _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
