request parameter vs @DataModelSelection

[holgerprause]

Hello,

I got a very basic question.
i am currently implementing a site where members with different roles
can register and perform actions (submit task, etc).

I currently implementing the action "view member details"

Doing this with request parameter "?member_id" an a correponding bean where this will be injected via "@RequestParameter" is very easy.

But, if u manipulate the get parameter, u can see the memberdetails of every member, i dont think thats a nice feature

Ok if use
@DataModel
@DataModelSelection

u can get around this, but the both declarations have to b in the same bean
which breaks my application desing
(i want 1 bean for the list action and 1 for the detail action, not 2 for both)

For search i can live with that limitation but not for the action "view task details" the code is really getting messed up.

Is there a 3rd way to get the member_id injected without using request parameter ?


Thank u very much,

Holger

[holgerprause]

Hello,

i am using this now as "woraround"

<h:commandLink action="#{viewMemberDetails.viewMemberDetails}">
 <f:verbatim>view member details</f:verbatim>
 <f:param name="member_id" value="#{tmp.member_id}" />
</h:commandLink>

u see no parameter in the link and the get parameter will be submitted via javascript(as far as i understood this)

Do u think this is an acceptable solution for my problem, me a bit unsure, but passing get parameter this way is much more easier for me.

Thank u again,

Bye,

Holger

[cptnkirk]

Why not use Java EE security along with Seam's support for userPrincipal and isUserInRole instead?

[holgerprause]

Hello, yes that maybe would solve some(maybe all) of my problems, ill take a look at it.

But the same thing will occur when the user can view
task details submitted by an user,(only taks submitted or received by an user can be viewed)

I think its a very basic problem that u will have over and over again.
Maybe i can solve this all with this "Java EE security"

Maybe i missing sth but thank u very much,

Holger