I am writing a simple enough program using JSF, and I need some advice about how to go about it. I have a jsp which takes a unique ID and has to find out if the ID exists in 3 different databases. If it does it should display a message telling user, where it exists, otherwise it should give the user option to add the ID to a particular database.
I have the jsp page which has a text field for the input ID and I have a button called "Submit" which should trigger the process of querying the db to see where the ID exists. My question is, how to structure this project, in terms of front end, middle teir and db layer.
I have a JSP page, when the user clicks the Submit button, I have a listener in the managed bean which gets executed. I have also read up that the listeners can either be a managed bean or a separate class. Should I have a separate class which is the listener? If so, should it be a Servlet mapping in the web.xml file, so all request get forwarded to this class. Should there then be a separate DAO class where the actual query
gets executed. We are using hibernate as well.
I would jsut like to hear people comments about how many classes there should be and how a particular ID Check will flow through the program from JSP->Servlet(?)-> DAO and then back to the same jsp. There is only JSP , there will be no other navigation pages.
Any direction will be much appreciated.
I have used Spring in the past, and this would be a breeze fore me with Spring, using the Controllers to delegate the requests to the appropriate service, and then the service would call the DAO class. But here we are using JSF and it has to be a JSF web page. I have not used JSF before so I am unsure about the different components needed. I have the front end jsp and a DAO class with the actual query, just wondering about the middle tier, with business logic. How does the front end request after clicking the Submit button get to the middle tier, what wiring is required? Is it in the web.xml?
I would suggest you take a good long look at Spring framework. Here's a Spring MVC tutorial to get you started.
Related
In the existing application there is a requirement to put some filter when any service is being called from the managed bean.
Filter is across the service call and will do some configured validation either using some config file or Rules Engine and based on it will popup a message that need user input and accordingly will proceed.
Problem is that ones the request goes out from managed bean i am not getting the way to popup a message with user input.
Any help or suggestions are welcome.
it's a bit difficult without code to see but you can try calling FacesContext and create FacesMessage object into a java filter.
I want to serve some data from an static url in Liferay. For example, say to serve a json containing the logged user from "http://server.com/whatever/user" so all the portlets in the proyect can read it. Right now I can do it with a portlet, but then I have to set the url with the configuration panel and I don't like that.
I've seen that I can put jsp files with the static content, but don't know how to access the information of session, users, etc.
Friendly urls seem to accomplish something similar but seem overly complicated and focused in getting a short easy url, something I don't care.
So, how can I get some internal data in an static url (I don't mind if it's friendly, long or short, but always the same) so every element of a Liferay proyect can read it?
FOURTH EDIT: Another way to put it...
In my eclipse I have this tree:
/whatever-war/docroot/html/fancy-porlet/list.jsp
How do I access that jsp in a browser without having to go the Liferay panel and putting the portlet in the menus of the web?
FIFTH EDIT: I haven't had the time to research any more, but I have this in my notes...
https://server/language/c/portal/layout?p_l_id=plid
This goes straight to the portlet, sometimes. plid comes from
PortalUtil.getPlidFromPortletId(themeDisplay.getScopeGroupId(), name_of_portlet_and_war)
It's no solution for me because, it doesn't always work. Sometimes you get a numeric identifier, sometimes you get a zero. I'd bet on the name of portlet and war being incorrect so it doesn't find the portlet, but then, how do you find the new name of the portlet? Sadly, I discarded the code where the name came from, but is coming from Liferay.
SIXTH EDIT: What I want to do is to be able to call a fixed url, with some data internal to Liferay, and get information based on that data back.
There are several aspects here:
Every portlet already has access to the user through a request attribute called ThemeDisplay:
ThemeDisplay themeDisplay = (ThemeDisplay) request.getAttribute(WebKeys.THEME_DISPLAY);
Check ThemeDisplay's interface for the various options that you have in order to get the current user's id or object.
You've asked about JSON delivery - this will need to go through Liferay and not (directly) through a JSP in your individual web application. The reason is that any request processed by Liferay will contain the user's information, but as any proper webapp, it's completely separate from any request directed at another webapp: Unless included by Liferay, your JSP will have a different session that has nothing to do with Liferay's session. (I hope this explanation makes sense)
If you write a servletFilter hook, you might not yet have the portal context initialized (Liferay 6.x has been a while for me, pardon for being vague here). If you're on the portlet side, you might have to do more than you expected.
One option that you have is to embed a portlet on every page, automatically (e.g. when it's deployed, it's available). You can configure a portlet to be automatically included on every page, it's done for the chat portlet, for example. That portlet does not need to have any UI, it just needs to expose its resourceURL, so that you can use it from everywhere.
However, I somehow doubt that you use it, given that every portlet has the information already at hand.
But I might also just not understand all of your requirements...
When a user clicks a button on JSF, a managed bean receives the input value from front end. To process the request and respond, when should or shouldn't I implement a CDI event? For instance, to print back "Hello World" to html page after a user clicks a button on a front end JSF page, I can implement a CDI Event using event-observer model, or I can do the same thing in many other ways.
My question is, what are appropriate scenarios to implement a request-process operation as a CDI event? Thanks.
Usually you want to use events when a request from user will affect multiple parts of application. Let's say user changed some settings it his profile and they are multiple components affected by this change so you can fire up an single event and all these components will be able to handle the configuration change.
Another argument for using events is to decouple your components so there are less dependencies in your application.
So for your example, events are probably overkill for such simple operation as printing Hello world.
I'm pretty new to EJB + JSF and I'd like that my webapp's entry point would be a method of a bean instead of a view.
I mean, when someone types www.mypage.com I'd like it to go to a method of a bean and then be redirected to a view rather than go to any xhtml... how can I do this?
EDIT:
I need to load some data from the database to show it in the view that the user sees when he enters the app. It's not authentication, it's just that I need some data to be loaded before the user sees the website.
Annotating the method that loads the info with #PostConstruct gets the work done :D Thanks to Luiggi Mendoza http://stackoverflow.com/users/1065197/luiggi-mendoza
In our current prototype most the standard HTML controls are replaced by an applet, most important the form submission is triggered by the applet.
Is there a way to call an associated action on the server side much the same way as with
<h:commandButton action="#{ctrl.doit}"/>?
This article Applet and JSF Integration - example had the same question but not a suitable answer. The applet is a drop in replacement for a form from the viewpoint of the server. It fills dedicated (hidden) fields and submits - no direct communication to a server.
EDIT
So far, i understand there are these integration possibilities:
add a (hidden) UICommand and trigger it via JavaScript
Implement a UICommand of your own. As far as i understand, i'd define a hidden parameter for marking the applet as the form submit control, in the request processing cycle the UICommand implementation will find out and trigger the action. Maybe one should implement a virtual control (comparable to f:viewParam) as an endpoint for MethodExpressions.
Attach a listener, either to a (random) control or a more general event listener and do your stuff here. In this case, how is navigation done?
This is not possible without having a physical JSF view in the very same page which has the applet embedded. So, you should really at least have a <h:form> with a <h:commandButton> in the same page, if necessary hidden by CSS display: none;. This is simply because JSF needs to have a view state of that form in the server side, among others to prevent CSRF-like attacks. If having a physical <h:form> in the page is not a problem for you (which seems to be true in your particular case), then you can just let Applet fill the fields (if any) and click the button of the form using Applet-JavaScript communication.
Other than that, a simple servlet or a real webservice API like JAX-RS/JAX-WS is really the best way. JSF is a component based MVC framework and not a webservice framework. That's what my answer in that linked question is trying to make clear: use the right tool for the job.