WTF: Why this flow?

Or The gentle art of spaghetti code. I'm Italian. I like spaghetti. As long as they come on a plate with some good recipe on them.
In the code I work with I prefer some other... pattern. What you see in the picture is the actual workflow of a very simple master detail view / controller set in a J2EE application. ( and I'm by far too generous using these definitions) . This is how it works:

1. the user ask for a url handled by a list controller. Without parameters the controller puts an object in the request with a flag which means " this is the first request" ( well this is also the actual name of the property) skip the query part and foreward to the jsp.
2. In the jsp there is a scriptlet ( yes a 90' style scriptlet) that set the above flag to false and set another flag to the "ready to search" value.
3. When the search button is clicked the request is handled by the same controller whom , upon flags examination ( with very elegant nested if statements) decide to invoke the dao layer and perform the query, dispatch to the jsp which , upon other flag examination again with scriptlets (AGAIN) display the results.
4. Clicking on one line in the result list will  invoke a second controller, which set the second flag to "display details now" and dispatch to the first controller which dispatch the request to the jsp

Amen.

Master detail should be simpler then this. In J2EE  eco-system Grails comes to my mind or my defunct project springears. Master detail , as many very very common use case and  should be handled in a DRY way. A simple, granular way. At least in the workflow management if the UI is really really complex ( although it shouldn't be).

This is not a a rant against a specific working day 'shit happens' moment, not Java/J2EE ( I did and have seen great things done with it). It's against bad code. This particular case is the rotten low hanging fruit of bad framework design and lack of long term view. This workflow is repeated dozens of times in the app becoming a pattern without a proper abstraction nor support ( and an ugly design at his root). The saddest final note is that the forth coming lack of will to deliver a good product and proper test do not allow me to make things better.

The bitter end.