I have the following requirement: Based on some user input, I need to generate a HTML form that the user can embed on a separate Web application. I thought on doing this with GWT since I'm familiar with it.
I'm clear on the input parsing and widget generation part. What I don't know how to do is how to export the root widget's (most probably a Panel) compiled code, so the user can take the code and include it in some other page.
Something like:
String rootPanelCode = rootPanel.exportCode();
Dialog codeDialog = new DialogBox();
codeDialog.setText(rootPanelCode);
Then the user copies the displayed code in some HTML file:
<script type="text/javascript" language="javascript">
//copied code goes here
</script>
Requiring a particular <div id="required_id" /> in the HTML file is not a problem. Or maybe javascript code is not enough, and the user is required to download a zip file with js and html files, copy those to a directory and reference them in the page. This again is not a problem.
Is my use case possible with GWT?
Thanks in advance.
I'd say... no :) Mainly because when a GWT application is started it first runs the bootstrap file that in turn chooses the particular permutation for the current browser. So the code that you would get might include some stuff that wouldn't work in all browsers. This might be side stepped by providing some sort of "lightweight" boostrap file/method to download but I doubt that would work.
Besides, the JS code you get is heavily optimized (and with GWT 2.0 the JS file contains JS, CSS and even images), for example, when possible strings are put into variables for performance reasons - but these variables are usually grouped together and put in one place in the compiled JS file, so even if you could somehow get to the code that creates your form, it could contain references to some undefined variables. In other words, the compiled code is meant to be used as a whole.
A more "elegant" solution (and more importantly, feasible with GWT ;)) is to export the form to some sort of abstract form/language, maybe JSON, so that you could parse/recreate it easily in the other web app:
{
"form1": [
{ "label1": "value1" },
{ "label2": "value2" }
]
}
Hmm, I just thought of a possible hack.. With the right use of code splitting it might be possible to separate the code responsible for the form creation - but that would make it maybe easier to "export", it's not a complete solution (and I wouldn't recommend it.. just an interesting/possible hack).
Related
For many projects I have worked on, programming teams work with the style of placholding every piece of static text in an xhtml file into a properties file. For example:
xhtml=
...
<h1>${messages.resourceBundle['key.to.static.text.placeholder']}</h1>
...
messages.properties=
...
key.to.static.text.placeholder=This will be the heading for this page only
...
Would anybody be able to explain what the advantage in this is?
So far, I can only see the following disadvantages:
making changes to any xhtml file requires you to hunt for the correct .properties file, and then the individual property to make the change to
if others have re-used properties, then deleting them becomes tricky as you have to be certain no other page is referencing the property, therefore after several change request rounds, properties files become large with redundant properties
if there are 1000 xhtmls, there will be 1000 .properties files to load, which is more cycles on the cpu to load and inject static pieces of text
if your using WebFlow and have flows that pass into other flows, properties have to be duplicated, meaning that sometimes you must place the same property in many different properties files to render correctly
hard to read code; if you know you want to work on the text 'This will be the heading for this page' only, you'll need to work out where that is on the xhtml from the property files first - you can't simply look at the xhtml and see clearly how the content will be laid out once rendered.
The only advantages I can see are text reuse and possibly html escaping.
Apologies if its coding 101, but I've had a hunt around Google and can't find the reasoning to the pattern.
Many Thanks
This is a common practice for internationalizing content.
You create one property file per language (or locale) and use a dynamic way off resolving which one to load depending on the context. (e.g. Language HTTP header the browser sends).
It is arguably more flexible than providing 1 jsp file per language, and can still deal with complex cases where plurals or stylistic differences might change the way you write localized text.
This is a standard JDK feature, lookup resource bundles.
You do not have to build 1 file per jsp (maybe your framework works this way?), although doing so can help the person writing the translation.
I'm currently developing some tests with HtmlUnit. It's loading a page that contains braintree.js (their form encryption library). I have a bunch running, but I'm stuck where it calls crypto. The JS in question is:
(function() {
try {
var ab = new Uint32Array(32);
crypto.getRandomValues(ab);
sjcl.random.addEntropy(ab, 1024, "crypto.getRandomValues");
} catch (e) {}
})();
HtmlUnit is throwing:
EcmaError, ReferenceError, "'crypto' is not defined."
I suppose HtmlUnit doesn't include crypto. Would it be possible to include a crypto library myself?
Based on your comment, I have to tell you that HtmlUnit is a pain in the neck when it comes to JavaScript. It will complain a lot about variables not being defined and unknown functions and so on.
Real browsers are more flexible, eg: they accept syntactically incorrect pieces of JavaScript. HtmlUnit expects everything to be perfect without any kind of error. Furthermore, even if you didn't miss a semicolon, HtmlUnit might complain.
My advice:
Make sure your JavaScript is syntactically correct
Avoid the user of complex libraries (jQuery seems to be properly supported)
If you can use non-minimized versions of libraries it's worth giving it a try
Try to avoid complex jQuery methods (eg: adding events dynamically to elements)
And the most important one: Try switching between different BrowserVersions. Internet Explorer (ironically) has proven to provide the best results when it comes to interpreting JavaScript
I notice that most GXT/GWT applications put the nocache.js file after the body tag. And few seem to put in the include in the header tag. Why is that?
Given the fact that the GWT script tag will be evaluated synchronously (the tag), but fetched asynchronously (the code, into an iframe), I don't see why not put it as the very first thing. Time saved!
Unless, you have some kind of complex logic that cannot have the chance to be properly displayed before the onModuleLoad() call (e.g., images evaluated but still not fetched), much like Steffen Schäfer pointed out. But you can defer you app startup for them though.
For more info, have a look here.
From my point of view there are 2 cases:
If you use GWT to only enhance your page that is generated on the server side then put the <script> at the end. That allows your browser to render the initial content of the page before parsing the JS code.
If you built a single page application that is completely generated by GWT on the client side, there's no content to be initially shown. In that case you can put the <script> to the head.
Be aware that 1. also applies if you implemented a loading animation or placeholder content to be initially shown.
AJAX is a very powerful tool so I am struggling with it :-).
Is there any way or API(in java) so that I can get the HTML code which is generated by AJAX?
Generally, AJAX make use of inner HTML code and hence this inner HTML code is missing when I look into the page source of a page.
e.g click here
Just see the section OTHER NEWS. The content is populated by AJAX. When I look into the page source the code is not there.
I need this HTML code through a java program. How can I get it?
To have a Java application use the content received via AJAX, you need to first find the URLs from where the content is getting called from. In case this it would be http://itm2083.com/get_wwo_content.php?featureGroupId=8355&featureDisplayLimit=1&sponsorName=vortalx&wwoDivCounter=5&domainUrlForWWo=http://item2083.com/&featureImgDisplay=FLAG_TRUE&featureGroupImageWidthLimit=200&featureGroupDefaultImageUrl1=http://wwo.itmftp.com/75x75.gif&featureGroupDefaultImageUrl2=http://wwo.itmftp.com/75x75.gif&featureGroupDefaultImageUrl3=http://wwo.itmftp.com/75x75.gif
The featureGroupId= parameter has 5 IDs: 8355, 8359, 8367, 8369, 8429. Use these to pull the content from the Other News box.
The featureDisplayLimit= parameter determines how much content is pulled from the server.
If you want the nice HTML as well, the Java app will have to recreate it, as the HTML rendered on the site is created by JavaScript code.
Ok, so coming from a background of mostly perl, and mostly writing dirty little apps to automate my tasks, I've read the pages about the evils of eval(), and I always use a hash (in perl). I'm currently working on a little project (mostly for me and a couple of other technical people at work), for creating "canned response" e-mails. To allow for additions, subtractions, edits, etc., I'd like to essentially describe the response form(s) in XML, and have my app parse the XML and create the response forms at runtime. I want to use Java (to integrate it into an existing Java tool that I created), and boiled down to a trivial example, what I'm trying to do is take some XML like:
<Form Name="first" Title="Title!">
<Label Name="before">Your Request:</Label>
<Textbox Name="input"/>
<Label Name="after">has been completed.</Label>
<Output>%before%%input%%after%</Output>
</Form>
<Form Name="second">
...
and from parsing that, I want to create a JFrame named first, which contains a JLabel named before with the obvious text, then a textbox, then another JLabel... you get the idea (I eventually want to use the output tag to control exactly how the response is formatted).
I can parse the XML, and get the element name and such, but I don't know how to instantiate the Objects with a name that is the value of a variable, effectively:
JFrame $(thisNode.getAttributes().getNamedItem("Name").getNodeValue()) = new JFrame(thisNode.getAttributes().getNamedItem("Title").getNodeValue());
I've read basically the whole first page of google results on java reflection, but I haven't come across anyone doing quite what I'm looking for (at least not that I could tell). Having basically zero experience with reflection, I'm curious if this is something that can be accomplished using it, or if I should take the same approach as I would in Perl, and create a HashMap or HashTable of Objects, and tie them to a entry in a Hash of JFrames. Or, I'm open to ideas that don't fall into those two categories. The Hash is sort of my stand-by answer, because I've done it in Perl plenty of times, and I'm sure I can make it work in Java, but if there's a feature (like reflection) that's made to do this task, then why not do it the way it was intended to be done?
What you're asking isn't possible in Java. It doesn't work that way and these sorts of tricks, which are common in dynamic languages, aren't the Java way. You can certainly do:
JFrame frame = JFrameBuilder.buildFromTemplate("frame.xml");
where you create a JFrameBuilder class that reads the XML and creates an object from it but the variable name can't be dynamic. You have to remember that there are two steps in Java.
Java source files are compiled into bytecode;
The bytecode is read by a Java interpreter (JVM) and executed.
What you want is essentially asking to execute code in step (1). Now annotations can do things in a compile step (like adding interfaces, implementing methods and so on) but local variable naming is not one of those things.
You could (not necessarily that you should) generate Java source based on your XML, compile the generated code, and finally, execute the compiled code. This could be more efficient if you saved the generated .class files and reused them instead of parsing the XML every time the program is run (it can check the timestamp on the XML and only generate and compile if it's been modified since the last code generation).