Comments on: Most web frameworks are broken

By: Antony Stubbs

Antony Stubbs — Sat, 26 Jul 2008 06:12:03 +0000

+1 for Wicket.

Although you still have to get your binding names correct, the framework fails hard and fast if they are mismatched (you can’t bind to a backing object that doesn’t exist). Secondly, there’s an eclipse plugin that will check all your bindings during development anyway. Great!

By: Stephen Friedrich

Stephen Friedrich — Thu, 17 Jul 2008 15:26:12 +0000

Well, part of the problem is an IDE that is not up to the task.
For example both IntelliJ IDEA and Red Hat Developer Studio statically check EL expressions.

I agree though that views and backing beans are too tightly coupled in principal.

By: James E. Ervin

James E. Ervin — Tue, 15 Jul 2008 16:29:47 +0000

I think this article highlights an idea I have been pursuing. The idea of separating programming languages and their associated contexts into two categories, implicit and explicit. I realized when I started on the idea the point I was really trying to get across was that I want to see things made more explicit in that even though I like terse languages (easy on the hands and wrists), I want tooling that in effect makes the language/platform explicit. You want tooling either in the compiler or IDE to be able to at least warn you of potential trouble as much as possible. This to me is the great divide between using so called dynamic versus statically typed languages at the moment. I know dynamic advocates will argue that you need a stronger set of unit tests, but really do you want to have to depend on people writing a bunch of tests when you could have a compiler or IDE tool give them the feedback they need automatically? My ADD afflicted mind and I prefer that the computer do as many automatic checks as possible, since it is likely I will forget, or be to lazy, to do them.

Mr Spiewak had a great blog entry on this:
http://www.codecommit.com/blog/ruby/pipe-dream-static-analysis-for-ruby

Incidentally, I think Daniel inadvertently makes the best synopsis of the argument between using dynamic and statically typed languages in that blog entry that I have ever read.

By: Bachew

Bachew — Mon, 14 Jul 2008 09:08:39 +0000

Absolutely agree! That is why web frameworks like Wicket exist. But everyone likes standard, so give them JSF. In fact, the whole Java community seem to like hardcoded string so much that they have lost they OOP nature.

By: Jose M. Arranz

Jose M. Arranz — Mon, 14 Jul 2008 07:30:50 +0000

I can’t agree more, this is the typical problem of “executable views” or “pull views” (the view pulls data), in the old JSP approach Java code was hard coded and the compiler was very useful to detect coding bugs. Now most of the templating engines interpret the view (the view logic uses interpreted languages) and there is no way to detect errors in a compiler phase.

The alternative is using non-executable views or web frameworks with “push views” (the application pushes any data to the view). Frameworks with “push views” reduce the view logic in the view, in some way the view rendering is “driven” by Java code, one immediate benefit is a cleaner view/view logic separation.

Terence Parr talks about this:
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

There are no very much examples of web frameworks with push views:

- StringTemplate: a proof of concept of Terence Parr ideas.
http://www.stringtemplate.org
- GWT : this is an extreme example because there is no template, view is built programmatically.
http://code.google.com/webtoolkit/
– Wicket: the template is almost pure HTML, most of the logic is defined in Java
http://wicket.apache.org
- ItsNat: my preferred, because I’m the author In ItsNat the view logic is pure Java using W3C DOM Java APIs and the templates is absolute pure HTML (or SVG).
htt://www.itsnat.org

By: Mike Brock

Mike Brock — Sun, 13 Jul 2008 19:16:37 +0000

“If cost is a String that holds “24.50″, and the computeGst() method returned a double, it is very possible that your web framework will still compute the result! This is because many of them perform implicit type conversion:”

I’d like to note, that even in weakly-typed mode, MVEL does not suffer from this problem unlike OGNL. MVEL *never* invokes a target method for type conversion purposes. OGNL 2.7 does though.