[Lift] Re: Dynamic SiteMap
On Wed, Oct 14, 2009 at 5:07 PM, Markus Kolb wrote: > > On Oct 14, 10:36 pm, David Pollak > wrote: > > > Are you talking about dynamic pages as part of a content management > system > > or are you talking about .html files appearing in the filesystem? > > It is comparable with a CMS. > The information for building the SiteMap is available via API of > another library doing network transmissions to a backend service. > The menu has functionality like a folder structure but views are total > different. > What do you think? > It's totally possible. I'll work up an example for you. Hint: the additionalKidParams method will return a list of params that can be used to denote dynamically generated kids from a given menu. > I want to use SiteMap because there are already conditions and request > handling. > It is well integrated in the framework to do the views. > But I have some problems to map the external data in the SiteMap. > At the moment it works ok, but it feels too much like a hack. > Do you know any pattern which would play well with SiteMap and > external data? > > Best regards > Markus > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
On Oct 14, 10:36 pm, David Pollak wrote: > Are you talking about dynamic pages as part of a content management system > or are you talking about .html files appearing in the filesystem? It is comparable with a CMS. The information for building the SiteMap is available via API of another library doing network transmissions to a backend service. The menu has functionality like a folder structure but views are total different. What do you think? I want to use SiteMap because there are already conditions and request handling. It is well integrated in the framework to do the views. But I have some problems to map the external data in the SiteMap. At the moment it works ok, but it feels too much like a hack. Do you know any pattern which would play well with SiteMap and external data? 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
On Wed, Oct 14, 2009 at 11:08 AM, mkolb wrote: > > On Oct 12, 7:29 pm, David Pollak > wrote: > > To address the specific issue of CondHidden/IfHidden, if a Loc (menu > > location) fails the If() or Unless() test, it will not be > > displayed/rendered/visible to the user. So, there's no need for a > IfHidden > > or a CondHidden LocParam. > > > > More broadly, SiteMap represents all the pages in your site and the > > visibility/access rules for each of those pages. > > [...] > > Does this resolve the questions/issues raised in this thread? > > > Hi, > > that's been interesting but it doesn't refer to my initially > question. > At least what has been my intention. ;-) > I don't have any questions to SiteMap conditions or access. > > To become more specific on my problem... > Right now I've put the logic to create and set a new SiteMap in a > static (object) method and I call the method after all code places > where some change to the SiteMap should be recognized. > But that handles only the changes to the SiteMap the liftweb > application is responsible for. > Are you talking about dynamic pages as part of a content management system or are you talking about .html files appearing in the filesystem? > In my place the data which is used to create the SiteMap may change > outside the responsibility of liftweb. > So I would need some kind of SiteMap listener to keep the SiteMap up- > to-date. > Is there already some kind of listener implemented which can be used > for this? > I don't want to reinvent if there is already some "magic" to get it. > > Thanks > Markus > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
On Oct 12, 7:29 pm, David Pollak wrote: > To address the specific issue of CondHidden/IfHidden, if a Loc (menu > location) fails the If() or Unless() test, it will not be > displayed/rendered/visible to the user. So, there's no need for a IfHidden > or a CondHidden LocParam. > > More broadly, SiteMap represents all the pages in your site and the > visibility/access rules for each of those pages. [...] > Does this resolve the questions/issues raised in this thread? Hi, that's been interesting but it doesn't refer to my initially question. At least what has been my intention. ;-) I don't have any questions to SiteMap conditions or access. To become more specific on my problem... Right now I've put the logic to create and set a new SiteMap in a static (object) method and I call the method after all code places where some change to the SiteMap should be recognized. But that handles only the changes to the SiteMap the liftweb application is responsible for. In my place the data which is used to create the SiteMap may change outside the responsibility of liftweb. So I would need some kind of SiteMap listener to keep the SiteMap up- to-date. Is there already some kind of listener implemented which can be used for this? I don't want to reinvent if there is already some "magic" to get it. Thanks 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
To address the specific issue of CondHidden/IfHidden, if a Loc (menu location) fails the If() or Unless() test, it will not be displayed/rendered/visible to the user. So, there's no need for a IfHidden or a CondHidden LocParam. More broadly, SiteMap represents all the pages in your site and the visibility/access rules for each of those pages. All the pages for which you have templates should also have a SiteMap entry (a Loc). The Loc will contain a set (0 or more) of If/Unless rules governing access. If there are no If/Unless rules, then the page will be accessible no matter the state of the application. If you want pages that are accessible in a particular application state (Anyone logged in, Teacher logged in, Student logged in, Teach with root privileges logged in, etc.), you define a method that calculates a Boolean based on the current application state: (assuming that User.currentUser returns a Box[User] and the User class has isTeacher, isStudent, isRootTeacher methods) def anyoneLoggedIn = User.currentUser.isDefined def teacherLoggedIn = User.currentUser.map(_.isTeacher) openOr false def studentLoggedIn = User.currentUser.map(_.isStudent) openOr false def rootTeacherLoggedIn = User.currentUser.map(_.isRootTeacher) openOr false def studentOrRootTeacher = studentLoggedIn || rootTeacherLoggedIn Now, you can define some conditionals: lazy val ifLoggedIn = If(anyoneLoggedIn _, S ?? "You must be logged in to view this page") lazy val ifTeacher = If(teacherLoggedIn _, S ?? "You must be a teacher to view this page") lazy val ifStudentOrRootTeacher = if(studentOrRootTeacher _, S ?? "You must be a student to view this page") And you can create locations (Loc) in your SiteMap that contain the ifLoggedIn, etc. LocParams. What you see is that how you calculate a given permission is not important to the If/Unless LocParam. It's all about the current app state and nothing more. Pages guarded by If/Unless will not load if the required conditions are not met nor will they be displayed in the menu hierarchy. Does this resolve the questions/issues raised in this thread? Thanks, David On Mon, Oct 12, 2009 at 12:05 AM, marius d. wrote: > > First of all I'm not reinventing anything. I don't think that If > LocParam semantic is giving you the hidden functionality as well. User > type 2 should not even see the menus for user type 1, not only to not > be able to access those locations. > > The way I see it this functionality should be totally irrespective of > Mappers or any persistence store. It is just a matter of how you > implement the function passed to If and other LocParams. > > You can also implement your own Loc and override the calcHidden > function and you can decide what to render there. I still think that a > conditional hidden LocParam would be helpful. > > Br's, > Marius. > > On Oct 12, 2:27 am, Dave wrote: > > Marius- > > > > Thanks for your help on this. I guess I'm not sure how this differs > > from the current conception of the If LocParam. As I understand it, it > > is checked when determining what to display on the Menu as well as > > when a User attempts to access the page (or its subdirectory if > > passing a pair). If this is true, then I think there is no need to > > reinvent the wheel per se. Assuming I'm right and we can use If's to > > accomplish this functionality, I can follow up this query with an > > implementation based question. Specifically, since both of my user > > types extend MegaProtoUser, I end up with loggedIn_? function that > > tells if some user is logged in, but is confused about which. So if a > > user of type 1 logs in and I call UserType2.loggedIn_?, it will also > > return true. Is there a way to check for this in If statements? Or > > is it necessary to override loggedIn_? (which I've been trying, but > > has been pretty slow going so far). > > > > Thanks > > Dave > > > > On Oct 11, 12:36 pm, "marius d." wrote: > > > > > 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
[Lift] Re: Dynamic SiteMap
Dave writes: [...] > Specifically, since both of my user types extend MegaProtoUser, I end > up with loggedIn_? function that tells if some user is logged in, but > is confused about which. So if a user of type 1 logs in and I call > UserType2.loggedIn_?, it will also return true. Is there a way to > check for this in If statements? Or is it necessary to override > loggedIn_? (which I've been trying, but has been pretty slow going so > far). Is there a reason you need two user _types_? It sounds like this could be accomplished by adding a role to the user. Then you could easily do If(User.loggedIn_? && User.role1_?) /Jeppe --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
"marius d." writes: > First of all I'm not reinventing anything. I don't think that If > LocParam semantic is giving you the hidden functionality as well. I haven't checked closely, but the scaladoc seem to indicate that it does. And in my own menu snippets (which is based on the original menu snippet), inaccessible items doesn't show either /** * If the test returns True, the page can be accessed, otherwise, * the result of FailMsg will be sent as a response to the browser. * If the Loc cannot be accessed, it will not be displayed in menus. * * @param test -- the function that tests access to the page * @param failMsg -- what to return the the browser (e.g., 304, etc.) if * the page is accessed. */ case class If(test: () => Boolean, failMsg: FailMsg) extends LocParam /Jeppe --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
First of all I'm not reinventing anything. I don't think that If LocParam semantic is giving you the hidden functionality as well. User type 2 should not even see the menus for user type 1, not only to not be able to access those locations. The way I see it this functionality should be totally irrespective of Mappers or any persistence store. It is just a matter of how you implement the function passed to If and other LocParams. You can also implement your own Loc and override the calcHidden function and you can decide what to render there. I still think that a conditional hidden LocParam would be helpful. Br's, Marius. On Oct 12, 2:27 am, Dave wrote: > Marius- > > Thanks for your help on this. I guess I'm not sure how this differs > from the current conception of the If LocParam. As I understand it, it > is checked when determining what to display on the Menu as well as > when a User attempts to access the page (or its subdirectory if > passing a pair). If this is true, then I think there is no need to > reinvent the wheel per se. Assuming I'm right and we can use If's to > accomplish this functionality, I can follow up this query with an > implementation based question. Specifically, since both of my user > types extend MegaProtoUser, I end up with loggedIn_? function that > tells if some user is logged in, but is confused about which. So if a > user of type 1 logs in and I call UserType2.loggedIn_?, it will also > return true. Is there a way to check for this in If statements? Or > is it necessary to override loggedIn_? (which I've been trying, but > has been pretty slow going so far). > > Thanks > Dave > > On Oct 11, 12:36 pm, "marius d." wrote: > > > 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 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." 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 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.
[Lift] Re: Dynamic SiteMap
Marius- Thanks for your help on this. I guess I'm not sure how this differs from the current conception of the If LocParam. As I understand it, it is checked when determining what to display on the Menu as well as when a User attempts to access the page (or its subdirectory if passing a pair). If this is true, then I think there is no need to reinvent the wheel per se. Assuming I'm right and we can use If's to accomplish this functionality, I can follow up this query with an implementation based question. Specifically, since both of my user types extend MegaProtoUser, I end up with loggedIn_? function that tells if some user is logged in, but is confused about which. So if a user of type 1 logs in and I call UserType2.loggedIn_?, it will also return true. Is there a way to check for this in If statements? Or is it necessary to override loggedIn_? (which I've been trying, but has been pretty slow going so far). Thanks Dave On Oct 11, 12:36 pm, "marius d." wrote: > 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 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." 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 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." 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) =
[Lift] Re: Dynamic SiteMap
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 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." 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 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." 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 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, > > > > > M
[Lift] Re: Dynamic SiteMap
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." 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 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." 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
Oh I should have read more carefully. Sorry Marius. Do you think you could provide an example with dummy's as to how one of these CondHidden and If's might work in conjunction? Thanks, Dave On Oct 11, 2:54 am, "marius d." 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 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." 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
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 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." 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
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." 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Dynamic SiteMap
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 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 -~--~~~~--~~--~--~---
