So LiftConfig would take the role of LiftRules from API perspective
meaning that LiftRules could be completely hidden from Lift users but
available internally to Lift only ?
Still from maintainability perspective initializing LifRules with a
LiftConfig may imply lots of assignments (unless LiftRules will
reference a LiftConfig in which case LiftRules code needs to change to
use LiftConfig) or when we'd want to expose some new stuff we'd have
to add it in two different places LiftConfig toexpose it to users and
LiftRules so that Lift code to use that.
Otherwise not a bad idea ...
Br's,
Marius
On Dec 14, 5:21 pm, "Viktor Klang" <viktor.kl...@gmail.com> wrote:
> On Sun, Dec 14, 2008 at 4:01 PM, David Pollak <feeder.of.the.be...@gmail.com
>
>
>
> > wrote:
>
> > 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"?
>
> class Boot
> {
> def boot(val lc: LiftConfig) =
> {
> add all configuration to LiftConfig
> }
>
> }
>
> and then in the code that lookups, creates and calls Boot.boot (haven't got
> access to the repository on this machine)
>
> just add/modify the code in the bootstrap loader:
>
> {
> val boot = ...//Lookup and create Boot instance
> val lc = LiftConfig() //(1)
> boot.boot(lc) //(2)
> LiftRules.init(lc) //(3)
>
> }
>
> (1) : Must create LiftConfig (this object is the placeholder of the
> configuration=
> (2) : Pass it into the boot-call
> (3) : Initialize LiftRules with the configuration prepared by the boot-call
>
> result:
>
> No need to expose mutability in LiftRules (since we discovered that changing
> stuff while the webserver was up and running had few applications at best)
>
> More clear now?
>
> Remeber that this is only a friendly suggestion to an issue brought up by
> someone else in this thread.
> If such suggestions are superflous, please just tell me so and I'll keep my
> trap shut.
>
> Cheers,
> Viktor
>
>
>
>
>
> >> 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 frameworkhttp://liftweb.net
> >>> Collaborative Task Managementhttp://much4.us
> >>> Follow me:http://twitter.com/dpp
> >>> Git some:http://github.com/dpp
>
> >> --
> >> Viktor Klang
> >> Senior Systems Analyst
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Collaborative Task Managementhttp://much4.us
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
