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 -~----------~----~----~----~------~----~------~--~---
