Hey guys, Long time without a peep from me, but I fully support a reusable component library for RIFE and would be more than happy to contribute as much as I can. It's been on my list of todos since Bevin added some code a few months ago, but I've just been swamped. I definitely do not have time to headup the project, but I might be able to contribute a few hours a week and would be more than happy to if someone else can spearhead the project. I'm working a 9-5 and another job at night right now, but I've got another developer I'm working with (finally YAY!) and I've convinced him that we should be working with RIFE. Basically, my time crunch should start including some RIFE code again and that should allow me to sneak some "reusable component library" time in, assuming there's a project head.
Cheers, Tyler On 6/21/06, Geert Bevin <[EMAIL PROTECTED]> wrote:
Hi Steven, just a small message to say that you're raising a couple of very interesting points and I agree with everything. With people like Eddy and Frederic starting to experiment with reusable RIFE components, I hope that an effort to build such a component library will soon start. While I really don't have time to actively work on that, I'll certainly look closely at the progress and give comments about the results and the approaches. Again, rifers.org is also there for any infrastructural needs. Take care, Geert PS.: I'll look over your wiki contributions later today, many thanks for those On 21 Jun 2006, at 08:26, Steven Grimm wrote: > 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 > -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
