Waffle is another web framework attempting to bring coding by convention into Java.

Configuration is done through an annotated Registrar implementation, which has a single reference in the web application's configuration file. Events in the framework are routed to specific methods in classes called "Actions," which makes it seem like an annotated Webwork of sorts.

The home page for Waffle does not, as of this writing, actually have a link to be able to download Waffle; however, it can be downloaded from the Sourceforge project page.

This is another entry in the "coding by convention" group of web frameworks; while this is quite the norm in Ruby nowadays (with Rails), does Java need another web framework attempting to fill the same space?

Waffle is another web framework attempting to bring coding by convention into Java.Configuration is done through an annotated Registrar implementation, which has a single reference in the web application's configuration file. Events in the framework are routed to specific methods in classes called "Actions," which makes it seem like an annotated Webwork of sorts.The home page for Waffle does not, as of this writing, actually have a link to be able to download Waffle; however, it can be downloaded from the Sourceforge project page.This is another entry in the "coding by convention" group of web frameworks; while this is quite the norm in Ruby nowadays (with Rails), does Java need another web framework attempting to fill the same space?

At first I figure this was the ruse, given the date. But then I went to the site and there were actual tutorials. If this is the joke, someone spent a lot of time setting this one up. Perhpas time better spent else where like positng silly opinions on TSS (like this one).

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

With a name like 'Waffle' I thought this had to be an April fool... but apparently its not. Not sure if the negative connotations to the word 'Waffle' extend across the atlantic (or elsewhere) but here in the UK I could never imagine trying to get management agreeing to use a framework called 'Waffle'.

I looked at Waffle as it was mentioned in the Grails thread. I don't see what is "Rails like" at all. What am I missing? It looks like just yet-another java configuration-light/less framework - of which there are now many to choose from. But to call it "Rails like" is way over the top.

From the Waffle "Actions" section:

public class AutomobileAction {
  private Car car;

  /**
   * This should be considered a Request level action because it has a dependency
  * on a HttpServletRequest object.
  */
  public AutomobileAction(HttpServletRequest request) {
    car = (Car)request.getAttribte("Car"); //typo, btw
  }
}

Just my opinion. I think a web framework should take care of dealing with the Servlet API for you. You _can_ get to the HttpServletRequest object if you need to, but most of the time, you don't.

I looked at 9 other web frameworks before deciding which one to use for my next project, and none of them had any HttpServlet* objects in their API method signatures.

