Hi John,
1. If RIFE is really all it appears to be (e.g., a complete answer
to the questions Ruby on Rails has posed to the Java community),
how come it is not more widely used? It is still a very minor
player (whether or not this is justified). I was wondering why this
might be. Could it be to do with its Belgian (i.e., non-US) origins?
People have said this to me before, but I don't think that's the real
reason. Of course any answer to this is pure speculation, but as it
turns out I talked about this very issue with Bruce Tate (Beyond Java
author) and David Heinemeier Hansson (Rails' creator).
This is what Bruce says about it : "I push RIFE every other weekend
or so, when I do the nofluffjuststuff symposiums. I also pointed <big
name> toward your frameworks. Usually, the biggest fear is that the
project wouldn't get too far without you, so they view it as risky.
I'd really work hard toward Spring integration, and work on ways to
hide that integration from the user."
My remark to David: "I fear though that not many people doing Java
are open for the 'quick results without a headache' approach unless
they totally switch over to another language or platform. RIFE
walking a middle road doesn't help much for its adoption though, but
that's another story ;-)"
His response: "I think that's a very precise analysis. As long as
people are in denial of a world outside, Struts will seem like the
only way. And a rebel framework like RIFE stand as little chance as
Rails. But as soon as they open up, I think they want to distance as
much as possible (and thus Rails provide the exact opposite of the
Struts in a lot of ways)."
I personally think that RIFE is in a difficult position for both
people coming from Java and people coming from PHP.
Those who come from Java are usually tied to the frameworks they
already chose and thus very often can't switch to another view on the
problem nor another technology stack. If they choose to change, they
tend to go for the solutions that already have a large user-base (if
100000 people chose it, it can't be bad). Even if they don't get the
nicest solution, they at least get one that works well enough and has
a pool of knowledge that can be capitalized on. If they choose to
change radically, then the memory of the over-zealous complexity of
what they already used drives them as far away from Java as they can:
RoR.
Those who come from PHP are used to a scripting language and know of
a lot of the monstrous Java-based setups and their complexity. They
don't risk getting close to it and go towards RoR instead.
A last part that plays against it is that while RIFE aims to provide
as much productivity and development fun as possible, we value
maintainability and clarity above that. This means that there is a
site-structure as a central point of declaration with the data and
logic flow inside it. Several people already told me first hand that
when they read the features, they loved what they read, but once they
saw the site-structure they remembered the XML declarations of other
frameworks and concluded that it was just a variation on the same
theme, without looking at what is really done in there.
2. How long do you think it would take a reasonably experienced
Java developer, who has worked mainly with the Struts/Spring/
Hibernate approach to web apps, to get comfortable and productive
with RIFE's very different way of thinking/working?
Depends on what you're doing. RIFE is setup (jumpstart) so that you
can start right away without having to plan, configure and setup a
whole collection or things before you even try something out. So,
getting your first results is almost instantaneous and, as Eddy says,
within a day you'll have something going. The next stage is a bit
more difficult though, since RIFE does a number of things totally
differently from what you already know: no servlet-side sessions,
logicless templates, declaration of data-flow, url == state, ... I
have never been in the situation of having to learn that (since I
designed the features), but most people just need time to get the
"aha!" feeling. Once they've switched to the mindset we rarely get
any questions, except for bugs, holes in the documentation, missing
features or complex aspects of the framework.
3. Are there any tips anyone could give me about how to start
'thinking in RIFE'? I.e., how to approach the design of a web
application with RIFE in mind. Perhaps something along the lines of
planning it as a flow diagram, thinking of possible exits from each
page view?
Some things have helped people lately:
* the URL drives a RIFE application: URL == state
* the templates don't drive the pages: they are logicless blueprints
When I begin with a new app, I start from the jumpstart and write a
simple version of my domain model first. I add RIFE/Crud to get an
instant admin interface to be able to easily populate the application
with data. Then, either I customize the Crud behavior or write some
custom elements. From there on, I extend iteratively and add tests to
ensure that the application continues to behaves as intended.
I hope this helps,
Geert
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
