Re: Recommendations for a web application framework?

Chris Smith schrieb:
Timo Stamm <timo.stamm@xxxxxxxx> wrote:
Do you mean separation of HTML and Java or separation of business objects and view code?

I meant separation of view code from application code. I try to avoid words like "business logic" or "business objects", but you could assume that we mean about the same thing.

I think so.


In my opinion, even PHP template libraries like TAL do a better job of separation in both respects than JSF.

I'm convinced, then, that we are talking about different things. TAL doesn't even get you halfway there. It's nothing more than an abbreviation language for encoding PHP control structures into special "tal:" attributes.

I admit that was an unjust exaggeration. TAL does a better job of separating the HTML Template from view code than JSP. But TAL certainly can't compete with JSF because it is just a template library, not a component oriented web framework.


That's Struts. But Struts is the oldest (and most outdated) of all Java Web Frameworks I know.

In a different form, it's also the Wicket example you posted, which has two id attributes in the page corresponding to the two components; and then a Java class representing that page, which again has to match the id attributes on components on the page. It's a little better than Struts, to be sure. Yet I still see this duality wherein there's a Java class representing the form.

Unfortunately, you can not eliminate this duality if you want to use HTML templates and insert a value into a specific position in the template.

But with wicket, you could encapsulate the two components for the link and the output label into one component and you can use language features like inheritance to remove redundancy (yes, it works with HTML templates too because a HTML file is always associated with a java class).


There are many Frameworks that hide HTTP entirely. With some, you don't even have to care about request-response cycles:

For most common purposes, JSF could be included in that category. JSF does define a request processing lifecycle, but typical application code just defines event listeners and they get called at the right time. You have to know a few things (for example, say, that converters get called before validators) but this is more about the JSF model than HTTP request processing.

This is a major problem with JSF to me: You have to define a lot of classes and XML configuration files. You have to solve too many problems that are not part of the intrinsic problem, but are introduced by the framework that you utilize to solve the intrinsic problem.

The example I gave requires one additional class to represent the Application and one entry in the deployment descriptor to get it running. An implementation in JSF would probably require at least twice as many files. I feels like having to work for the framework instead of solving problems.


The request processing lifecycle becomes more important when you're generating non-JSF content (such as dynamically generated images and such), or when you're pulling more advanced tricks such as when I wrote a JSF component to interact with JSF backing beans straight from JavaScript in a web page, and needed to prevent the rendering of an HTML response to that HTTP request.

Was that before JSF 1.2? As far as I understand, the "Avatar" Extension should make AJAX (forgive me using the buzzword) easier.


Timo
.