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.
Related
I find that GWT will generate multiples HTMLS and use frame injection to invoke the JS logic in the caller HTML. But most of the browsers will not allow you to do frame injection on a local file system.
I am trying to avoid accessing different htmls on a local file system. Is there any way to generate pure JavaScript files from GWT instead of HTML ones?
Thanks!
Yes, you just have to change the linker.
Add this line in your *.gwt.xml module file to have pure .js files:
<add-linker name="xs"/>
Or this one, if you want .js files but they are executed in an iframe context.
<add-linker name="xsiframe"/>
Here is my situation: I'm working with an application that makes heavy use of JSP includes <%include ... %> and also loads tons of components dynamically using AJAX. All these get loaded into one main template page depending on what the user selects, etc.
My issue is with editing/maintaining these small page fragments that get included and loaded through AJAX. Since they are fragments, their code does not include a and doesn't include things like JQuery, which are added by the main template page.
Of course when they are loaded in the browser they work since the fragments are loaded through AJAX and added to the DOM.
The issue is: since these are just fragments, when I'm maintaining these pages I get a lot of errors and warnings on missing CSS classes and Javascript variables, etc. Besides, I can't use any WYSIWYG editors for the fragments due to the missing imports.
How can I tell Eclipse to assume certain imports (e.g. JQuery or CSS sheets)for these fragment files? Since using JSP templates is such a common design pattern I can't believe I'm the only person needing this.
You can go to the
Eclipse - > Preferences - > JavaScript - > Include Path -> User Libraries
and add a new JavaSCript library.
You can give your project JS folder .
After that you can go to your project build path and include that library in build path.
or you can add it directly to your project from here,
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.
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.
Javascript is executed by Java application. However, something like Jquery library is really too long to fit into a String variable. I am able to read jquery.js from a file but not sure how to package it inside the .jar file.
Loading the .js files is the same as loading any other resource from a jar file. Generally, this is what I do:
For files stored in the root of the jar file:
SomeClass.getClass().getClassLoader.getResourceAsStream( "myFile.js" );
For files stored along side a .class file in the jar:
SomeClass.getClass().getResourceAsStream( "myFile.js" )
Both techniques give you an InputStream. This can be turned into a String with code a little bit more work. See Read/convert an InputStream to a String.
This technique is for when your resource files are in the same jar as your java class files.
There are all sorts of places you can keep your JavaScript sources:
In the CLASSPATH. You fetch them with getResourceAsStream()
In the database. Yes, the database. You fetch them like you'd fetch any other CLOB.
Personally I've use both approaches for different purposes. You can keep your JavaScript files around in your build tree in a way that exactly parallels the way you keep .properties files. Personally I just keep them in with the .java files and then have a build rule to make sure they end up in the .war, but they can really live anywhere your build engine can find them.
The database is a nice place to keep scripts because it makes it much easier for your web application to support a "script portal" that allows dynamic updates. That's an extremely powerful facility to have, especially if you craft the web application so that Javascript modules control some of the more important business logic, because you can deploy updates more-or-less "live" without anything like a deployment operation.
One thing that helps a lot is to create some utility code to "wrap" whatever access path you're using to Javascript (that is, either the Sun "javax.script" stuff, or else the Rhino bindings; at this point in time, personally I'd go with straight Rhino because it really doesn't make much difference one way or the other anyway, and the Sun stuff is stuck with a fairly old and buggy Rhino version that in the current climate will probably not see an update for a while). With a utility wrapper, one of the most important things to do is make it possible for your JavaScript code (wherever it comes from) to import other JavaScript files from your server infrastructure. That way you can develop JavaScript tool libraries (or, of course, adapt open-source libraries) and have your business logic scripts import and use them.