|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
|
Message #204058
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Comparing Web Frameworks: RIFE
not sure how useful a read-only example of any framework is. I think it would be better to include at least one instance of the common problems developers face such as;
1. Validating input, e.g. make sure characters aren't been provided where an integer is expected
2. Binding request parameters to the correct target type, eg. converting request.getParameter("age") to an Integer called "age"
3. Provide a mechanism to provide exception messages to the input screen if validation fails
4. Forward down the pipeline if the input is valid.
5. Lookup a view for synchronous requests.
Obviously, there are more common patterns, but an example that incorporates at least that much would be more beneficial. Any developer could hack together a read-only example that looks attractive, but reading rarely throws up any suprises.
Geert: What was the final outcome for your request for feedback regarding the Rife templating mechanism?
|
|
|
Message #204059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparing Web Frameworks: RIFE
The reason why I did the comparison using Simon's set of requirements is that, although it doesn't tackle any interaction with the user, it does present you with the minimum entry point to use a framework.
The examples we've seen so far tell you how to do the most simple thing, a dynamic read-only site, using all the different frameworks. It's true that the strengths of each framework may be in different areas, but if you take the most simple case and compare them, you might get a sense of how difficult or how easy is a particular framework, using that minimalist entry point.
Having said that, I'm sure the articles will eventually expand to include other type of functionality.
|
|
|
Message #204061
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparing Web Frameworks: RIFE
Hi Analog Boy,
I totally agree, this type of use-case doesn't allow advanced framework to demonstrate their power very well. I specifically said that to Simon when he started this effort. However, after having written this article I do think that it has one particular benefit: you see the overhead of each framework solution clearly.
Independently from this, I started an informal 'competition' on IRC to implement a pastebin in Java using modern frameworks. I'm doing a RIFE version (http://rifers.org/paste) and someone else is doing a Wicket version (http://papernapkin.org/pastebin/app/home). Initially I had to catch up with my version, but now the other one is lagging behind. We still decided upon adding some Ajax features to easily add notes on top of existing pastes. When that is done on both sides I think that it will be a much more useful comparison application (but also more difficult to grasp). The source code of my version is already available, and I've been told that the Wicket version will be pushed out soon.
About the template syntaxes, we decided to add the Velocity-inspired version and the regular tags version since those, together with the existing syntaxes, seemed to cover most of the expectations and preferences. More info here: http://rifers.org/blogs/gbevin/2006/3/2/rife_1_4_released#1_4_highlight02
Best regards,
Geert
|
|
|
Message #204063
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparing Web Frameworks: RIFE
The goodness or madness of a framework depend in part of the type of application the your are developing, if you think in an framework as an final application with hole, the framework if good if the framework is like your desired application.
That is, if I need to develop business application with CRUD, batch processing, commercial reports, etc. the ability to create a blog with a framework is not matter for me.
Would be interesting a comparative of the same business application developed with several framework.
By the way you can compare the Booking Demo (a little business application) with 2 different frameworks:
- Booking demo with JBoss Seam
- Booking demo with OpenXava
|
|
|
Message #204065
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparing Web Frameworks: RIFE
Maybe it's just me, but I thought a large part of the appeal/usefulness of these articles was to have someone who was new to each framework figure out how to get started and build the example application. Having the framework author or a comitter do it seems to defeat the purpose a little bit.
And while we're at it....how come the Wicket and RIFE versions of the series get a TSS article but TSS didn't cover the fact that Simon (the originator of the series) put together a Stripes one over the last week ;)
-Tim Fennell
Stripes: Because web development should just be easier.
|
|
|
Message #204068
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparing Web Frameworks: RIFE
Hi Tim,
has someone submitted a news article to TSS about the Stripes version? Another thing to consider is that the Stripes version came only one day after the Wicket version. They always keep a certain lapse of time between posts at TSS before covering the same topic again. A week is a bare minimum and I think mine just got in because it's a slow news days and it's Friday.
Best regards,
Geert
|
|
|
Message #204070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
It took me about 2 weeks to get used to working with RIFE. I'll admit it is different than a lot of frameworks I've worked with before. I think a lot of people get turned off because it is so different, I almost was. Thankfully, I stuck it out, used Jumpstart (a GODSEND --trust me) and started digging into the framework. After two weeks, I was truely a RIFE zealot.
RIFE's power / flexibility is amazing. The concepts are disruptive and in my opinion exactly what web frameworks needed. RIFE truely inovates instead of following the norm.
I HATED web development (I'm not kidding at all), but after 2 weeks with RIFE I started making a lot of web projects that I'd put off for months or years. All I can say is, when you figure out why RIFE does things the way it does, you'll never want to look at another Framework (At least until they start copying RIFE).
All the best,
Tyler
|
|
|
Message #204079
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparing Web Frameworks: RIFE
Maybe it's just me, but I thought a large part of the appeal/usefulness of these articles was to have someone who was new to each framework figure out how to get started and build the example application. Having the framework author or a comitter do it seems to defeat the purpose a little bit.
+1
|
|
|
Message #204090
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Just do Pet Store -- A challenge for all these frameworks...
Ok, so Pet Store isn't sexy, and it's kinda old and boring....but....
It's the defacto example app. It has unique presentation characteristics that allow the web framework to really be tested.
I'd challenge these teams to best the current Struts based JPetStore 5 (to be judged by this community). JP5 is unit tested, well layered and CSS/XHTML for the most part. It comes with a build file and deploys in one step.
If you want to show us something, show us you can beat Struts...
JPetStore 5 is available here: HERE
Feel free to download it, strip out the presentation layer and replace it with your own.
Don't tell me it's too much work. ;-)
I wrote the original in a couple of weeks. Our RBatis contributor recently reimplemented the ENTIRE petstore implementation with Ruby/Rails in about 7 or 8 days....you should be able to do the presentation layer in far less time...
Cheers! :-)
Clinton
|
|
|
Message #204091
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Pastebin competition? What a joke...
Independently from this, I started an informal 'competition' on IRC to implement a pastebin in Java using modern frameworks. I'm doing a RIFE version (http://rifers.org/paste) and someone else is doing a Wicket version (http://papernapkin.org/pastebin/app/home). Initially I had to catch up with my version, but now the other one is lagging behind.
I think the reason why Wicket pastebin is 'dragging behind' is because you are the only one in this 'competition' :)
We set out to build a simple pastebin that we can deploy on our intranets, and we did. As far as I know there are no plans for any bells and whistles.
|
|
|
Message #204093
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
PS: The wicket implementation is already underway...
The wicket implementation is already underway...(not by me)
|
|
|
Message #204095
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Pastebin competition? What a joke...
only one in this 'competition' :)We set out to build a simple pastebin that we can deploy on our intranets, and we did. As far as I know there are no plans for any bells and whistles.
Oh dear, that was meant as a joke, please don't take it badly.
I just wanted to see how easy it was to do in RIFE and then kinnabalu (IRC nick) reused my syntax highlighting code and said that he wanted to add diffs and private pastebins too. We then just discussed that it would be a nice comparison app and what could be done else as useful features (ie. the Ajax stuff). This really just a friendly thing and of course not a 'competition'.
|
|
|
Message #204099
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
All I can say is, when you figure out why RIFE does things the way it does, you'll never want to look at another Framework (At least until they start copying RIFE).All the best, Tyler
I've been having the same kind of experience with XWork/WebWork. RIFE, Stripes are also on my list of "these are worth looking into".
My question is: let's say you "get" a certain framework, and you're loving it. That's fine for your own webapps, but how do you "sell" this within an environment of co-workers? What if your co-workers aren't as "passionate" as you (read: willing to invest a bit of time and effort)? Then they'll never "get" it like you did. Anyone else ever deal with this kind of problem?
Another question: do you think that the "lock-in" a framework imposes is a valid point to consider when evaluating your options? Meaning, if you write a webapp using framework A, then decide to use framework B for whatever reason, are any parts of your webapp reusable? Or is this not a valid point?
For example, what I find attractive with XWork/WebWork so far is that XWork is actually totally independent of WebWork. So, you could define your actions, results, validation, type conversion, etc. using XWork and reuse them in any context, not just a webapp.
Another example: Stripes is pretty "lightweight" in that it keeps things simple and basically does the wiring of parameters, requests, responses, views, etc. for view in a simple way. If you, like me, don't like JSPs, you could easily use FreeMarker instead and the rest still works beautifully.
On the other hand, I would call Tapestry, Wicket, and RIFE "total" solutions in the sense that you have to commit to using all or nothing. This isn't necessarily a bad thing. However, I find it interesting to have the possibility of defining the "navigation" between actions, results, etc. independently of the web app. I imagine RIFE offers this too - does it? I mean, can "wiring" elements, parameters, navigation, etc. together be done independently of the web app? Because I really like the idea that RIFE promotes, i.e. to build small blocks and wire them together. I'm wondering if you can do this and stop before the "template" part, say if you want to reuse this in a standalone application..
I'll end with my standard disclaimer: This post is meant to discuss technical issues with you because I'm interested in reading what you think. No criticism is meant, and please don't start any flame-wars over this.
Many thanks,
Frederic
|
|
|
Message #204101
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
Hi Frederic,
a number of very good points in your post. Indeed the adoption of any technology entails a certain amount of lock-in. It's always the same dilemma, either you decouple to death and try to isolate as many reusable parts as possible, either you just embrace technology and get on with it. Whatever you do, it's your architected or project's manager decision to do so and the team follows. Any technology whatshowever is bound to have its proponents and opponents. I think that the best way to decouple is at your domain model, and keep it as clean as possible, and that's what RIFE promotes. For the implementation of your application logic and view logic. This is entirely up to you. You and your team make (or don't make) the choice of decoupling reusable services and DAOs from the actual implementation that is bound to a framework. As such, I think that the adopting of sensible application development patterns probably gives you the less lock-in.
The wiring of the components in RIFE are related to web development and that's also its strength. We don't try to abstract away too much and too far. A standalone application is totally different from a user and a design perspective than a web application. State management is mostly a non issue, as is navigation. That's why we focus on making those as good as possible for web development and let RCP offer you the environment you need for standalone applications. However, everything besides the web engine in RIFE's full stack can be used by standalone applications and are being used. From mobile phones to standalone swing apps to webstart apps, they can all get a lot of benefit from RIFE's approaches.
Best regards,
Geert
|
|
|
Message #204110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
I find it interesting to have the possibility of defining the "navigation" between actions, results, etc. independently of the web app. I imagine RIFE offers this too - does it? I mean, can "wiring" elements, parameters, navigation, etc. together be done independently of the web app? Because I really like the idea that RIFE promotes, i.e. to build small blocks and wire them together.
Just how standalone is this? It would be neat if we could integrate more nice modular features of other frameworks with Wicket where possible to give people more choices. We already did this with Velocity and Freemarker by making template rendering Panels. If there's an opportunity to do this with RIFE or other frameworks to achieve some neat effect(s), that would be cool.
|
|
|
Message #204252
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Just do Pet Store -- A challenge for all these frameworks...
FWIW, Spring has been shipping a JPetStore variant since Spring 1.0. It's part of the framework distribution alongside other samples. The sample app chapter of "J2EE Development without EJB" (Wiley, 2004) discusses the general characteristics from an architectural perspective.
The Spring JPetStore is actually based on Clinton's iBATIS JPetStore, adding Spring management of the service layer and the data access layer. In particular, it illustrates Spring's iBATIS DAO support in combination with various declarative transaction demarcation styles.
In the web user interface, the Spring JPetStore features a Spring Web MVC layer as direct alternative to the Struts MVC layer. This can serve as basis for a direct comparison, in particular since the switch between those two web tier options is as simple as a config line in web.xml.
Isn't it amazing that we're still discussing Java pet stores in 2006? Personally, I'd welcome the fresh breeze of a completely different sample app... But what can you do in the face of a de-facto standard ;-)
Juergen
|
|
|
Message #204321
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
Hi Geert,
Thank you for your reply.
It's always the same dilemma, either you decouple to death and try to isolate as many reusable parts as possible, either you just embrace technology and get on with it. The wiring of the components in RIFE are related to web development and that's also its strength. We don't try to abstract away too much and too far. A standalone application is totally different from a user and a design perspective than a web application. State management is mostly a non issue, as is navigation. That's why we focus on making those as good as possible for web development and let RCP offer you the environment you need for standalone applications.
You're right. At some point you have to get down to the concrete stuff and get it done. I understand your point about web applications being different from standalone ones.
Also, we have to beware of YAGNI (Ya Ain't Gonna Need It.) In my case, I did need it - I have an application that I want to run as a webapp and as a standalone app, reusing as much as possible so that it's only the GUI parts that are different. But, that's not really my point. Most of the time, it's true that you ain't gonna need it. Even so, I like the idea that, while I'm developing a web app in a "bottom-up" fashion, none of my code "knows" about the web app part until I actually get to the UI. So, there's the database, model objects, services and DAOs, etc. Then there are actions, requests, or events, whatever you want to call them, with validation of the inputs. Even this doesn't have to be "web app aware". I can unit test all of this easily, and thus when I actually get to the web app I'm pretty confident about everything that's underneath.
I think that the best way to decouple is at your domain model, and keep it as clean as possible, and that's what RIFE promotes. However, everything besides the web engine in RIFE's full stack can be used by standalone applications and are being used. From mobile phones to standalone swing apps to webstart apps, they can all get a lot of benefit from RIFE's approaches.
This seems to fit exactly what I'm talking about and what I would expect from RIFE from what I've seen so far. So, although you say that wiring of elements is related to web apps, I'm assuming that all of the elements in the "middle" do not need to be "web app aware", only the UI elements.
Well, I know I have to go and do my homework and that's what I'll do.
Thanks again Geert for your response.
Frederic
|
|
|
Message #204324
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
Just how standalone is this? It would be neat if we could integrate more nice modular features of other frameworks with Wicket where possible to give people more choices. We already did this with Velocity and Freemarker by making template rendering Panels. If there's an opportunity to do this with RIFE or other frameworks to achieve some neat effect(s), that would be cool.
Jonathan,
I'm not sure yet how standalone it is. So far I've only tried XWork. I have yet to explore RIFE in that capacity. I can tell you that with XWork, it's standalone in terms of defining actions, their inputs, the validation of the inputs, type conversion, and returning generic results that are open to be wired as you wish.
Perhaps an example would be clearer. Say I define an Action to create a User. I can define the inputs as being First name, Last name, and age. I can define the validation of those inputs (required inputs, type conversion for the age, valid range for the age, etc.) Then, in the action, I can perform the work and return a result, which in XWork is a String (e.g. "input" to indicate that the input needs to be corrected, or "success").
Now, it's up to the client code to wire the "input" and "success" results to a view. So this could be a simple output to the console for a standalone test, a MockResult for a unit test, an HTML view in a web app, etc.
Of course, the way to specify the input to the XWork action and the way to retrieve the validation results are XWork specific, but this can all be abstracted away in a service, much like a DAO.
Obviously, WebWork integrates with all of this directly. Still, it would be possible to write some code that bridges this with another web framework. I'd like to try this to see if it's practical.
I wonder though, how would this fit in with a component-based framework such as Wicket? Does the "action/result" nature of XWork conflict with the "component/event" model used by Wicket? Or could an event simply be wired to an action, and the result wired to a view?
The reason I'm exploring all of this is that, like you said, it would be cool to write some code that defines actions, validations, and results -- all the middle stuff -- and be able to plug in the web app part on top, and be able to change that web app part to use another framework (because you're like me and you like trying them out) while reusing that middle part that shouldn't really need to change.
|
|
|
Message #204332
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
it would be cool to write some code that defines actions, validations, and results -- all the middle stuff -- and be able to plug in the web app part on top, and be able to change that web app part to use another framework (because you're like me and you like trying them out) while reusing that middle part that shouldn't really need to change. I guess you are Jacob's client ;-)
|
|
|
Message #204374
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
I think it would be neat to have more reusability. To achieve that, however, I think you have to make something that is completely separate from the environment it runs in. For example, I think you COULD make a completely generic validation framework that could be plugged into any stateful, object-oriented web application. Where reusability falls down is when people start to deviate from the OO path, and I'm afraid that encompasses an awful lot of what's going on in the Java web space right now. If you've made a framework that's not truly object oriented, reuse is going to be extremely difficult. Getting frameworks to deal with simple Java objects is a first step towards reuse. Once you have that, you can start to think about "what does validation mean in the abstract?" and "how can i create a validation framework that is totally independent of its usage context?" That might be worth doing once we get there. I'm not convinced we are there yet though. What I was hoping was something more along the lines of coarse granularity reuse, where RIFE is encapsulated completely with a few simple requirements of its container and we can embed RIFE in a Wicket Panel. It doesn't sound like that's possible.
|
|
|
Message #204377
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
Hi Jonathan,
RIFE's validation framework and meta data handling through constraints is totally POJO driven and can be used within any context. The web engine and site structure is bound to our Request and and Response interfaces though (which you can however implement anywhere too, this is how we achieve out of container testing, through MockRequest and MockResponse)
Best regards,
Geert
|
|
|
Message #204380
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
Is there a build of the validation framework that works without RIFE?
|
|
|
Message #204424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
No, just download RIFE, it's one jar without deps and only 2MB.
|
|
|
Message #204548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIFE from a new user standpoint
No, just download RIFE, it's one jar without deps and only 2MB.
I'm starting to "get" RIFE, and liking it more and more.
It is really clean. Most frameworks use "tricks", which can be good but become evil with increasing complexity. So far I find RIFE to be intuitive, consistent, and mostly "trick-free".
More on this later, on the RIFE site itself.
Congrats Geert and the RIFE team!
Frederic
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
