Yes, a Loc accepts many LocParams ... as I said above If/Unless/Test would be used in conjunction with CondHidden to also provide accessibility constraints.
Here is the definition case object CondHidden(test: () => Boolean) extends LocParam but we also have case class If(test: () => Boolean, failMsg: FailMsg) extends LocParam So the test function is the same which means that you essentially implement one function and provide it to both LocParam's. We could probably combine the two LocParams in a: IfHidden(test: () => Boolean, failMsg: FailMsg) // if you have a better name please let me know :) The test function would be called in two cases: 1. When rendering the Menu to see is the Menu should be rendered or not 2. When try to access the location to as a security check I could probably add it this week and point you to my branch to check it out. If I runt into something weird that I cannot foresee I'll let you know. Would this work for you? Other people are welcome to comment as well ... Br's, Marius On Oct 11, 7:06 pm, Dave <davidtgoldb...@gmail.com> wrote: > Hi Marius, > > Thanks for the response. The LocParam is a good idea, but here is the > attendant problem. No only do I have to hide options A,B,C from user > type 2, I have to make sure user type 2 does not access those pages/ > areas. Can I include that in the locParam as well? Right now, I'm > using an If() val to determine what type of user it is, and then > funnel accordingly. I assume i can just include both the if (to > determine access/where to send) and then the conditional hider > LocParam if necessary. But can I bundle both into a more DRY solution? > > Thanks, > > Dave > > On Oct 11, 2:54 am, "marius d." <marius.dan...@gmail.com> wrote: > > > So doesn't what I described about help you? ... a conditional Hidden > > LocParam? ...thus the SiteMap contains all A, B, C, D, E, F menus but > > for user type 1 D, E,, F are hidden, and for user type 2 A, B, C are > > hidden. The decision would done in the function that you provide to > > CondHidden. > > > If this helps the new LocParam could be added with not much problems. > > > If this doesn't work for you, please elaborate. > > > Br's, > > Marius > > > On Oct 11, 2:09 am, Dave <davidtgoldb...@gmail.com> wrote: > > > > Hi all- > > > > I am interested in a similar question. I have two types of users and > > > once logged in, I'd like to provide them with distinct menu options. > > > For instance User type one would have a menu with A / B / C and User > > > Type Two would have D / E / F. I have tried a variety of approaches > > > including storing a session variable when the user first logs in, but > > > because the sitemap is already built, its tough to modify > > > dynamically. Further, unfortunately, User1.sitemap and User2.sitemap > > > don't play well together, and only one should be shown at one time > > > depending on the user type. Not to take away from Markus' question, > > > but if someone could address this more concrete scenario, it would be > > > much appreciated. > > > > Thanks, > > > Dave > > > > On Oct 10, 5:09 pm, "marius d." <marius.dan...@gmail.com> wrote: > > > > > Well SiteMap is per LiftRules which means it's per application > > > > runtime. One approach would be to define the entire SiteMap but > > > > depending on the context using some conditional Hidden LocParam. > > > > Perhaps something like: > > > > > case object CondHidden(coond: () => Boolean) extends LocParam > > > > > This could be used in conjunction with If/Unless/Test LocParam-s to > > > > also grant access per context (even if the Loc is Hidden) > > > > > This probably won't suffice if you want each user to have its own > > > > unique SiteMap. Can you elaborate more on your application > > > > usecase? ... in what way you want unique SiteMap per user? > > > > > Other option would be to have in LiftRules something like: > > > > > val sessionSiteMap: (LiftSession) => SiteMap > > > > > This means that you can provide a function that will create a SiteMap > > > > depending on the LiftSession ... which would probably be called after > > > > LiftSession is created. I'm not sure if this is the way to do it as > > > > this would act as a secondary SiteMap ... and this would complicate > > > > things a bit for the Lift engine. > > > > > Br's, > > > > Mariu > > > > > On Oct 9, 11:36 pm, Markus Kolb <liftweb...@tower-net.de> wrote: > > > > > > Hi, > > > > > > I'm something new to Scala and Lift is freshmeat for me. > > > > > At the moment I am trying to find a best practice possibility to > > > > > setSiteMap with a SiteMap which includes Menus and Locs which might > > > > > change during application runtime. > > > > > Let me say... each user should get his own, unique SiteMap after > > > > > login. > > > > > The SiteMap should be generated based on class construction and method > > > > > calls during runtime. > > > > > I've the problem to find a solution without putting setSiteMap-call > > > > > nearly everywhere in my code just to update it. > > > > > > Uumh. Yes. Any tips are welcome... > > > > > > Best regards, > > > > > Markus --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
