On Sun, Dec 14, 2008 at 10:46 PM, Marius <marius.dan...@gmail.com> wrote:
>
> 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 ?
Since LiftRules would then only expose immutable data, I'd see no problem
exposing it if there is value in exposing it.
But keeping it private is a very viable strategy.
>
>
> 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.
Yes, there'd be quite a few assignments, but with a nifty unit test you
could secure that everything is used properly.
Cheers,
Viktor
>
>
> 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
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