From the Waffle "Actions" section:public class AutomobileAction {  private Car car;  /**   * This should be considered a Request level action because it has a dependency  * on a HttpServletRequest object.  */  public AutomobileAction(HttpServletRequest request) {    car = (Car)request.getAttribte("Car"); //typo, btw  }}Just my opinion. I think a web framework should take care of dealing with the Servlet API for you. You _can_ get to the HttpServletRequest object if you need to, but most of the time, you don't.I looked at 9 other web frameworks before deciding which one to use for my next project, and none of them had any HttpServlet* objects in their API method signatures.

+1

First of all I'd like to say that I really appreciate the feedback on Waffle. I just wanted to make a clarification to your point. The Actions in Waffle are simply POJO's, there is _not_ a strict API that they must follow. The example you posted from the Waffle web site explains how you can use Constructor based Dependency Injection when you are instantiating Actions. HttpServletRequest, HttpSession and ServletContext could be passed as arguments to your Actions constructor only if you wish, but it is not required. Typically your Actions would be built with specialized components (i.e. DOA's, Factories, Services), which would be passed directly to your Actions constructor.

Take a look at Waffle events to see how attributes from your applications request, session or application context can be passed directly as method (event) arguments:

http://waffle.sourceforge.net/events.html

Also, thanks for pointing out the typo.

Mike,

Thanks for the clarification that you provided. The event mechanism to which you referred me is an interesting one.

By the way, when I first visited the Waffle page, I noticed that there was no direct download link in the menu items on the left, as Joseph mentioned above in his original post. I eventually found it by going to the Sourceforge project page, but it might be a good idea to provide a direct link in the menu.

One last comment, I like that you've left the view open for flexibility in that you can use FreeMarker or Velocity instead of JSP if you wish, and that it is SiteMesh/Tiles compatible. That's a plus.

Cheers,
Frederic

Like Martin Fowler once said here:

http://forum.mentaframework.org/posts/list/160.page

Programatic configuration is the way to go. What you guys are trying to accomplish with AbstractRegistar, was accomplished 9 months ago with Mentawai:

http://www.mentaframework.org/styles.jsp

IMHO (In my HUMBLE opinion), convention for the view layer, in other words, trying to guess page names, consequences, etc by convention, has very little value in practice. Maybe for small projects it will work, but for anything more serious it will fail, requiring the human intervention to configure the pages.

The problem is not the configuration itself, but how it is done. In my humble opinion, and maybe on Fowler's opinion too, programatic configuration is the way to go.

Mentawai also supports configuration through Beanshell:

http://www.mentaframework.org/configuration.jsp

Support for JRuby, Jython and Groovy is coming.

What some people are saying about Mentawai:

" This site, with Mentawai and pBeans, was a completely different experience. I've loved both, especially Mentawai. It is just powerful enough to do what it is supposed to do, and simple enough not to get in the way of getting the job done."

Give it a try with Mentawai and we do have a very active forum in our website were comments and questions are welcome.

http://www.mentaframework.org/

(In my HUMBLE opinion), convention for the view layer, in other words, trying to guess page names, consequences, etc by convention, has very little value in practice. Maybe for small projects it will work, but for anything more serious it will fail

I disagree entirely. Convention over configuration can actually work wonders. With modern IDEs it's often easier to move a class or rename it than it is to hunt around in configuration files and change it's URL (for example). Some major benefits of using convention for URLs (for example) are: 1) when looking at a URL it is immediately obvious what class is responding and vice-versa (with configuraiton it's up to developers to follow a convention and then type it out). 2) You can change your entire application's URL strategy by simply changing the convention/inference without the need to edit everything.

The problems with centralized configuration in code is the same as in XML for me: it's still easy to make typos (there's lots of strings in there), and there's still a file over which lots of developers will contend and inevitably create merge issue.

-Tim Fennell
Stripes: Because web development should just be easier

You have a good point. The truth is: these alternatives are always subjective.

Just one question:

- How to guess if you want a forward or a redirect ???

In Waffle this is handled very easily. If your Event returns a View instance you'll be forwarded, if your return the sub-class RedirectView Waffle will do a redirect.

This is the default behaviour. This can be altered by plugging in a different EventResponseHandler. Have a look at the pluggable documentation on Waffle's site.

http://waffle.sourceforge.net/pluggable.html

Ok!

May I ask just another question:

- My application has the page welcome.jsp. Many actions from my application can send me back here, in other words, a SUCCESS from action1 can take me back here, a SUCCESS from action5 can take me back here, etc.

Convention for the view will kill me here, won't it ? Will I have to place a forward or redirect inside the following pages:

action1.success.jsp

action5.success.jsp

My point is that I really want to explicit say:

success for action1 goes to redir welcome.jsp

success for action5 goes to redir welcome.jsp

See my point?

May I ask just another question:

- My application has the page welcome.jsp. Many actions from my application can send me back here, in other words, a SUCCESS from action1 can take me back here, a SUCCESS from action5 can take me back here, etc.

Convention for the view will kill me here, won't it ? Will I have to place a forward or redirect inside the following pages:

action1.success.jsp

action5.success.jsp

My point is that I really want to explicit say:

success for action1 goes to redir welcome.jsp

success for action5 goes to redir welcome.jsp

See my point?

This is simply a wrong, wrong, wrong, wrong, wrong pattern, though very popular. Action/ActionForm handles events and updates model for a particular web resource. JSP page renders a resource. A resource can have several views, thus one Action/ActionForm pair can have several JSP pages that *belong* to it.

Forwarding to a page that does not belong to a particular resource and then submitting to an action that services yet another web resource is a bad pattern. It produces convoluted relationships between actions and pages that some call "page flow". Then they use fancy GUI tools and huge XML descriptors to visualise and define this mess. Yuck.

http://wiki.apache.org/struts/DataEntryForm

This is simply a wrong, wrong, wrong, wrong, wrong pattern, though very popular. Action/ActionForm handles events and updates model for a particular web resource. JSP page renders a resource. A resource can have several views, thus one Action/ActionForm pair can have several JSP pages that *belong* to it.Forwarding to a page that does not belong to a particular resource and then submitting to an action that services yet another web resource is a bad pattern. It produces convoluted relationships between actions and pages that some call "page flow". Then they use fancy GUI tools and huge XML descriptors to visualise and define this mess. Yuck.http://wiki.apache.org/struts/DataEntryForm

You said a bunch of beautiful things, but you did not say anything related to our problem.

We are talking about page convention for views. Something like: /myaction.success.jsp.

The problem is, and I am sure this is common and desiable: many different actions will lead you to a single jsp page (welcome.jsp).

My concern is that page convention will be useless here and we will have to explicit configure by hand. But I may be wrong...

(About forward and redirect I kind of agree with you, but some people won't. It is not that uncommon to change a forward to a redirect and vice-versa in the development phase.)

We are talking about page convention for views. Something like: /myaction.success.jsp.The problem is, and I am sure this is common and desiable: many different actions will lead you to a single jsp page (welcome.jsp).

I said up above that I think convention is a good thing for URLs...and hopefully from the context it was clear that I meant action URLs. E.g. you have a class, it gets bound to a URL, and convention works nicely here.

What I didn't say (and didn't think I needed to ;) is that I think convention for the action->view mapping is a bad idea. In most non-trivial applications there will be a multiplicity of strategies - an action that manages multiple views, an action that manages a single view, two actions which work together to manage a view etc. Convention needs to work 80-90% of the time to make it useful, and it doesn't here.

I also agree with Michael that changing a forward to a redirect is a change that would generally involve some changes in application logic and some testing. In which case changing configuration so you don't have to rebuild seems to be a non-saving. I'd constrast that "saving" against having to dig around in multiple places just to put together what a given action is doing and what views it is rendering.

Another good example of convention over configuration (or lack thereof): one of the examples (honestly, I forget which framework it was from) had code registering a DateConverter for a string field name. This despite the fact that there was a Date property kicking around with the same name. Type conversion is an area that is crying out for convention. And with generics you can determine nearly all conversions by reflection (yes, this *is* convention). Annotations work nicely as the override mechanism whereby you can simply declare a different conversion if the default one doesn't work.

-Tim Fennell
Stripes: Because web development should just be easier.

I said up above that I think convention is a good thing for URLs...and hopefully from the context it was clear that I meant action URLs. E.g. you have a class, it gets bound to a URL, and convention works nicely here.What I didn't say (and didn't think I needed to ;) is that I think convention for the action->view mapping is a bad idea. In most non-trivial applications there will be a multiplicity of strategies - an action that manages multiple views, an action that manages a single view, two actions which work together to manage a view etc. Convention needs to work 80-90% of the time to make it useful, and it doesn't here.

I agree 100% with you here. You defined very well what I was trying to do. Some people brag to much about this type of CoC. Isn't RoR based on this, too?

one of the examples (honestly, I forget which framework it was from) had code registering a DateConverter for a string field name. This despite the fact that there was a Date property kicking around with the same name. Type conversion is an area that is crying out for convention.

Agree, too!

Most of this discusion comes down to taste: I would rather have my configuration together in one single place, instead of scattered through the actions. I would have configure the action url - > action class, because since I am already defining my action and its filters, consequences, pages, etc. I don't mind going ahead and defining the URL "/Register" -> RegistrationAction.java. (I agree that if I make a type I am screwed, but I can live with that!). I would definetly rather configure the jsp pages myself instead of using conventions. I would rather leave my actions as thin and dumb as possible.

You said a bunch of beautiful things, but you did not say anything related to our problem.

We are talking about page convention for views. Something like: /myaction.success.jsp.

The problem is, and I am sure this is common and desiable: many different actions will lead you to a single jsp page (welcome.jsp).

I think what I said was relevant. "/myaction.success.jsp" belongs to "myaction", I am ok with that. It also can be "/myaction.edit.jsp", "/myaction.view.jsp", "/myaction.badstate.jsp".

I said, that "many different actions" should not lead to a JSP page. In your case of "welcome.jsp" these actions should lead to "welcome.do" or how do you call your actions.

It is not just simple prepending of view with an action. It is a different concept. Instead of rendering a view of another resource, you forward (or redirect) to that resource and it renders itself. You don't care what is exactly rendered there, the resorce does. This makes resources less dependent (ideally, independent) on each other. Also, because a view is always rendered by one and only one action, you can make sure that all necessary output data is prepared accordingly.

In Waffle this is handled very easily. If your Event returns a View instance you'll be forwarded, if your return the sub-class RedirectView Waffle will do a redirect.This is the default behaviour. This can be altered by plugging in a different EventResponseHandler. Have a look at the pluggable documentation on Waffle's site.http://waffle.sourceforge.net/pluggable.html

Just some thoughts: I think FOWARD or REDIRECT should be something in your configuration, not hardcoded in your code. If you later decide you want a forward instead of a redirect, than you need a full rebuild of your application.

Since you are using annotation for configuration, you will have to do it anyways and always.

This will be a big deal for some people and for other people this will be ok.

Just some thoughts: I think FOWARD or REDIRECT should be something in your configuration, not hardcoded in your code. If you later decide you want a forward instead of a redirect, than you need a full rebuild of your application.

Why would you change forward to a redirect? It webapps forward vs. redirect is a decision that affects application design as well as user experience. These decisions should be made once at the early stage of development.

I disagree entirely. Convention over configuration can actually work wonders. With modern IDEs it's often easier to move a class or rename it than it is to hunt around in configuration files and change it's URL (for example).

I have a sneaking suspicion that's why Mentawai puts configuration in a Java class that can be checked by the compiler and refactored by the IDE.

I have a sneaking suspicion that's why Mentawai puts configuration in a Java class that can be checked by the compiler and refactored by the IDE.

This is just one advantage of programmatic configuration over static XML/Properties configuration.

Although the configuration syntax will be taken care by the IDE and you are free to refactor, create methods, inherit, do loops, ifs, and this kind of stuff that only a programmatic configuration will give you the freedom to do it, the NAMES of the pages (welcome.jsp) etc will be there as strings and the compiler/ide cannot do much about it, meaning, if you make a type you are in trouble.

However, and don't think that's a big deal and I do like to explicit configure my view, due to the issues I have described above. But I understand that this is a subjective question. (Let's see how would we solve the common problem of many actions leading to the same page) In this case I think you would probably have to explicit configure your view.

There is no reason not to have both. Imo, any decent API should be layered enough so that even if it uses static xml/ properties files and does tricks like name matching, that should be build on top of some API construction.

There is no reason not to have both. Imo, any decent API should be layered enough so that even if it uses static xml/ properties files and does tricks like name matching, that should be build on top of some API construction.

Eelco: I think that's a given for any quality framework. But I also think that (randomly made up number over 50) 90% of developers won't investigate how to change the strategy, and will simply use [one of] the ones provided in the framework distribution.

-Tim Fennell
Stripes: Because web development should just be easier.

Eelco: I think that's a given for any quality framework. But I also think that (randomly made up number over 50) 90% of developers won't investigate how to change the strategy, and will simply use [one of] the ones provided in the framework distribution.

Sadly it's even worse. It's one of the most difficult problems that I'm struggling with for RIFE. In fact, the framework doesn't care a single bit how you declare this configuration since the Java builders can be used directly or any of the provided declarative wrappers (XML, Groovy, Janino, RIFE/Crud, ...), you can even mix and match seemlessly.

However, no matter how many times I explain this, people look at one particular example (any example) and think that things can only be done as they see in that code snippet, and they label the entire technology according to this.

So, it doesn't matter which ones the framework provides, it matters which one is used in the first exampes that people will look at! If you can think of a good way to bring the concept of alternatives across to people, please tell me, I seem to fail to do this properly.

Sadly it's even worse. [...]

However, no matter how many times I explain this, people look at one particular example (any example) and think that things can only be done as they see in that code snippet, and they label the entire technology according to this.

It is really sad that it's the truth. As you could see above I fell into that exact same trap with Waffle. I looked at the very first code snippet from the main page, saw an HttpServletRequest parameter in a method signature, and thought, "great, we're going backwards here, having to deal with HttpServletRequest? No thanks." and I turned away. I did exactly what you described, wrongfully so.

If you can think of a good way to bring the concept of alternatives across to people, please tell me, I seem to fail to do this properly.

Not easy. Maybe it would help to list this "choice of configuration mechanism" as one of RIFE's features right up front in the main page? And have it blink in bold red font? (OK maybe not.) But, hopefully people see it on the first page, and perhaps it could link to a doc. page that describes this feature, the different supported configuration mechanisms.

Kind of like what you did to show the different template syntax alternatives.. I think people know about those now.

Frederic

"Forward vs Redirect " is a basic design in MVC Framework, a Rails-like web framework should be more high-level, Jdon Framework is a Rails-like web framework too, the page flow is based in Struts 1.2,https://sourceforge.net/projects/jdon/

Hi Friends, I just came across this waffle. And looked at the samples and examples. By the way in the past three years I have used many frameworks including Rails, sumfony, Django, Struts, Spring and Grails. And I found that they all trying to do something similar for different or same languages. That's fine and it's okay. Rather I have a concept (actually proof too) about having a new framework which will simple and provide the clean MVC (by conventions - can be overridden) and the eclipse like plugin based scalability. The concept is that the framework (I called it as "Fame" for now) will hold the layout and core plugin management classes and MVC classes. What user has to write a new plugin (actions, jsp's and plugin.xml- perspective, css, js) and start using it. I have made it working and written couple of plugins to it to prove the concept. At a one instance of the session one plugin can be active with one perspective. There is lot more to say about it but unfortunately the project is not sponsored and I alone can't bear the cost of making it live and public. But I need help from the community. I want the help in terms of improving it and making it known to the people. Once it's known to the public the growth of it may be in n-directions than only 1 for now. I alone can only think up to certain boundary so can't be perfect, so I need your help. I would like to share it with you to make it really success. I can't send the document with you here only so I request that if you are interested please email me at emailmejust/at/gmail.com. I think there is no point in developing something which is not known to the others. So help me please. Thanking you Rajendra R Patil http://wirelessprojects.googlepages.com