For GWT we use static constants to provide internationalization for our users. However, this makes reviewing and editing the texts a tedious process, because if one of our stakeholders has comments, it has to be compiled and deployed to our demo environment again. The solution would be to have some kind of semi dynamic text constants.
What I would like, is that I can compile to some kind of "review mode", and when I do that, the constants are read from a file from the server or database. If possible I would like to be able to edit this file, so stakeholders can modify the texts themselves (using some kind of text edit widget I would have to write for that). Then we can develop, test and demo with these texts. If we are satisfied, we compile for production mode, which uses a old fashioned constants resource bundle, compiled completely in JavaScript.
Does somebody know if something like this exists, or have some pointers on how to implement this?
It is a very surprising situation that GWT programmers often overlook the usefulness of JSPs and the Dictionary class. Even though many of us had tons of JSP experience prior to using GWT.
Dictionary class
You can define your "static" information as javascript var objects in the html hosting file. The Dictionary class can be used to read those javascript objects any time after moduleload.
JSP
The HTML "hosting" file, i.e. the html file used for launching GWT need not be an HTML file. It can be a HTML file dynamically generated by a JSP.
If you are familiar with JSP, you could turn an HTML file into a JSP just by changing its extension. Now turn the javascript object section you used for defining GWT "static" information into being dynamically generated by the JSP.
Voila!
I use JSP as the hosting file when I need to generate user- or session- specific "static" information for the GWT client. The JSP could read from the database or from some conditionally chosen text files.
Related
I'm using Play 2.5 and there is a requirement to store all of the relevant static HTML Template data in a column in the database that we can then call and pass relevant object into.
This is proving difficult as it seems that Play requires the template to exist as static files included in the classpath prior to running.
For example, say I have an index.scala.html file that looks like this:
<html>
Hello #name!
</html>
I want to store this template in a variable (i.e. String template) that I can pass objects into like so:
String template = GreetingDTO.getTemplate();
Content html = template.render(User.getName());
This is essentially all I do to do regarding templating at this point. I need to format some passed in objects into a user-editable HTML layout for E-mail Notifications.
Is this possible without hacking around with Play's classpath structure? Where would I even begin with this? Could I possible achieve this easier by using a different template engine than Twirl. The only example I have found is this old Freemarker post from several years ago so was hoping there might be something a little more current.
You won't be able to use Twirl, the default template engine, because it is compiled to scala code and then to bytecodes and that all happens at compile/build time. From the docs:
Templates are compiled as standard Scala functions, following a simple naming convention. If you create a views/Application/index.scala.html template file, it will generate a views.html.Application.index class that has an apply() method.
Of course, it is possible to change the template engine and you can use another template engine that better fits your requirements (dynamically load and parse templates). Finally, take a look at the modules directory.
My application suppose to work with different languages. In order to provide this feature, I have created different messageResource files for each language.
Each resource files contain the same keys but values are different according to which language application is running. I load the specific language resource file on application load up.
This is working very fine.
However, as we are adding more features, the resource files for each language becoming very long, which makes it difficult to manage (edit) for non-techy person like Content editor guy.
Therefore, I would like to know, how can I redesign or remodularise in such a way that it will be easy to manage for Content Writers?
I hope I clear the scenario but please shout, if any thing needs?
I do not know a i18n standard mechanism in the Java world to split message properties in chunks. However, I have made good experiences with a standalone properties-edit-tool like jLokalize. It's pretty user-friendly even for non-programmers: hand over the properties files to the content writer and let him/her load the files in the editor.
Do you ever need to write your own HTML, CSS or JavaScript files for your GWT app? Any reason to ever write your own HTML/CSS and include it with the build? If so, under what circumstances, and where do you package it in the final WAR?
Some developers prefer to use an external CSS file for their app instead of a CSS resource. Then you add this CSS file to your /war directory, and provide a link to it in your host page like you would do with any external CSS file.
If you use UI:Binder, which I highly recommend, you can write a lot of page or widgets' layouts in HTML as opposed to using GWT widgets. In this case you don't have to do anything with the HTML: GWT compiler will take care of it.
There is a way to use native JavaScript from inside the GWT app. Sometimes developers want a special effect or some functionality that they can't (or, quite often, don't know how to) implement in GWT. In this case you include the JavaScript code directly into your GWT code, or you use an external JavaScript file and reference it from GWT. In the latter case you include your JavaScript file in your /war directory and load it in your host page like with any JavaScript file.
I would like to invoke the JSP parser programmatically. That means that I want to be able, in Java, to 'run' a jsp page and get its output, without sending it back to the client (I actually want to save the output to a file). I don't want to 'forward' the request to the JSP page. I want to be able to do that on several JSP pages in a row.
What is the best way of doing this?
I have found this question, but BalusC doesn't really answer the question directly.
In case you are wondering, I need to do this is because I want to 'precompile' the JSPs for using on other platforms than a Java servlet container.
EDIT
What I need is not the .class file, but the HTML output. Indeed, that will be static once generated but I have some custom jsp tags and I want to leverage the JSP parser to expand them.
I'm not sure that I understand the point of all this.
JSPs are parsed and precompiled to .class files. They're Java servlets at that point. You need a servlet engine to execute them.
If your intent is to capture the generated HTTP response as the "precompiled" response, it would suggest that there's no dynamic content and the response is the same every time you send that particular request. If that's the case, what you've got is static HTML.
If I'm correct, this would seem to be a poor way to generate such a thing.
If your wish is to precompile JSPs to .class files, the problem is that different Java EE app servers use different JSP precompilation engines. You can't precompile JSPs using Tomcat and use them on WebLogic.
The best way to get the html output from a jsp page is to actually deploy it to a real webserver and then call the page and save the rendered output.
If you want to automate some part of this, you might want to look into using a testing tool that exercises through the real interface, such as Selenium or that emulates the browser, such as HttpUnit.
But this is doing much more than just invoking the JSP compiler.
Maybe it would be more practical to use template engines like http://freemarker.sourceforge.net/ or http://velocity.apache.org/
Freemarker even seems to support JSP Taglibs: http://freemarker.sourceforge.net/features.html
Is your JSP dynamically generated. If so then you are stepping into a potential disadvantage situation wherein your JSP will be compiled again and again, leading to performance issues.
However if you could have a single large JSP with all the rules that you need to prepare your display, you could use HttpClient to make a call to your own JSP and that would return the HTML. This would ensure that you are not app-server dependent. If you use JSP Parser you are going to be vendor dependent.
But if your JSP is being dynamically constructed then you should look at options wherein your HTML can be generated on Java side. But if it involved rule based HTML creation, you are better off creating it in Java. You can use Apache Jakarta ECS library for this.
And yes JSPs are not meant for this purpose.
This question already has an answer here:
File names for JSP include directive to avoid compilation of them
(1 answer)
Closed 5 years ago.
What are .jspf files in JSP? As I know the compiler will look for .jsp files to compile, then how are the .jspf files compiled?
As others have noted, .jspf files are JSP fragments. They're designed to be statically included in another JSP file, not compiled on their own:
<%#include file="/WEB-INF/jspf/example.jspf" %>
You'll note that this example comes from the /WEB-INF/jspf directory. This means that it is not accessible outside of the web application; there's no way to construct a URL that can retrieve it. If you put them in the same directory as "normal" JSP files, you can construct such a URL; Tomcat, for example will retrieve the page as a text document. A front-end web-server, however, can block these URLS.
I like JSPF files as a first step in refactoring large JSP pages. Since they're statically included, you can extract a small chunk of the file without making provision for scriptets or variables, leading to pages that are somewhat more maintainable (and I want to stress, it's a first step; dynamic includes and taglibs are usually a better long-term solution). When refactoring, I believe in keeping the fragments close to their parent files; this is when having a web-server to block URLs becomes useful.
JSP Fragments can be compared to server side includes. These fragments are not compiled on their own, however there are compiled along side the page in which its included. If I've to display different pages base on a user preference, i will opt for jspf.
What : .jspf files are generally files that are included in .jsp files via the include directive. The 'f' stands for 'fragment' as these files are not full JSPs in and of themselves.
How to Compile: Since .jspf is a fragment of a jsp hence it may not be complete and compilable source, so most of the time it can't be compiled independently of another, complete, source that references them.
Source : Ibm Infocentre
IBM says that .jspf is for JSP fragments. A fragment may not be complete and compilable source, so they likely can't be compiled independently of another, complete, source that references them.
They're mentioned in Sun's developer resources in the same context - a naming convention for JSP Fragments.
In many web frameworks, it's possible to assemble views and pages from smaller, shared views and pages. Using JSP, these smaller pieces are called fragments. As the name implies, they're not necessarily a complete representation without some larger context.
Other languages and frameworks have their own term for the equivalent concept. In Ruby on Rails, for example, they're called partials.