I am a firm believer in separating the presentation layer from the calculation layer. (As an aside: I acknowledge that there are more official terms for these principles, however for the sake of argument I will use these terms). In that believe I have a bit of a problem having for-loops, if-constructions etc. in the presentation layer. This makes the presentation layer no longer pure presentation but now also contains some form calculation and that has a risk of creap (pun intended) of business logic in the presentation layer. However, this I have noticed in the field that this creep is commonplace in JSF and I (will have to) accept the fact that the presentation layer in JSF does contain some programming logic.
Is there to the knowledge of the authors one or a number of patterns which will help us reduce the number of these constructions or helping the developers limitting these constructions to the ones which will have the least risk of changing once the application is in production? My fear (backed by some experience) is that when once an application is in production the impact of maintenance is worsened by the presence of logic in the presentation layer.
This topic is already answered in the welcome topic, however I would like to be eligible for the receipt of the book
Dolphins are grey, but they dream in colour.
Joined: May 21, 2007
And to be complete: here is the answer as given by mr. Ed Burns:
Cor Takken wrote:I am a firm believer in separating the presentation layer from the calculation layer. (As an aside: I acknowledge that there are more official terms for these principles, however for the sake of argument I will use these terms). In that believe I have a bit of a problem having for-loops, if-constructions etc. in the presentation layer. This makes the presentation layer no longer pure presentation but now also contains some form calculation and that has a risk of creap (pun intended) of business logic in the presentation layer. However, this I have noticed in the field that this creep is commonplace in JSF and I (will have to) accept the fact that the presentation layer in JSF does contain some programming logic.
You are right to be cautious about using logic in Facelet pages. In fact, I have been touting the complete absence of scriptlets in Facelets as one of its selling points. There are still a few corner cases that remain unresolved in using JSTL conditionals or iterators in Facelet pages, mostly revolving around state that changes between requests. As far as patterns or practices to refactor an existing occurrence of the use of conditionals and iterators I do have some suggestions.
Let's take conditionals and iterators separately. First, conditionals. The most common use of conditionals is to show/hide portions of the page. This usage is generally safe, especially when you value bind to the view scope.
Next on to iterators. If at all possible, use ui:repeat instead of c:forEach. ui:repeat is backed by an actual JSF component, while c:forEach is a tag handler. Because ui:repeat is a JSF component, it does a better job of managing its state.
If anyone else has something to share on this, please do!
I can fully subscribe to your opinion! From the experience with my daily work I can only warn everyone to NOT use anything which looks similar to programming logic inside the view layer or view templates if it's not absolutely necessary! With tears in my eyes I have to wade through piles of code and programming logic buried forever in XML templates (a non-standard XML format) every single day and it's just annoying and exhausting!
Undoubtedly there are justified situations where it necessary and reasonable to use for example a loop inside a template. But I've seen situations where I've wasted HOURS to find the reason why something in the web interface didn't show what was expected. So for God's sake minimize logic in templates as much as possible!
Anyone who's spent any time on this forum knows that one of my favorite things to rail against (and one of the most common offences) is the act of putting logic in the View.
Java is an extremely expensive tool to use. Unlike the (mostly scripted) "Git 'R Dun!" platforms, you have to spend a lot of time setting up a proper scaffolding on even the simplest of apps, and you have to do a lot of advance co-ordination between components just in order to get things to compile.
In the mean time people are madly hacking out scripted websites at a much faster rate - frequently shoddier, less secure, websites, but they put Pages In Front of Eyeballs faster, which to the simple-minded implies Productivity. So there's considerable pressure to take shortcuts in Java just to be competitive. Not to mention out of sheer laziness.
What you get is a classic example of the Pay Now/Pay Later syndrome. If the business logic is scattered between Java code and Views, then every little change request turns into what I call a Treasure Hunt, as you scramble to find which layer the action is in. Or worse, layers, which means that changes in one place can have unintended consequences in another place. This is true when you put code in Views, it's true when you put code in the database (stored procedures), and it's true any time you violate the proper tier locations for things.
One of the primary reasons why the whole tier concept was developed in the first place was to reduce the cost of maintenance for large projects by ensuring that future developers would be able to easily locate things and that when they changed things, the consequences of those changes would be well understood.
Customer surveys are for companies who didn't pay proper attention to begin with.
There's nothing more to add, Tim! You couldn't have described the typical problems in software development better!
Too sad that laymen can't see what a mess a piece of software can be even though it may look bright and shiny at its surface! So the easiest solution to blind a layman is naturally to create a piece of software with a shiny surface which at a glimpse looks like it would do more or less what was expected. Of course the beast lurks under the surface and guards the treasure so that every hunt for this treasure is guaranteed to cost hours and hours.
It would be a real pleasure if some day someone would find a way to visualize the degree of mess in any software graphic and understandable for everyone, even business people. And to calculate the loss of money and time when software is developed the "Pay Now/Pay Later" way. Customers would surely think twice before buying software and a lot of those wannabe developers would be very unhappy.
Unfortunately this will probably not happen in the near future...