Handling element attributes based on user roles in GWT - gwt

I am trying to tackle a quite common scenario in GWT based application.
If user has role 'ROLE_A', then show him only 'Search' button. All the
other buttons will be disabled.
One way to address this is by calling an async service to get the user's roles and then handle the visibility/accessibility of different UI components.
Is there any generic way in GWT to address authorization? I referred to Handle Authorization in GWT application and Using GWT Generators for custom annotations but couldn't get whatever I need.
I'm using GWT 2.4.0 with Spring 3.0.5.
Any pointers would be much appreciated.

The way I do it (and I think how it should be done, really) is to include the roles into the HTML host page, rather than getting them through an additional request. Have a look at my dagger-guice-rf-activities archetype for an example (using Guice and Servlets security, but easily transposable to Spring)
Then on the client, use plain Java ifs to handle the UI. And for those big parts of the app that only some users will see/use, use code splitting so other users don't have to download too much code.

Related

GWT CRUD GUI Model

Good day. I'm still learning GWT so please help me. I'm working on a project - Web Application with GWT on the Client Side. This app has lots of CRUD operations so I'd like to make a model for this. Can anyone suggest a prototype for my CRUD class?
CRUD on this app goes something like this:
When I clicked the Details button in a module, a popup will be shown that allows the user to do CRUD operations. This popup do have the module title, info on the selected item, and the buttons - Edit, New, Delete.
I have already finished building the base GUI for this project but I'm just starting to work on each module. I choose to begin on those module with CRUD operations. So, please help me and give your ideas on this project. Thanks in advance :)
Your question is a little bit general.
You probably have to deal with two questions which can be handled separately:
Communication with the backend.
GUI for CRUD operations
Communication with the backend:
It depends on which kind of backend you are using.
Java-backend:
For Java backends the recommended client-server communication protocol is RequestFactory.
Non-Java-backend: In case you are using a non-java backend (python, PHP, etc) you have to use RequestBuilder using JSON or XML (I would recommend JSON).
For mapping JSON/XML to DTO's and vice verca you can use different methods:
Third party tools like piriti which are based on GWT generators
Javascript Overlay Types (JSO)
GWT Autobean framework (which is used by RequestFactory btw).
GUI for CRUD operations
For mapping your DTOs to your UI and doing the CRUD operations you can do it either:
manually
with the Editor framework
I would recommend to use the Editor framework as it reduces the amount of boilerplate code
to move an object from your object graph to the UI and back.
The Editor framework works well with RequestFactory (RequestFactoryEditorDriver), Autobean (SimpleBeanEditorDriver) and Javascript Overlay Types.

How to add edit-layer as Plack-middleware?

I have an idea to add a edit-layer to website as a Plack middleware.
Explanation: let's say, we create a website, based on some framework and templates and CSS (requesting it like /some/page). Now we could create a middleware so that every request to pages starting with adm (like /adm/some/page) shows the same page, but adds a layer for content editing. So we could easily look and use the page as visitors do, but with double-click on block-level element we could modify or add content. So middleware should bind certain block-elements with certain events (double-click) and set handlers too (with some Javascript library).
For now it is just an idea and i have not seen such approach in any CMS. I am looking for hints and ideas and examples, how to start and implement such system. I hope, there is already done something like that.
You could do it, but I don't think you want to do this. My understanding is that Plack::Middleware's are supposed to be generic, and implementing a CMS as a plack middleware limits its re-usability, and its out of place, there is no inherent connection between a middleware and a CMS.
See these as examples Plack::Middleware::OAuth, Plack::Middleware::Debug, Plack::Middleware::iPhone, Plack::Middleware::Image::Scale, Plack::Middleware::HTMLMinify
It would be trivial to add a middleware filter to insert a form in your html based on /adm/ or /admin/ or whatever ... and mapping the url to the dispatch would highly depend on the underlying CMS model/view/controller framework, which is why frameworks such as Catalyst, Mojolicious and other already provide this feature
See http://advent.plackperl.org/2009/12/day-23-write-your-own-middleware.html
Basically, I think this is a job for a view/controller of your application, a plugin, not a wrapper for your application (middleware)
I know my explanation is lacking but hopefully you catch my drift

Complete GWT based sign-up system

have anyone come across a complete GWT app with registration/sign-up page to start with--unlike with PHP. Until now I haven't find such app that have the ability to register user, have the user a 'user page' and so on. With integration to MySQL and other db to persist user data. Does anyone know such code to start with.
A GWT app is quite useless without an appropriate backend (Java, PHP, Python, etc).
In the end GWT code is only compiled to client-side javascript code. With client-side javascript you can't access any database on the server and thus any GWT app also requires a backend in order to access a database like MySQL.
So in order to create a registration/sign-up app you have to write both backend and frontend code.
For the frontend and the UI respectively you can use GWT. For the backend you can use any server side technology. The tightest integration with GWT can be achieved with a Java backend but you can also use non-java backends like PHP, Ruby, Python, etc.
GWT will communicate either via RPC/RequestFactory (Java) or RequestBuilder (non-java backends). Fore more information refer to the GWT docs.
So I recommend following steps:
Decide which backend technology you are going to use. Java offers the tightest integration (RPC,RequestFactory, etc). However for small/simple apps sometimes it is easier to use non-java backends like Python or PHP because they can be setup/implemented faster/easier.
Implement the business logic on the server-side. In your case this includes among others "adding new users to the database", "signing up users", "retrieving user information", etc
Design and implement the UI with GWT. In your case this will be the user-page and the form to fill in details for signing up, etc.
Write the communication part between frontend and backend in GWT using RequestFactory/RPC (Java) or RequestBuilder (non-Java)
What kind of application are you going to develop? If your project is a public website and you plan to run it on GAE, you could use Google App Engine User Service.
http://code.google.com/appengine/docs/java/users/
For enterprise apps this is probably not a valid option...

The Output page(Response page) of my Application, will given by JSP only.... Then what is the use of GWT at client side

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

General question, what do you want from a web framework?

In a MVC application, what are some of the components that make up the application. What tools and functionality is missing that you would like to have. Regardless of the server-side language, what would you want?
I see a lot in my code where I code some much functionality that it seems should already be there. I looked at Google web toolkit and they seem to get it right. Widgets are widgets and you simply add them to your application.
For example. I work with J2EE apps but in other languages, the components are the same.
Controller Objects
Controller handlers, defined by methods in the controller objects.
Configuration files defining the URL mapping and settings.
Template server page files (e.g. JSP/ASP files).
Configuration files defining O/RM mapping between application objects and the database.
Configuration files defining the database connection properties.
JavaScript libraries (e.g. jQuery)
Logging configuration files
Resource message bundle files
Validation configuration files or code
Middleware components and objects (EJB configurations, JMS/Messaging configurations, etc).
Credit Card or other middleware connectivity APIs and libraries.
Anything else you can think of?
Built-in Unit Testing Component
I think one thing you're missing from that very exhaustive list is the automatic binding of request properties to form objects, and the saving of these objects to the session where appropriate. Form objects here being the object on the server that represents the current state of the HTML-based for displayed to the user.
I think scaffolding and automatic admin interfaces are very nice features too, that I dont want to miss ;)
You've made the assumption that all MVC applications are websites. MVC is widely used for more than just web apps so things like URL mappers, template server pages and "Server side" languages are not associated with the MVC pattern, so much as a particular implementation and adaptation of the MVC for use in web apps.