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