I have an MVC application where all endpoints are simple ReST styled MVC endpoints that return static pages, i.e /customers/${customerId}, or for a customer listing /customers?state=${state}.
I'm adding mobile support through jQuery and am trying to establish a flexible design while fitting in with the rules of jQuery-mobile.
The first problem I face is that jqm is very much an ajax style UI framework where pages are loaded into the current document, or you build them all together. Given this I find it hard to see how static URI's would fit in, i.e. if I have /customers/123 and /customers/456 they are both the same view but different content, so should I then be controlling everything through ajax?
But then what if someone accesses the site via /customers/789 instead of home and then navigating? How is this controlled if everything is done via ajax?
I would love to see a petclinic style example using spring and jqm.
Related
I've done almost all of my web projects using Java(Spring MVC + Thymeleaf) and it's MVC technologies. Recently I've heared about REST and started learning some stuff about it. I realized that it is one of the coolest things I've ever seen in my whole life!(I'm just joking around, it's definitely not)
All we need is just to parse data to json type and then return it to the frontend. And in frontend we no longer need to use Model and it's objects. Frontend can get all required data in nice-to-work-with json type using one single GET request!
We don't need to use some weird Thymeleaf constructions to handle errors or to iterate through the list in our template! We can handle all events and process all data using javascript and it's frameworks. It is much more powerful.
Does there exist something I missed? When to use Model? When to use json-type data?
These are two (somewhat overlapping) approaches to frontend development: generating pages on the backend and on the frontend.
Using a backend model and Thymeleaf templates (or any other HTML templates), you generate your web page on the server side. This means the following benefits
you can write frontend and backend logic in one language (Java);
you can enforce data and security constraints in one place - on the backend, using Java code or configuration;
in many cases, it's faster for the user to get their first page, since the rendering happens on the server, and the user gets an already rendered page;
But this approach has the following drawbacks:
the server has to render the pages, which means more load on the server;
most of the modern web sites and applications use JavaScript anyway, so you'll have to write at least some JavaScript;
server-generated pages don't even come close to what's possible to render in the browser.
Providing a REST API for a JavaScript frontend, you have the following benefits:
you unload your server, since most of the UI related work happens on the user's device;
you can achieve much more with modern frontend frameworks;
navigating on an already rendered UI is faster, since you don't need for the server to render every page, you only need to get a relatively small JSON response and then update the page dynamically.
But this approach has the following tradeoffs:
the user generally waits longer to see their first page, as the browser needs to download a lot of scripts and then spend time on dynamic rendering of the page;
in a large application, you need to either have a full-stack developer team, or two teams working on frontend and backend separately;
you have to write your UI logic in JavaScript. Make of it what you will :)
you have to sometimes duplicate the constraints both on the frontend and on the backend: e.g., if a user can't edit a field, you have to both show it as read-only on the frontend, and add validation in your REST service, since the user may try to access your REST API directly and bypass the frontend validation;
you have to be more aware of securing your REST API in general.
I am new to REST and watched few videos and read few blogs on REST webservice and I came to know that generally people are using REST for supporting multiple devices like mobile and computer etc.
Now consider I am developing order management system and I want to support both computer as well as tablets. If in m traditional web application, I am using Spring MVC at front end, how REST will fit here so that it will support both the kind of devices.
One more doubt is, whatever examples I have browsed, it return html or json data. I want to develop the application the way spring MVC or struts works like returning name of jsp and jsp will be rendered with dynamic data (instead of returning string represented html).
I hope my question is clear. Please bear me as my questions are vague but I am looking from implementation and design point of view.
Just to start REST isn't anything to do with supporting mobile browsers. It is the architecture pattern HTTP follows. The Web had been REST since the early days.
I'm guessing what you mean is a server that returns light weight JSON that the client renders into HTML rather than the server returning HTML directly to browser. To do that you can use a java script framework that expects JSON data and that has a template engine to generate HTML on the fly in the browser. I think Anglar and Ember work like this.
Though I would only do this if you need to, and you don't need to do this just to support mobile browsers, you can support mobile just by making sure your CSS is responsive.
in standard "page-based" webapps, it´s quite easy to implemet direct links to several pages, f.e, an url abc.com/app/customer/4711 which directs the user directly to the page diplaying customer 4711.
Is there a way to reproduce a similar behaviour in an GWT-App?
Tnk Mica
You can use Activities and Places design pattern. It provides easy access to any "place" within the app:
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
Every once in a while this question is being asked in one form or another and I think misconception exists about what GWT is best suited for.
GWT is an amazing set of tools for creating web applications: JavaScript multi-screen user interfaces which run in modern web browsers, load as a single web page and generally don't need full page reloads or page switching for their operation.
Navigation between screens happens in response to triggered events (for example, a user pressing a button, a timer firing or server-side state changing). The data needed to be presented is acquired asynchronously via XHRs (again without web page reloading).
GWT provides an elaborate framework for all of the above - Activities & Places for navigation, as Andrei mentioned, GWT-RPC and RequestFactory for data acquisition and exchange, and much much more to make advanced and highly-structured web apps which leverage the processing power of modern machines and capabilities of modern browsers.
I want to develop a Web Application by combining Spring Framework, GWT, Servlets, JSP........
I plan to develop Server side using Spring,Servlet ,JSP....
And for Client side, GWT....
The Output page(Response page) of my Application, will given by JSP only....
Then what is the use of GWT at client side....
please clear my doubt....
Read the following
1) AJAX - http://en.wikipedia.org/wiki/Ajax_(programming)
2) RIA - http://en.wikipedia.org/wiki/Rich_Internet_application
3) GWT - http://en.wikipedia.org/wiki/Google_Web_Toolkit
The problem with using purely jsp to create a web application is that each user interaction typically requires the entire page to be reloaded. Depending on what you're doing this approach is considered outdated. GWT is built on top of javascript and xhttp requests, allowing user interactions to affect only relevant portions of the page. This generally results in a faster and smoother user experience.
If you have already decided that you want to use JSP, then you don't need GWT. Although you could use it to create custom dynamic components and embed them on your page. Or to create a part of your application where you find JSP not sufficient (which would be probably a part that should be more 'dynamic' and would require a lot of javascript).
http://code.google.com/webtoolkit/overview.html#how
I am new to GWT and am going through the docs, examples, demos etc.
All the examples seem to have just one module which is loaded by a single html page contained in the sample.
What if the web app has multiple web pages/features. Can multiple web pages providing different functionality utilize the same gwt module by building the UI differently based on request params?
Or is it normal to create one module per html page (feature) in the app?
You can have a look at these two questions:
Multiple pages tutorial in Google Web Toolkit (GWT)
GWT with multiple host pages in a legacy application
...or at this site which guides you through the process, if you are new I strongly suggest to subscribe to the 5 days email course.
Usually a GWT module contains multiple 'screens', or 'views'.
In short: Yes you can have multiple different pages in a GWT app.
Full: You can do his in several ways, the easiest is to use the XML file where you can list the various URL points (the same you use to specify the RPC call back URL) to list multiple URL's and the corresponding classes (each class will need to inherit the correct classes to ensure it is a front end)
You can also simply generate different screens based on different variables in the same class, however this will complicate the code and lead to messy designs.
I think that using less number of the pages that needs full page reload to interact is better in GWT.
In generally, you can to divide logic to many tabs, screens, windows and other layouts, that can interact without page reloading.
See on the google mail )