Apache Click Project

"Why Click?" Because "click is JSP and MVC Free. This is a good thing!"

While I sure can agree that JSP-free is a good thing I'm surprised by the second assertion: MVC-free is a good thing. I don't agree.

I think in the given reasons there is some confusion about what sometimes is called MVC and what it should be. MVC is mainly a design pattern which clearly separates the three well-known roles. I find nothing bad about that. The author seems to think that mixing all these roles into a component is some kind of OO. He gives Swing as an example, but exactly this is the point: Swing claims to have some kind of MVC inside, but this in fact is an a very low-level, technical design.

In a real MVC-based application the whole Swing classes form just the view layer and the technical separation with TableModels and UI classes are part of the views. I still have to build a real business model, which knows nothing about my views of and real controllers, that are also not dependent on my GUI library decision. They contain application flow which is triggered by actions. So what I just learned is that Apache Click is just another UI-Framework which leaves it to the developers how to build a good application structure - what a pity!

Apache Click Project

Isn't this an anti pattern? In pretty much any application I've ever been involved in, irrespective of size and technology (web, spring, whatever), separation of concerns is a very desirable thing and combining the controller with the view just ends up setting yourself up for a big mess further down the line as things start to scale.

"Isn't this an anti pattern? In pretty much any application I've ever been involved in, irrespective of size and technology (web, spring, whatever), separation of concerns is a very desirable thing and combining the controller with the view just ends up setting yourself up for a big mess further down the line as things start to scale."

 

Hmm, according to Martin Fowler's "Patterns of Enterprise Application Architecture", pages 331 - 332 (where the MVC pattern is discussed), the separation between the view and controller in web presentation layers is less important than it is to separate out the model.

 

Fowler does go on to state that the full separation of concerns is more common in web front-ends than in rich clients.

Personally, I prefer the full split.

Being the original author of the quoted page I would like to discuss intent behind this piece. The idea was to get people thinking about encapsulation where you can have a reusable control/component which you can drop into a page without having to wire up configuration files or write a bunch of JSP tags.

With regard to MVC, the Java Swing framework does implement the MVC design patterns. It is sophisticated, relatively complex, and takes people a while to get the heads around it. 

In parallel the Flex application developers have a number of MVC frameworks which are also sophisticated and which people also struggle with.

The complexity around this space involves, wiring up observer patterns and event notifications between the various components, dealing with issues of lazy instantiation of model and view objects and its impact of binding, and you can also through asynchronous call backs into the mix to spice it up a little.

Both Swing and Flex MVC applications also struggle with memory management, once you have build up your MVC object graph its actually quite difficult to get rid of it and have bits of it garbage collected. You will also find it difficult to achieve much reuse in these applications, because you get tight coupling between the model and view components.

Overtime I think people now think of MVC in terms of the web applications, and as a higher level architectural construct. This started out with Servlets being the controllers, JSP's were the views and database objects where the model. This is not what the MVC pattern was originally about.

The ironic thing about all this is that web application development in Click is actually much more productive than a full blown MVC application. This is partly because the individual pages which are largely isolated from each other. Developing a 30 screen application is pretty easy, you just plough through the pages.

While in contrast developing a 30 screen Swing or Flex application with a rich MVC framework is much more complex and takes a lot longer.  I see this every day in the company I work in.

Please note you can amazing things in Flex and Swing, which is harder to do in Click, but you can do straight forward things much faster in Click.

regards Malcolm Edgar

Probably they used the wrong terms, Click does have some sort of MVC. It is page centric, where the C in MVC is in the page manager class (sorry if I use the wrong terms).

The "onClick" and similar methods are simply ways to capture controller cases.

Moreover, Click has lots of similarities to JSF. One big difference is that Click has a tight connection between a page and its manager class. But you cannot say that JSF has some sort of MVC.

But you cannot say that JSF has some sort of MVC.

Sorry, i meant "But you cannot say that JSF has *not* some sort of MVC"

I think the article in question is talking about the MVC pattern that was popularized by Struts, not the desktop MVC pattern from the 80's.

Kind regards, Bob