Trying to get a GWT project off the ground and finding it difficult to do any basic routing.
Trying to fire up different UI's based on the URL. Thought I could set a string based on the getHash() and then switch off that, but seems cumbersome (and annoying since I can't do string-based switches in Java).
There's got to be a best practice for this. I know Gerrit uses hashes for determining this type of information but couldn't find where they do it in the source.
Or is this totally not GWT-related? Something I can handle in web.xml?
Any help is much appreciated.
If you want to load different UIs by using different URLs, instead of doing it directly from client side (gwt code), one way I can think of is to separate your application in several modules and have different host pages (dynamically generated from server side) load each module.
Not sure it's the best way, but I guess it depends on what type of application you're building.
So far, in GWT I only built desktop like applications so... once I loaded the GWT app I didn't cared about URL's and stuff.
Url's can be loaded using a "Place" manager. Support for this is handled through GWT presenter:
http://code.google.com/p/gwt-presenter/
import net.customware.gwt.presenter.client.place.PlaceManager
Related
I am planning to allow users of my JavaFX program to select a custom CSS stylesheet, so that they can fully customize their UI layout and design.
I am wondering whether this is a safe idea as I am aware this can be dangerous for certain programs as it allows for people to inject code, though I can't seem to find any information on the possibility of using CSS for anything other than defining styles in JavaFX.
This is not a topic you need be concerned about.
Only read on if you are still concerned...
Ah, so there is no chance a user could use a stylesheet to somehow manipulate the program maliciously?
Well I would not say no chance. Software is complex and exploits can be unusual and unexpected.
But, the chance that it would happen and cause enough harm to the users of your app that it was worth investments by yourself in potential countermeasures is IMO, infinitesimal.
Your, and other’s, effort is best spent elsewhere. Use secure servers and packaging, use up to date frameworks and libraries, patch or redeploy for known exploits, etc.
A JavaFX app where you supply all the code and the app is installed as a package on a client machine is an inherently different attack surface than a web browser sourcing from many network locations that you do not control.
There is no server side cross site code injection without cross site servers. So trying to apply a website css attack (which is not normal by the way, most site attacks are scripting, phishing, server infected malware, etc) to a JavaFX client isn’t going to work.
If you are still concerned then do your own further research into the subject.
Context:
I have created a 'desktop' (console-based) Java application in Eclipse. I am using several third-party APIs to help me with the logic of my application. There's currently about 1000 lines of Java code.
I would now like to make this application browser-accessible. All I require is a few buttons and a few tables. The buttons (including a file upload button), upon being clicked, would run my 1000-line java code, and then output the text results into a table or two. I might require a few drop down boxes. All that matters, is that the application is accessed through a typical Web browser.
In another project, I have previously used ASP .NET Web forms (C#) to create a browser-accessible Web application and it was extremely straight forward. I simply dragged and dropped the buttons and tables I required. And coded the logic behind each button, and simply pressed "play" for it be usable through the local Web browser. I could do the CSS styling through VS to make it look pretty if need be.
Questions:
Sorry for my simplistic nature, but what is the "Java version" of ASP .NET C# Web Forms? - that is, drag and drop UI components for a web form that I can simply tack code behind, that can be easily deployed to a browser.
What's the "fastest" route I can take to achieve my goal? I simply wish to deploy my console-based Java application into a browser-accessible stand-alone application. It only needs to run on my local machine.
Notes:
From the reading I have done, it appears that I can use JavaFX for my purpose? - that is, create the UI and code the backend. And apparently, I can simply package the desktop-based JavaFX application to be runnable through the browser.
I apologise for any shortcomings of my question/context; I tried to keep it succinct so I may have generalised a bit. Not in the greatest mindset at the moment...
As for question 1, that would probably be JavaFX. It has the UI builder, and can be deployed to the web as well as to the desktop.
As for the general question, there are dozens of solutions, too many of which to cover here. The most straightforward and common solution would be to write a servlet. You would have to do all the mapping from HTTP URLs and request parameters to the appropriate model objects and then convert the model objects to HTML yourself.
Built on top of that are plenty of tools which can help you with the request mapping (JAX-RS, JAX-WS, Spring MVC, ...), and the conversion from model to HTML (JSP, Apache Velocity, ...), and everything in between.
In addition to Servlets and JavaFX, there are probably also several other options such as GWT and Flex. Figuring out which one is the "fastest" would be a broad and subjective question and so the best I can do is list some options.
i'm working on a project which needs to support internationalization.
the solution we thought of is:
create HTML templates with placeholders for language (i.e. home.html).
create an i18n directory with files such as: "language_en_GB.json".
on the build process have them merged together to create an output HTML. the output file will sit on a language based directory (such as "views/en_GB/home.html" or "views/fr_CA/home.html").
so basically this:
<h1>{{i18n_welcome}}</h1>
<h2>{{userName}}</h2>
merged with this:
{
welcome:"Welcome!"
}
will become this during a build proccess:
<h1>Welcome!</h1>
<h1>{{userName}}</h1>
i have a few question and appriciate your input.
is this a good approach for i18n?
do you know of a templating engine that does that i18n process well?
is there a solution for client side "baking". i would like a UI developer to be able to bake localy as well.
There are several frameworks that support i18n out of the box depending on your needs and what you are currently using in your code. As a pure templating engine, you can take a look at Velocity or Freemarker. For a more complete framework, you can look at Spring and Spring example and Struts and Struts2 example.
There are, of course, numerous other options as well. I'm just listing four of the most popular that I've seen people use.
Basically, for any of the frameworks, you create resource bundles for each language (named using the language for the specific bundle. Ex: language_en_GB.properties). So your thought process is pretty much in line. Basically you start with your html file and include your placeholder. In your resource bundle for each language, you specify what the string is supposed to be. After that, the framework does the merging on the fly for you, using the appropriate resource bundle for the language in question.
So you're pretty much on the right track - it all becomes a question of integrating properly with your framework and leveraging it to do the merging instead of doing it during your build pipeline.
You failed to provide the necessary details, so I can't really answer your question. I can only say that what you plan seems to be another wheel re-invention (but not as round as original one).
There are certain i18n best practices. In Java world it usually mean using Resource Bundles (in form of properties files) and some mechanism like JSTL to translate them when the page is being rendered. This is the best approach, as you won't need to re-compile anything to introduce the support for another language.
If you care about providing support for client-side scripts, it is usually done by writing out some array from the web page and accessing it on the client side. I think this is the most common solution. Another would be having some web service to provide you with translations and read it via XHR (i.e. AJAX), but that may be problematic. Anyway, you need to push the translations from the server side to the client side somehow.
And of course you need to read them from resource bundles.
From what you wrote it seems that you want to build some kind of static web page, backed by the application server (thus static web pages compilation). If I guessed correctly, honestly using Java for it is a bit overkill. You'd better go with some CMS software like Joomla, Drupal or jEase.
I am developing an client-server application where client gets updates every second (lets say 1000 fields) . I also need to draw waveforms from at client side.Server is already existing.
For this type of application which will be better ? GWT with intermediate server or Java Web Start which directly connects to existing server in terms of performance, difficulty to code ?
I don't see that much difference among them. I'd even say that they are separate things. Webstart is how your client will get the app: from some site.
Webstart is a bit easier to mantain, since your client will get it everytime it starts.
Deploying a stand-alone can be a bit harder, depending on your infrastructure.
Performance: just the "download" part of the webstart can be a bit heavier. I thinkg performance is almost the same, after ir began to execute.
Difficulty to code: it's just a matter of experience. Your code in both them will be almost the same, since they'll do the same things.
Mantain / upgrade : easier to mantain and upgrade the Webstart than installing a client on each machine.
Consider using a JFreeChart DynamicTimeSeriesCollection, seen here, distributed via java-web-start. A thousand fields in a scroll pane is possible, but JList or JTable would be considerably more efficient.
If the server already exists, the issue is more about the best way to connect it to the client, than whether or not to use GWT. For example, if you want server-push rather than client-pull for the updates, that changes things somewhat. However, assuming you need to do some vector graphics, and pull information from a server (I'll assume that you can use either JSON or XML to get server information), you could use several different JavaScript toolkits to do this directly, without Java or GWT needed at all.
For this type of application, Dojo would be one fair option. It has fairly good portable vector graphics, it's pure JavaScript and it is finally at a stage where documentation is OK. GWT would be a useful bet if the server didn't already exist, and where you wanted a decent set of controls usable on the client side. But for rich graphics, I'd look at JavaScript options like Dojo, Raphael, or even jQuery. Dojo does support line charts, and that might be a good basis for waveforms.
Some of this depends on the nature of the server. If it uses a different protocol from HTTP, or doesn't really provide easy JSON or XML access, you're probably better looking at a client-server package that does make the bridge between client and server simple.
GWT might be an option here, but it is designed more for robustness than for very fast development. And if you are fitting with an existing protocol, it could be a fair amount of work.
I am no artist/designer so usually my GUIs well, you know... I've tinkered a bit with GWT and I was able to get sensible results but I feel I have used contrived ways of getting those results.
If the community feels this question could help: please put one recommendation per answer.
We identified the following high-level best practices for GWT 1.6/1.7 (just after 3 months of research and development):
Use design patterns (MVC/MVP, Command for GWT-RPC, Composite for widget composition, Observer for event bus, etc.);
Isolate application logic with MVP by abstracting out widget classes and views using presenter display interface and GWT characteristic interfaces (such as HasValue, HasText, etc.);
Use dependency injection with gin on a client and Guice on a server (or stick with existing server framework like Spring);
Use GWT Composite in combination with HTMLPanel to drive your views with html, css and MVP;
Use mock testing based on isolation of application logic with MVP;
Implement Event Bus with GWT HandlerManager;
Use GWT modules to effectively optimize code compilation;
Use client, shared, and server packages when organizing GWT modules;
We have developed a large HR portal with GWT. The look and feel of this application can be customized for different deployments. To do this we use fragments of HTML to generate parts of the GUI i.e. bits of HTML are sent to the client in DTOs and then stuffed into HTML widgets. This approach works well for mastheads, logos, menus and so on.
Other things (e.g. capture forms) are generated using normal GWT code.
We use "pages" (different history tokens identifying where you are) as this makes it possible for users to use bookmarks in a meaningful way. We also generate links to different parts of our system in emails and so on.
Our application is composed of a lot of "higher level" widgets we call "Portlets" arranged into "pages" defined in XML. Again this makes it possible to customize the functionality for a given installation.
All this is done using a framework (GWT Portlets) that we have published as open source.
The best practice is to do everything from Java, so your HTML only acts as a placeholder. Yes I hate to say this, but if you're still messing around with the HTML it only makes your life more miserable.
If you still have the only web mindset, which is separating webapps into several html pages, throw that away, get the building the desktop app (that run on the browser) mindset. Think of building swing apps.
If you need to style the GWT components, override the GWT's css classes in your own CSS.
The last best practice is to decouple your application with the MVP pattern. The reason is because you can basically write the whole application in one Java class, which of course can lead you to maintenance hell, and problems if you are working with several peers.