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
