I have a small project where I would like to generate dynamic data entry forms with a little bit of logic behind them.
A simple use case might be
a Football resulting form, so you have a button for a goalscorer, and when clicked the user will be prompted for a player. The form will then send a message (probably to a webservice, but maybe a JMS queue) with the event data. eg Barcelona, Goal, Henry.
Then I want to create a similar form for tennis...
My idea was that I would create a webservice, where you define business logic. (events, components, actions you take etc.) Initially I thought I would send the sport definition from the webservice in xml. Then write an app to parse the xml and dynamically create the data entry screen.
I was initially thinking of writing a webservice and returning a xml data. (which will look awful) the rendering technology could then be flex/ flash and be a thin client.
Then I thought it would just as easy to create the forms as a java app using the swing application framework and that was the way to go.
Then I thought, well, rather than write a xml schema to describe the java forms, can I just serialise a java class and send that across the wire.
Once on that path, I am now wondering if should just a java framework, and the dynamic forms become class that are called by reflection.
I would love feedback on the above approaches, and how people on stackoverflow would solve this problem.
thanks
David.
I would avoid serialisation because it is a bit fragile, difficult to do safely and difficult to diagnose.
You say it's a small project, so does the metadata really have to pass from client to server? Would you not be much better off very simply writing the metadata (really code) as Java code?
(FWIW, my first commercial Java project was creating forms dynamically from a database specification (with regular additions). Previous to that I working with C++ running an interpreter for training systems. In both cases I would now (and for the last decade), have written them as Java. Don't be put off by people mumbling disapprovingly about "hardcoded".)
I would consider XForms as well. It allows you to define both the data model and the UI as XML, and all you need to render it on the client side is a web browser. I assume the event would be submitted to a remote server, which makes the web browser as a natural choice.
This would enable you to generate the UI on the server based on what kind of sport event the user wants to report about, so you can easily add new forms, fix bugs, etc. without ever having to update the client software.
By the way, I don't understand your concerns about using XML. In my opinion it's a viable option for your use case.
Related
I have a project that is built on Applets and that also comprises of Corba calls to backend (which is in C language). Now I need to remove Applets and convert it into JSP and Javascript combination. But the code seems to be complex as it also consist of backend calls. I am facing problem in figuring out what is to be converted in JSP and what in Javascript.
If I convert all the applet logic in Javascript, how will I pass the javascript data to the Java objects to pass it as input for corba calls.
I can't implement all the logic in JSP as the existing logic depends on the dynamic change of data by user.
I tried various links but couldn't find the proper solution to my problem.
I read somewhere that Google Web Toolkit (GWT) might help me converting Java Logic to Javascript, but couldn't figure out what exactly needs to be done for that.
Can anyone guide me how should I start and what exactly should I do to complete my project?
First the bad news. There is no generic and magic solution that can convert your legacy (as you are describing it) into modern n-tiers web application.
I can suggest you the following steps.
decide what kind of client and server side technologies you are going to use and learn them to become familiar enough to start coding.
learn your legacy code and re-design it. Decide which parts of the code must be re-written, what you can use as-is and what you have to change and/or re-package.
To choose client side technology try to search for "client side javascript frameworks" or something like this. Popularity of GWT that you mentioned is going down now. The most modern framework these days are AngularJS.
Concerning server side technologies I personally prefer Spring but you can take a look on Guice and EJB too. You can also implement whole server side as as collection of servlets. It is up to you.
Start learning this amazing world and come back with more concrete questions. Good luck.
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.
There are already a few posts on SO discussion whether this architecture is a good idea or bad idea. For many reasons within our company including the existing programming talent, we've decided to use Java for the backend and PHP for the front end. Our objective is something like...
Java - Models/Controllers
PHP - Views
We're working on building a prototype of the interaction between Glassfish and Apache. One thing we're still working on is when a user visits http://domain.com/login.html and they login, that login will be sent to the Glassfish controller which exists somewhere like /login.java. We can do that no problem, the trouble is getting the view to be rendered at that URL.
Has anyone does this with PHP or any other technologies?
Have you considered setting up a soap/rest server in java and having PHP talk to that? I imagine that would be much simpler than what you're trying to achieve.
I am sorry to bring this up but it seems like it would make things a lot simpler to stick with just one of these languages. If you are using PHP to add more logic into your view, it might be worth taking a look at Velocity. It allows you to access and create variables, iterate through lists, use conditionals, define macros, make method calls, etc. This seems like it might make things much cleaner. However, it is usually a good idea to try to keep as much logic out of your templates as possible.
If you would like to use PHP because that is what is required I would suggest taking a look at using web services to communicate. Take a look at Googles GSON library. It is really nice tool (on the java side) for mapping JSON Objects to your model (and vice versa).
On your front-end, it might also be worth taking a look at Backbone. It is a tool that makes it simple to mock up your model Objects and bind events to them, or add tie them directly to fields, etc.
I've had first hand experience at two companies that use the Java Service layer and PHP Client layer technology stack, although it was not used exclusively. To clearly separate the layers a well-defined JSON REST API was built so each layer had a contract it could code to.
The Java layer used SpringMVC in-between the persistence layer to generate JSON views with well-defined routes (i.e. URL structure) in order for the PHP layer to GET/PUT/POST/DELETE resources.
Regarding the login issue specifically, there were actually two Java services, one specifically for login/logout and the other for the regular backend.
When visiting /login which I assume would be a .php file. A submit of the login <form> to the "Login" service resulted in a session cookie being added but also an encrypted "user ID" cookie. The encrypted cookie could then be used to protect access to the Java Service layer for the product. Each REST request from PHP to Java would have access to the cookie, and the Java layer could then decrypt the "user ID" and respond to the PHP REST call if it was valid. The Java layer would then have access to the real user ID in order to return user-specific data from the persistent store.
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.
It's not a very concrete question. I created a simple project with a help of this tutorial, it's really fine. All the GWT code samples related to JSON I saw so far seem to work with a JSON (or immitate this work with some mock-up JSON), that is retrieved and processed in GWT. I'm a newbie in GWT, and I wonder, what are the cases of interacting with services that return JSON (services are mentioned in the same tutorial) and what are the pros and cons of such interaction.
I thought about two options (well, service is an overloaded term):
everything that is mentioned in these JSON GWT tutorials is about the third-party services, like GData and Yahoo! Web Services mentioned here, which would make sense, cause it's about retrieving some data and processing in the app,
and the second option is about services, that are created within the confines of a project (and, if there are some cases, and definitely there are some, my question is about them).
It's probably can't be fully explained in the answer, so a link (or a few) would be appreciated. Thanks in advance.
Your question is really quite generic. But here are some pointers:
JSON is just a data interchange format similar to XML or Protocol Buffers or some other proprietary format.
They are necessary in modern web applications because the UI is entirely controlled by the javascript code running in the browser.
However the data that a web application presents to the user usually resides on the backend. In order to get the data from the backend to the frontend you have to use some data interchange format like JSON or XML.
The advantage of JSON is, that is fairly efficient compared to XML and well accepted.
As you mentioned there are third party services that rely on JSON. These are very useful when you want to include the services in your applications.
The biggest advantage of applying this service oriented approach to your own project is that you decouple your components (frontend and backend). By doing this you achieve following things:
Make your services available to other (web-)applications and users because your service exposes a specific API/data exchange format that they can use.
Easily replace or add another frontend (for example create a desktop application in addition to your GWT application) that can work with your data (display or modify).