I'm working on project which uses JSF as UI framwork.
There is a lot of huge forms which contains many <ui:include> tags referring to other part of pages and they also includes others etc. When you drilling into structure it's really headache to hold it in your head.
So, my question is there any feature in IntelliJ Idea (or maybe in other IDE) which may graphically show such hierarchy?
Thanks for advice
since filter only work well when i use page-redirect=true on every commandbuttons' action, i am looking for a usable alternative.
all i have now are two filters (which don't work well):
Filter A -> /pages/* (Filter checks if user is logged in)
Filter B -> /pages/restricted/* (filter checks if user has admin permissions)
because of the navigation-procedure by JSF they do not work, because the url is never changing.
my question is: what is the best solution to restict page access without filters (is there a easy to use security (without complex roles etc.-> some users just have isAdmin=true)? or is there no problem at all when i use redirection? why does jsf then doesn't use it per default?
Is using a prerenderview component an acceptible solution? (if the user dosn't have enough rights, he should be navigated to a 404 page)
You're making a fundamental mistake. You should not be using command (POST) buttons/links for page-to-page navigation in first place, but you should be using direct (GET) buttons/links for that.
Long story short:
What is the difference between redirect and navigation/forward and when to use what?
How to navigate in JSF? How to make URL reflect current page (and not previous one)
When should I use h:outputLink instead of h:commandLink?
Considering this information and best practices, a servlet filter is still the best solution. All existing security frameworks are also based on the filter principle.
See also:
How to handle authentication/authorization with users in a database?
I'm trying to figure out if it is possible to use ServiceStack Razor for old-fashioned server-side form validation.
By way of example: a GET to a url returns a razor template with a form. When the user POSTs the form, request DTO is validated and if there were errors, the user is shown the same form, with original values re-populated as and fields in error marked somehow. If, on the other hand the request DTO is valid, the service will redirect the user to another page.
Is that scenario possible?
If so, how would one go about implementing it? I presume I'll have to write certain filters or features for this to work, however I'm wondering what strategy will require minimum amount of coding.
(I understand javascript validation is possible, however my question is specifically whether it is possible to round-trip the form with server-side validation).
Take a look at ss-validation.js, it can be used to apply validation errors to your form based on ServiceStack's ResponseStatus.
So we write all our validation code server side using FluentValidation, then on round trip ss-validation reads ResponseStatus and applies markup.
Out of the box is assumes Bootstrap style validation, but it's fairly easy to modify to suit your needs, e.g. we amended to display inline icon tool tips instead of inline/block messages, and provide an error summary.
After a lot of spelunking of the ServiceStack codebase, it seems it is theoretically possible to achieve the desired scenario.
The code already contains ModelMetadata and ModelMetadataProviders classes, and some of the HTML helpers are ported from System.Web.Mvc.
Sadly, the classes are not fully wired, so I guess it will require solid amount of work to get everything working correctly as one would expect.
I don't often have need for tomahawk components anymore since jsf 2.0 provides great selectOneMenu support and most of other functionality I used to use them for, but when it comes to a selectOneRadio component I don't know of another provider with a layout="spread" option. This is essential from time to time to achieve a certain layout I'm asked for.
I'm using Tomahawk for exactly this purpose but recently discovered some serialization issues caused by this component during failover. I was wondering if anyone has discovered another provider with similar "spread" functionality or if anyone has written/published an alternative based on h:selectOneRadio?
We also wanted to use the "spread" option - in our case for DDA compatibility (no using tables for layout) but for political reasons were unable to use Tomahawk. We ended up writing our own custom renderer for radio buttons and checkboxes.
It wasn't too hard, took me a few hours to get it working the way we wanted. I'm at home for a couple of days without access to the code base so I can't give you the exact code but it's a pretty simple matter of overriding the encodeBegin() and decodeBegin() (or encodeEnd() and decodeEnd() depending on your usecase) methods and writing the html appropriate for your application.
Background
I'm going to develop a new web-application with java. It's not very big or very complex and I have enough time until it'll "officially" start.
I have some JSF/Facelets development background (about half a year). And I also have some expirience with JSP+JSTL.
In self-educational purpose (and also in order to find the best solution) I want to prototype the new project with one of action-based frameworks. Actually, I will choose between Spring MVC and Stripes.
Problem
In order to get correct impression about action-based frameworks (in comparison with JSF) I want to be sure that I use them correctly (in a bigger or a lesser extent).
So, here I list some most-frequent tasks (at least for me) and describe how I solve them with JSF. I want to know how they should be solved with action-based framework (or separately with Spring MVC and Stripes if there is any difference for concrete task).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
Thanks in advance for explaning how these items (or some of them) can be done with action-based framework.
I'll do my best to answer regarding Stripes. I've used Struts and JSF in the past, but not recently, so at best I have vague notions and feelings about them.
We are intimately familiar w/ Stripes, use it for most everything now, and really enjoy it. It is easy to jump into, supports many of the complicated scenarios, but you are also free to work OUTSIDE of it, which is really important when you want to build your own ajax widgets or talk to another system or something.
If you go the stripes route, I definitely recommend buying or download the book. It is a one stop shop for everything you need for Stripes, and is practically the only documentation for Stripersist (really nice feature, but NO web docs).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
This is similar. Core, Html, Fmt, etc. as well as any custom tags you find, inc. display:tag, pack tag, and create your own. However, obviously you do not deal at the component level now, you deal with a tag that determines what is on the page / sent to or from the server.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Stripes has many built in converters, and it is easy to create custom converters for your more complex data types. Stripes supports very complex data structures to be mapped with little hassle. Combined with Stripersist, for example, I can put my model object directly on the ActionBean, put a few of the fields on the form, and Stripersist will hydrate the model from the db (based on its PK) and update that with the fields I put on the form - all before releasing control to me on the ActionBean.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Navigation in stripes is based on what you name the ActionBeans, initially. There is no xml. Additionally, pretty urls are an annotation at the ActionBean level in Stripes 1.5, so you can do things like #UrlBinding("/{$event}/{model}") where /view/5 would take you to the "view" event handler for your Model object with the ID/PK of 5.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
While I only am vaguely familiar with the concept of conversation scope, Stripes has Wizard Form functionality, but I haven't used it and am unable to really expand on that. I think it is a similar idea though.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Not drastically different. Instead of components on your [action] bean, you now have Java or custom types. ActionBeans are created per request and thrown away, unless you do something like put it in session, or wizard, or whatever. This is nice, because all the instance variables get mapped to the data from the form, you use it, then throw it away, and don't have to deal with any synchronization issues like struts did. After you do your thing with the data, Stripes lets you send a ForwardResolution (OK status), Redirect, or Streaming (JSON, file, etc). The Redirect-after-POST pattern is implemented nicely with the idea of flash scope (3/4 down the page).
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Stripes allows validation in annotations on the instance variables on the ActionBean. They allow some defaults, required, maxlength, etc. or you can always create your own. The default is easy to add and flexible, while there is always the ability to make something completely customized.
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
This was my big problem with the JSF way of doing things. Even if you did get the widget right, you're still stuck with THAT widget. With Stripes, you can use whatever latest and greatest Jquery has to offer, and as long as you send the right GET or POST to the server, stripes knows what to do with it and can easily send JSON back. I think component frameworks fit a niche a few years ago much better when AJAX was hard, but JQ makes it so easy now.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
#UrlBinding, it's as easy as that.
My answer is not the one you want to hear: Don't switch from Component Framework to action framework
I switched the other way around after many years of action framework development and I'm never going back.
Of the 8 use cases you mentioned, only one comes to mind where Action frameworks are obviously better, and that is URL design / friendly URLs. It can be done in component frameworks as well, but much easier in Action Frameworks (especially in Stripes where you just annotate your ActionBean with the url).
I would advise you to try wicket, it is very easy to learn (much easier than JSF) and it let's you re-use many existing components as well.