On Sun, Dec 14, 2008 at 12:54 PM, Marius <marius.dan...@gmail.com> wrote:
> > > > On Dec 14, 12:53 pm, "Viktor Klang" <viktor.kl...@gmail.com> wrote: > > On Sun, Dec 14, 2008 at 11:42 AM, Marius <marius.dan...@gmail.com> > wrote: > > > > > On Dec 14, 12:10 pm, "Viktor Klang" <viktor.kl...@gmail.com> wrote: > > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius <marius.dan...@gmail.com> > wrote: > > > > > > > On Dec 14, 3:02 am, "Jorge Ortiz" <jorge.or...@gmail.com> wrote: > > > > > > Not to beat a dead horse, but... what's the rationale, again, for > > > > > throwing > > > > > > an exception after boot? Is there a real danger to some or all > > > RulesSeqs > > > > > > being mutable after boot? If some, then those rules should > > > selectively be > > > > > > protected. Even if they're all dangerous, there are better (i.e., > > > type > > > > > safe) > > > > > > ways of protecting RulesSeqs from mutation than just throwing an > > > > > exception. > > > > > > > This was actually DPP's suggestion. I'm not sure why would someone > > > > > mutate them after boot but I'm totally opened if there is a strong > > > > > case for allowing that. I do not have strong feelings about this so > > > > > changing it would be trivial. Still I kind of like it this way. > What > > > > > other ways of protecting mutations after boot are you referring? > ... > > > > > something like ignore it and do nothing? > > > > > > Hmm, how about "locking" them by havign a paralell lazy val? > > > > > > val somePf : RuleSeq = Nil; > > > > > > lazy val runtimeSomePf = somePf.toList > > > > > > Then prepending/appending on the somePf AFTER runtimeSomePf has been > > > > dereferenced won't make a difference. > > > > (runtimeSomePf would be used by Lift internally if that isn't clear > > > enough > > > > :) ) > > > > > Still we'd allow useless strong references on those lists. > > > > > > Or another, perhaps more suitable suggestion: > > > > > > make boot() have an InitializationContext parameter that's only > available > > > in > > > > the scope of boot, and then the problem should disappear? > > > > > How would the problem disappear? ... I mean after boot people would > > > still be able to add their functions (from API perspective) and they > > > would be surprised that their functions are not called and yet lift > > > just allowed them to do that. > > > > I meant something like: > > > > def boot(val lc : LiftContext) = > > { > > //prepend/append,configure everything on lc > > > > } > > > > And then when the LiftFilter runt boot: > > > > { > > val lc = LiftContext(/*servletContext and stuff goes here*/) > > boot(lc) > > LiftRules.init(lc) > > > > } > > > > And then only have non-append/prependable stuff in LiftRules? > > > > But really, what is it a problem that lift is reconfigurable during > runtime? > > I thought that was kind of cool? > > As I said I don't have strong opinions on this. It was DPP's > suggestion and personally I kind of like it which does not mean that > things can not change :) ... AFAIC reconfiguration at runtime does not > make a whole lot of sense because: > > 1. We'd have to expose other functions to allow people to also remove > their function not only prepend & append them > 2. I do not see what kinds of problems runtime reconfiguration really > solve (I'm only referring on the current RulesSeq members). I haven't > encounter a practical need but if you have please let me know. > 3. Dynamic behavior can happen inside user's functions without > allowing runtime reconfiguration. > > Just my 2 cents ... > > P.S. > If the general consensus is to remove this restriction I have no > problem removing it ... so more thoughts/perspectives on this are > welcomed. I have no opinion, I'm just offering solutions :) > > > > > > > > Cheers, > > Viktor > > > > > > > > > > > > > > Cheers, > > > > Viktor > > > > > > > > Nit-pick: why is 'toList' (which just returns 'rules') defined as > > > > > > private[http] when 'rules' itself is public? > > > > > > > Why would you use toList in the lift app code? ...RulesSeq is > mainly > > > > > about adding user functions to lift. If "rules" itself is public > > > > > doesn't necessary mean that it should not have its "private" logic. > > > > > > > > Also, if RulesSeq are always made up of either Functions or > > > > > > PartialFunctions, maybe we should enforce that at a type level, > and > > > the > > > > > > helper methods on Seqs of PFs that now exist in the NamedPF > object > > > can be > > > > > > put in the RulesSeq object. > > > > > > > But what would be the benefit? .. except that it would simplify a > bit > > > > > how Lift calls these PF's? > > > > > > > ... to me distinguishing between functions and partial functions > here > > > > > by using Either or even using different RulesSeq traits would not > > > > > bring much benefits ... but I hope I'm wrong. > > > > > > > > --j > > > > > > > > On Sat, Dec 13, 2008 at 2:31 PM, Marius <marius.dan...@gmail.com > > > > > wrote: > > > > > > > > > All, > > > > > > > > > I committed a bunch of changes in LiftRules. In a previous > thread > > > > > > > Jorge suggested the abstraction of LiftRules variables. Lists > of > > > > > > > functions are now abstracted by RulesSeq trait, which contains > > > prepend > > > > > > > and append functions. Note that if you're calling > prepend/append > > > > > > > functions after boot they will throw an exception. If there are > > > > > > > compelling reasons not to do this please let us know. This is > just > > > a > > > > > > > mechanism to enforce the use of these functions on startup. > > > > > > > > > Br's, > > > > > > > Marius > > > > > > -- > > > > Viktor Klang > > > > Senior Systems Analyst > > > > -- > > Viktor Klang > > Senior Systems Analyst > > > -- Viktor Klang Senior Systems Analyst --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---