I am writing a new service Convert-HTML-TO-PDF. But now I am confused that what way should I prefer.
What ways I have to implement:
Use Head-less browser and capture the HTML page and convert to PDF
Use Java/Node Lib to convert. Which will create HTML relevant component in PDF file and then render?
Now, please help me to understand what will be the best way to implement a service and why!
[update]
And what will be the advantages and disadvantages of each approach
In my view, the best way forward always depends on what you already have experience with and what approach you take. There is no right or wrong here, everyone has to decide that for themselves based on their preferences.
Each approach has advantages and disadvantages. Some of them are:
Headless Browser:
Advantage:
No large Libs necessary, therefore very memory saving
Disadvantage
the desired browser must be installed on the computer/server
rendering may differ for different browsers
Library:
Advantage:
different libraries available
for the popular libs there is a good documentation and code examples
Disadvantage
When upgrading to a newer version, code usually needs to be adapted.
When upgrading to a newer version, the result may look different.
In my projects I use a headless chrome browser. For this I found an easy to use api on Github, which uses the DevTools of Chrome.
It also includes a simple example how to print a page into a PDF.
For my purposes I have customized this example and write the HTML into a temporary file and then navigate to that file.
// Navigate to HTML-File
page.navigate(htmlTempFile.getAbsolutePath());
I can't say if this is the best way, but for me this was the easiest and most understandable way
Got three questions on the play Scala template system.
Just a clarification:
I am assuming you create a new template for each kind of page that you want to produce - that correct? So, a log in page, an accounts page, home page, etc? Does this mean I should expect to have quite a few templates?
If I am say storing a history of orders - using java OO features with classes such as OrderLog and order. Would it be ok to call a java method in OrderLog.java that directly creates html text that I simply pass to the Scala template or is this a bad idea? Should I instead give the objects to the Scala engine and have that translate them?
The two considerations I am thinking of are whether the Scala is faster at rendering the text and whether it is just bad style to have the java compose the string.
How do I render JSP using the play framework?
For good design and ease of use, you'd probably want a modular design, where repeated structures (such as a footer for instance) have their own templates. Sometimes a large portion of multiple different pages could be reused, where you should only write it down once in a template that you use on all pages (can also parametrize your template to serve two almost similar pages). Thus, you should create plenty of templates. Think about them as methods in your code, helps being DRY (Don't Repeat Yourself) and KISS (Keep It Simple Stupid), not trying to solve all the problems in one template or forcing every page to have their own template that does practically same things as another page.
According to the MVC pattern, you should leave all rendering details for the views (in this case your templates) and keep it out of your models (OrderLog). Should be less verbose to do it in a template than trying to create HTML on server side and all your HTML is in one place, so it's clearer for new people - or yourself after a long break from working with this application.
You shouldn't use JSP, just the template engine. It can do everything plain JSP's would and more. Templates will be rendered when you have the server up and running and load the pages (on dev mode). You can keep changing POJO's or templates without having to republish the application or restart the server to see the differences.
We are working on a Spring MVC web application (running in Tomcat 7) and currently we are experiencing moderate load on the website. The main resource that has to be raised from time to time is RAM due to increasing number of users.
Some of our JSPs are pretty complex, but on the other hand they aren't changing very often. I was wondering if there is a library or some kind of cache system, which would store generated HTML that was generated from JSP for a recent page visitor and serve the next user as a static content. This would lower the stress on our application server (CPU, RAM).
My idea is that it should function like some kind of server-side cache so we could set how long the page should be cached as HTML and delete that cache if necessary. Tomcat would user HTML version if available or simply use classic JSP if needed (and generate HTML after that). So far I haven't found anything like that.
Any ideas?
JSP are dynamic by nature. A JSP page is first compiled into a Servlet and then up to answer client requests and generate HTML content to the browser. So, you have to consider your design. If you are using JSP to generate dynamic content, maybe this specific page is not supposed to be cached.
Otherwise, if you know that the content is really static, make it a simple HTML (or .xhtml) page, skipping JSP-Servlet compilation process. You can still create a javax.servlet.Filter to generate cache headers (cache-control, expires, etc...) for these specific static resources.
If you are using Tomcat, you can even create a acting as a request processing filter
as a general purpose caching filter for static resources on the server.
If you don't have a reverse proxy in front of your Tomcat(s), consider setting up Varnish, and have it cache those particular JSPs (among other things). But be sure to not cache anything sensitive (user-specific). See https://www.varnish-cache.org/.
We just moved from GWT to Wicket 1.4. While very happy in general, we still have a bit of a learning curve for certain things that GWT made simple. One of those things is resource caching.
How can I configure our app's resources (CSS in particular) so that they aren't downloaded with each page request?
We're seeing some flickering on certain page elements because the styles aren't being applied immediately, presumably because the style sheets are being downloaded each time. I traced through our logs and indeed, I'm seeing requests for the stylesheets on nearly every page request.
We're referencing the CSS directly in our HTML files like so:
<link href="/css/ag.screen.css" rel="stylesheet" type="text/css">
<link href="/css/ag.base.css" rel="stylesheet" type="text/css">
I'm not sure it matters, but all our pages are mounted with IndexedParamUrlCodingStrategy, as we need them to be both bookmarkable and have particular URL structures.
I tried implementing what Stefan Fußenegger suggests in his blog (i.e. referencing the CSS via a header contribution rather than in the HTML directly), but that didn't seem to help (I tried checking the headers with "curl -I").
Is there a standard way of setting Cache-Control or Expiration headers for resources in Wicket 1.4? Is it worth moving to Wicket 1.5 for this? (I'm hesitant to do so because it's not officially released yet).
Edit: I just gave 1.5 another try, but the lack of documentation is really a roadblock at this point. IndexedParamUrlCodingStrategy and related classes are are gone, and the migration guide has almost nothing to say about it.
Edit 2: I just noticed something very odd- when I arrive at one of my pages either by directly entering the URL, or by clicking a BookmarkablePageLink, the resources referenced on that page (CSS, images, etc) seem to get cached (I see no requests for them in my logs). But if I arrive at the same page via a form submission, all of the resources are downloaded again. Why does a form submission cause resources referenced on the page to be re-downloaded?
Since you are moving to Wicket I'd recommend you to use 1.5RC4.2. Looking at the bug reports about this RC I think the next one may be 1.5.0Final.
About caching see this wiki page: https://cwiki.apache.org/WICKET/caching-in-wicket-15.html.
It is about 1.5 but it also says what are the differences against 1.4.
I had the same need as you, the need to cache resource client side the more I can.
For now I am stuck under 1.4.x and I found a solution that suits me.
I use the great library Stefan Fußenegger wrote and he made available here. Implementation is pretty straightforward, I use a StaticResourceVersionProvider in production mode. I had no issues so far (rock solid for my clients for now).
Don't hesitate if you need details on how I use this solution.
To manage the headers of non-Wicket resources you can use plain Servlet Filter that is listed before WicketFilter in your web.xml. Just check the request Url and if the file extension is .css/.js/... then just set the cache headers in the response.
About **UrlCodingStrategies in Wicket 1.5 read http://wicketinaction.com/2011/07/wicket-1-5-request-mapper/ and the next two articles. I hope it will be more clear for you.
You get fingerprints on resources out-of-the-box. The strategy for creating cache fingerprints can be modified or altered quite easily.
There's more information at the Wicket wiki page about how resource caching works in 1.5.
I'm about to choose to way to organize my view (with spring-mvc, but that shouldn't matter much)
There are 6 options as far as I see (though they are not mutually exclusive):
Tiles
Sitemesh
Freemarker
Velocity
<jsp:include>
<%# include file="..">
Tiles and Sitemesh can be grouped; so can Freemarker and Velocity. Which one within each group to use is not a matter of this discussion, there are enough questions and discussions about it.
This is an interesting read, but can't quite convince me to use tiles.
My question is - what do these frameworks give that can't be properly done with <# include file=".."> and JSTL. Main points (some taken from the article):
Including parts of pages, like header and footer - there isn't a difference between:
<%# include file="header.jsp" %>
and
<tiles:insert page="header.jsp" />
Defining parameters in the header - like title, meta tags, etc. This is very important, especially from SEO point of view. With the templating options you can simply define a placeholder which each page should define. But so you can in jsp with JSTL, using <c:set> (in the including page) and <c:out> (in the included page)
Layout reorganization - if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.
Coupling between the common components and the specific content - I don't find an issue with this. If you want to reuse some fragment, move it to a page that doesn't include any header/footer, and include it wherever needed.
Efficiency - <%# include file="file.jsp" %> is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.
Complexity - all non-jsp solutions require additional xml files, additional includes, pre-processor configurations, etc. This is both a learning curve and introducing more potential points of failure. Also, it makes support and changing more tedious - you have to check a number of files/configurations in order to understand what's happening.
Placeholders - do velocity/freemarker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.
So, convince me that I should use any of the above frameworks instead of/in addition to plain JSP.
A few arguments for Velocity (I haven't used Freemarker):
Potential to re-use templates outside of a web context, such as in sending emails
Velocity's template language syntax is far simpler than JSP EL or tag libraries
Strict separation of view logic from any other sort of logic - no possible option to drop down to using scriptlet tags and doing nasty things in your templates.
Placeholders - do velocity/freemaker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.
Yes, references are really the core of VTL:
<b>Hello $username!</b>
or
#if($listFromModel.size() > 1)
You have many entries!
#end
Efficiency - <%# include file="file.jsp" %> is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.
Not so sure I agree with or understand this point. Velocity has an option to cache templates, meaning the abstract syntax tree they are parsed into will be cached rather than read from disk each time. Either way (and I don't have solid numbers for this), Velocity has always just felt fast for me.
Layout reorganization - if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.
The difference is, with a JSP approach, wouldn't you be re-organzing this layout in every JSP file that uses the same header/footer? Tiles and SiteMesh allow you to specify a base layout page (JSP, Velocity template, etc - both are JSP frameworks at their heart) where you can specify whatever you want and then just delegate to a "content" fragment/template for the main content. This means there would be just one file to move the header in.
The choice between jsp:include and Tiles/Sitemesh/etc is the choice between simplicity and power that developers face all the time. Sure, if you only have a few files or don't expect your layout to change very often, then just use jstl and jsp:include.
But applications have a way of growing incrementally, and it can be hard to justify the "stop new development and retrofit tiles (or some other solution) so we can fix future problems more easily", which is required if you don't use a complex solution in at the start.
If your sure your application will always remain simple, or you can set some benchmark of application complexity after which you will integrate one of the more complex solutions, then I'd recommend not using tiles/etc. Otherwise, use it from the get-go.
I'm not going to convince you to use other technologies. For all I know everyone should just stick to JSP if it works for them.
I work mainly with Spring MVC and I find JSP 2+ in combination with SiteMesh the perfect match.
SiteMesh 2/3
Provide decorators to be applied to the views mostly like inheritance works in other templating engines. Such feature is unthinkable to work without nowadays.
JSP 2+
People claiming that JSP will make it hard to avoid Java code in templates is bogus. You just shouldn't do it and with this version it's unnecessary to do so. Version 2 supports calling methods using EL which is a big advantage compared to previous versions.
With JSTL tags your code will still look like HTML so it's less awkward. Spring packs a lot of support for JSP through taglibs which is very powerful.
The taglibs are also easy to extend so customizing your own environment is a breeze.
One of the best arguments for facelets (not in your list, but I'll just mention it) opposed to using JSP is that the compilation is integrated with the interpreter instead of being delegated to the JSP compiler. This means that one of the most annoying things I had with JSF 1.1 - having to change the id-attribute on a surrounding JSF-tag when saving a change in order for the runtime engine to discover the change - went away, giving the save-in-editor, reload-in-browser cycle back, along with much better error messages.
A good view technology eliminates most and most anoying if/switch/conditional statements, simple include does not. Using a 'complex' view technology results in a 'simple' application.
You didn't provide information about specific of your applications. For example I do not use JSP just for few reasons:
It is hard to avoid using Java code in JSP templates so your break concept of pure View, and as result you will have difficulties to maintain code in several places as view and controller
JSP automatically creates JSP context which establishes a session. I may want to avoid it, however if your applications always use session it can be not a problem for you
JSP requires compilation and if target system doesn't have Java compiler, any minor tweaking will require to use other system and then redeploy
Minimal JSP engine is about 500k of bytecode plus JSTL, so it can be not suitable for embedded systems
Template engine can generate different content type of the same model, let say JSON payload, webpage, e-mail body, CSV and so on.
Non Java programmer may have difficulties to work with JSP templates, when non technical people never had difficulties to modify regular templates.
I was asking same question long time ago and ended by writing my framework (surely template engine based) which was free from all disadvantages I saw in other solutions. Needless to say it is about 100k of byte code.
I realize that this comes off as a smart ass answer, but the truth of it is, if you don't see any advantage to using templating over code in your current project, it's probably because in your current project, there isn't one.
Part of it is about scale. You might think that includes are every bit as powerful as let's say sitemesh, and that's certainly true, at least for a small number of pages (I'd say probably about 100), but if you have several thousands it starts becoming unmanageable. (So for eBay it's not necessary, for Salesforce it probably is)
Also, as has been mentioned before, freemarker and velocity are not servlet specific. you can use them for anything (mail templates, offline documentation, etc.). You do not need a Servlet container to use freemarker or velocity.
Lastly your point 5 is only partially true. It is compiled every time it is accessed if it has not been so already. This mean that whenever you change something you need to remember to delete your servlet containers "work" directory, so that it recompiles the JSP. This is unnecessary with a templating engine.
TL;DR Templaing engines were written to address some (perceived or real) shortcomings of JSP + JSTL. Whether you should use them or not depends entirely on your requirements and the scale of your project.