On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang <viktor.kl...@gmail.com>wrote:
> David,
>
> sounds reasonable.
>
> So being able to call prepend/append after boot() makes no sense.
>
> In the light of htis, it shouldn't be possible to call the prepend/append
> outside of boot.
> I suggest my approach described previously. (Injecting an initialization
> context into boot and use that to configure LiftRules, then we don't expose
> the mutativity in LiftRules.
> Result: No runtime exceptions, no confusion on when to configure the webapp
> etc.
I have no idea what this means or how to translate it into code. Can you
give me an example of code that "injects an initialization context into
boot"?
>
>
> Input?
>
> Cheers,
> Viktor
>
> On Sun, Dec 14, 2008 at 3:41 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Folks,
>>
>> I have not had a single instance of wanting to change global application
>> behavior at runtime. I cannot think of use case for such a feature.
>>
>> On the other hand, the idea that your program behavior is stable from the
>> first HTTP request on makes a lot of sense to me. It means tests work
>> because the tests don't have to worry about the behavior of the program
>> changing. The same n steps will lead to the same result.
>>
>> If anyone can come up with a use case for globally changing program
>> behavior during program execution, I'm all ears, but barring that, once the
>> boot phase is over, the stuff in LiftRules should be frozen.
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> On Sun, Dec 14, 2008 at 3:54 AM, 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.
>>>
>>>
>>>
>>> >
>>> > 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
>>>
>>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Collaborative Task Management http://much4.us
>> Follow me: http://twitter.com/dpp
>> Git some: http://github.com/dpp
>>
>>
>>
>>
>
>
> --
> Viktor Klang
> Senior Systems Analyst
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
