I need to globally rewrite all links to CSS / JS / Images, adding a prefix which will depend on deployment details and is the same across the entire application.
There are hundreds of links on dozen of source HTML templates so modifying at the source (as suggested here for a similar problem) is too error-prone and unsightly.
So I would like to do this programmatically, parsing the outbound HTML, and dynamically replacing each link before the HTML is returned out of the server.
Where to do it?
In Thymeleaf can I intercept the DOM and modify it before it is serialized to HTML?
In Spring MVC can I capture the view output (HTML), parse it, and re-serialize it?
Should I stay "close to the wire" and write a ServletFilter?
Or is it better to write a Tomcat Valve?
How about stepping out of the JVM altogether and have Apache mod_proxy added in front of tomcat just to parse and rewrite?
My initial hunch is that the best place to do it would be Thymeleaf, where there is more context available and it avoids an additional parse/serialize. Why generate wrong data in one layer to have it patched in another, when you could just generate the right data at the outset? Unfortunately the Thymeleaf maintainers don't agree, according to this closed Issue.
I also have this uneasy feeling that I might be reinventing the wheel. Isn't there a generic config option I can set somewhere in one of these layers?
So, to re-state the question objectively, what is the simplest solution - with the fewest lines of code written, and least number of files touched - to globally rewrite all CSS/JS/IMG links in a web application at run-time based on an application-specific algorithm?
I am using Spring 4 MVC to display serve my web page. I now want to display the same content with different layouts wrapped around the body/content depending on the current HttpServletRequest (e.g. request.getServerName()). This means https://page1.test/page.html will be mapped to the same controller as https://page2.test/page.html and returns the same content depending on the controller logic, but page1.test draws for example a different header and footer.
As far as I know, Spring MVC is not capable of doing this. I am now planing to use Apache Tiles 3 or JSP 2.0 tags to do this. Is there any best practice and how can I do this (Spring Java Config is preferred)?
You should take a read of http://tech.finn.no/2012/07/25/the-ultimate-view-tiles-3/ just to see how far you can push Tiles-3
Indeed it can solve what you're after.
(That blog website has just been migrated from wordpress to github pages so some of the code snippets require horizontal scrolling, we're still cleaning these small formatting issues up so please excuse them)
My project's domain is of eTendering. And we are planing to use Spring and Hibernate in the architecture and in presentation Spring MVC but we want look and feel like silverlight of .Net or Flex of adobe in short we are planning for Ajax framework in presentaion. So SpringMVC will be worthfull? I have seen wicket and openxava but I am still confused so please suggest correct option in terms of my domain's complexity.
Depends on your needs:
Spring MVC - this option will leave you with writing AJAX on your own (via JQuery for instance) along with HTML and so forth. It might be tedious, but you're controlling everything. It's also up to you what will be the quality of your resulting HTML and how good it will be indexed by SEO.
JSF - this option provides you with a number of components and allows you to create AJAX based forms and handles it out-of-box. But when it comes to writing custom components, it won't that easy as just writing JS/JQuery on your own. Also it generates not that pretty HTML which is not of that good quality and you might be less indexed by SEOs.
GWT - this choice would mean that you don't write JS, instead you write logic in Java and then it transforms to JS. From one hand it will provide you with good-looking AJAX-based app where you don't need to write JS, from the other hand it's a) pretty complicated to write really good-looking apps UI b) it will add another step in your development cycle (it takes pretty much time when you generate that JS) c) it almost won't allow your pages to be indexed. Also, if it comes to such derivatives as SmartGWT, they provide a large set of cool-looking components, but they always require money for support.
Vaadin - this is AJAX based framework that partially generates Java to JS, but it also sends requests go server for logic execution (of course in GWT this happens as well, but not that often, GWT tries to execute logic on client). It takes less time to compile sources to JS and it's also almost impossible to make pages being indexed.
ZK - another AJAX based framework. unlike other frameworks that allow you to work with only one pattern, it can work in MVC, MVP, MVVM modes. It doesn't compile Java sources to JS thus all the requests go to the server (I've heard about internal company's benchmarks that showed it was actually faster than GWT, but I think it depends on your processing logic). SEO won't make it with ZK at all, but it's possible to include ZK components into JSP pages (though this functionality is not free) which makes it possible to kill both birds. It will be not trivial to write your own components with ZK, but it has a wide range of ready-to-use components.
So you should consider several things: SEO, money you can give for the framework, how much AJAX you need and do you want to write it on your own, etc.
Also pay attention to those patterns I mentioned: MVP for instance is suitable for complicated interfaces and is supported by GWT, Vaadin, ZK. MVVM is very cool because of its binding and is supported by JSF and ZK.
I was reading about JSF that it's a UI framework and provides some UI components. But how is it better or different from number of components that are available from jQueryUI, AngularJS, React, Vue.js, Svelte, ExtJS, or even plain HTML, CSS and JavaScript.
Why should someone learn JSF?
JSF to plain JSP/Servlet/HTML/CSS/JS is like as jQuery to plain JS: do more with less code. To take PrimeFaces (jQuery + jQuery UI based) as an example, browse through its showcase to see complete code examples. BootsFaces (jQuery + Bootstrap UI based) has also a showcase with complete code examples. If you study those examples closely, then you'll see that you basically need a simple Javabean class as model and a XHTML file as view.
Note that you should not see JSF as replacement of alone HTML/CSS/JS, you should also take the server side part into account (specifically: JSP/Servlet). JSF removes the need of all the boilerplate of gathering HTTP request parameters, converting/validating them, updating the model values, executing the right Java method to do the business stuff and generating the HTML/CSS/JS boilerplate code. With JSF you basically end up with a XHTML page as view definition and a Javabean class as model definition. This greatly speeds up development.
As with every component based web MVC framework, you have in JSF less fine-grained control over the rendered HTML/CSS/JS. Adding custom JS code isn't that easy as you have to take the JSF view state in the server side into account as well (e.g. enabling a disabled button in JS side won't enable the button in JSF side, which is in turn a huge security advantage). If that is however a major showstopper, then rather look for an action based web MVC framework like Spring MVC. You'll only take into account that you have to write all that HTML/CSS/JS code (and prevention against XSS, CSRF and DOM-manipulation!) yourself. Also if you fall back from Facelets to JSP, you'll miss advanced templating capabilities as well.
On the other hand, if you have a big JSP/Servlet/HTML/CSS/JS/jQuery based website and you'd like to refactor the repeated JSP/Servlet/HTML/CSS/JS/jQuery boilerplate code into reusable components, then one of the solutions would be JSF. Custom templates, tagfiles and components can aid in this. In that perspective, JSF stands above JSP/Servlet/HTML/CSS/JS/jQuery (and that's also why it's pretty important to understand those basics before diving into JSF).
You can find a real world kickoff JSF based project here: Java EE Kickoff App. You'll see that it contains next to JSF as good HTML5, CSS3 and jQuery.
See also:
Difference between Request MVC and Component MVC
Difference between JSP, Servlet and JSF
What are the main disadvantages of JSF 2.0?
Is it possible to use JSF+Facelets with HTML 4/5?
When to use <ui:include>, tag files, composite components and/or custom components?
JSF was created to make it so that java shops didn't have to learn stuff like jQuery and build complex JS but instead focus on a purely Java stack. In a world where time is money and lots of places already focusing on Java development, one less language/piece in the stack makes training and maintaining faster and thus cheaper.
I'll add that JavaScript is easy to become a maintenance nightmare on large teams, especially if some of the developers on the project are not highly web savvy.
With Javascript and frameworks such as jQuery you have full flexibility and full control . With ext's etc you lose much control and must adapt to the framework. With JSF you totally lose control and must totally adapt to the framework. You're invoked in lifecycles etc. and finally you have no control when the call to the server can be made and where not. If you are to do something considered 'special', you're in very hard position. And in JSF world even such basic things as multicolumn table sort or fields where you can type only limited set of characters (such as number field) are considered 'special'.
However, the more flexibility you have, the more errors or bad practices you can made. High flexibility works only with highly intelligent programmers, others will turn the project into unmanagable nightmare.
But, with JSF and its limited flexibility, there's always only a few (or even only one) correct way to do something. You are very limited, you can't make shortcuts, you must write more XML etc. - but when adapting to standard, there's better control on the code the unexperienced or low-skilled programmers will produce. As a result, big corporations love JSF because it is 'safer' for them.
When I moved from GWT to JSF, I was shocked, how many things, that was natural to me, was considered highly untypical and how much simple things were so hard to achieve. What's more, even making the smallest changes, such as adding ':' sign after label, which in GWT/jQuery powered app would be changing one function generating label, required changing dozens of files with localized properties, which wasn't even considered by anyone except me strange...
The benefits of using JSF are not only in generating xhtml + css + js. Sometimes JSF imposes a restriction on the markup you can generate, like any component based framework. But JSF is not just for that, its lifecyle helps greately. After validating the input it can update the model and sync your server side beans without any effort. you just say "whatever the user types here, check if it's a number, if yes then store it in the property YY in object XX" and JSF will do all that.
So yes, you can still use JQuery, JS, etc. But JSF provides many benefits when it comes to writing server side code and saves you from a lot of boiler plate.
I strongly disagree that jsf adds anything. It only adds overhead. Doing ui stuff on the server is the most ridiculous thing ive ever heard. And javascript on large teams works great - its called reusing code.
Just wrap the jquery in some jsp tags, thats all you need and youre done, and dont endure the.shackles and scalability issues with.jsf and richfaces.
Having worked with JSF, Spring MVC, Struts, Grails, JQuery, and ExtJS my opinion is that Grails + ExtJS is one powerful combination.
I would pick Grails over JSF any day. I like the completeness of ExtJS as the client side framework and library, but it comes with a steeper learning curve than JQuery.
Here are the biggest differences between jQuery & JSF:
no MVC architecture
no state control (store date in session or conversation, auto-clean up, etc.)
no (default) validation library
no templating library
no advanced navigation/routing
client side
jQuery was never intended to be used as a full stack webframework. It was more intended for replacing low-level JS code so that writing JS becomes easier and more powerfull in less lines of code.
And it should thus mostly be used to add behaviour on HTML elements.
Having used ExtJS framework for a large web application, I know how easy it is to use. The ExtJS (Schena) is best suited for (Oracle 11g) database interactions in MVC architecture. The View was for the visual / user interactions. The controller specified the 'processing' and the triggers that needed to be used form the PLSQL packages (the API for the CRUD, SQL select queries etc.). The Model and the store files were used to 'map' the data items to the Viewer / inputs.
ExtJS is not suitable for non database intensive web interfaces - where Angular JS may be a better fit.
For a relatively simple application, can Webflow be employed to reduce the need to create form controllers? Well, certainly it can, but I guess what I'm asking is: can and should I write an entire application using Webflow for all of the controller / view logic if my goal for doing so is to reduce the amount of code that I write?
I'm struggling my way through the (poor) Webflow documentation and am wondering if it's worth it, or if I should just stick to regular MVC.
The use case for Web Flow is to solve the problem involved with controller logic that spans multiple-page navigation (a pageflow, or wizard). If you don't have to have a form split across multiple pages (or need several small forms to participate in a single transaction), you probably don't need a Pageflow.
Most applications do need this, however. Anything more than simple CRUD stands to benefit.
Pageflows provide a natural cache for the data and can solve problems involved otherwise when using back button navigation and multiple frames/tabs.
If you are thinking about how to store data that needs to live longer than a single request (the common but misguided view is to store in the HttpSession) then you will definitely get something out of Web Flow. If you're not doing anything like that and processing everything at the request-scope then odds are you don't need Web Flow.
Update:
Web Flow can eliminate the need for specialized controller classes to accomplish following a path of page transitions/form updates along a predefined workflow. If you don't need to do this, you can save yourself a lot of configuration/complexity just by using MVC.
SpringMVC and Spring WebFlow can be used together where appropriate - there is nothing odd about that.
If you have a use-case which is simple crud and you think you could easily implement this using SpringMVC then that's probably the right choice.
Note: You could also achieve this in WebFlow too and that neither better or worst.
If you have complicated wizard logic and state management requirements then WebFlow is great plus you get many other features for free like transactions and persistence support (Version-2).