Hi, We just use one application/page for all roles, otherwise, you'd have a hard time maintaining everything especially if you have dynamic roles. Wicket has an interface you can implement for authorization (IAuthorizationStrategy); there are also existing projects that implement it for you as well and cover the general use case such as wicket-auth-roles and wicket-security. However, we just implemented our own IAuthorizationStrategy since we have an existing role-based system from older applications so I haven't had much experience with the existing projects. The basics of implementing your own are covered pretty well in the Wicket in Action book as well, but if the existing projects cover your needs then you should be able to use them pretty easily.
On Fri, Feb 26, 2010 at 6:35 PM, Jing Ge (Besitec IT DEHAM) <[email protected] > wrote: > Hello guys, > > > > We have been using wicket since more than one year. It is very > comfortable to work with wicket and "live" here in this community. > Thanks you guys! > > > > Now we want to add more features into our application and we get a > (actually very common) problem: > > > > What is the correct way for building a role-based wicket application? > > > > The requirement is something like this: > > > > 1. Users are assigned to different roles, or groups, or projects. > > 2. Some pages looks similar to the users of different roles. But they > are not same. > > > > We have thought about it for a while and get some ideas: > > > > 1. One application for all roles and one page for all roles. (with > "if.. else" maybe, we know it is not good). Is it possible with wicket? > Since the wicket:id, that is defined in the html , must be added in the > java class. Maybe show/hide it for different roles? > > 2. One application for all roles but one page for each role. The > drawback is the duplicated code & logic. This could be solved by class > inheritance. But the html files are still duplicated. > > 3. One application for each role. Build a base project and then > let other projects inheritance from the base one. > > > > We know that the third choice is not good (actually very bad from the > technical point of view, has a lot of problems for changes, release, > deployment, etc.), but it has also one real great benefit: role relevant > changes will be limited only to the users of that role. That means, for > such changes, only the application for that role needed to be updated, > redeployed, and restarted. > > > > Is there any features of wicket can solve such problem? Does anyone of > you guys has some better ideas? We appreciate any suggestions, guides, > helps, etc. Thanks! > > > > Best regards > > Jing > >
