This is exactly right ross - I get its purpose (but I dont necessarily like the API), I just don't get the inconstancy in usage. It would certainly help a great deal if there were examples littered by its usages.
Cheers, Tim On 5 Feb 2010, at 18:44, Ross Mellgren wrote: > In my experience, I found that the functionality of the FactoryMakers was > very flexible (and I could see the utility of that), but that the > documentation was just plain missing. Maybe more/better documentation on > FactoryMaker itself, and some simple common examples on the places where > FactoryMaker is used, e.g. stripComments might say: > > * To strip comments from all resources served by lift: > * LiftRules.stripComments.default.set(() => false) > * To strip only for a certain request: > * ... > > -Ross > > On Feb 5, 2010, at 1:41 PM, David Pollak wrote: > >> >> >> On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett <[email protected]> >> wrote: >> Guys, >> >> I just wanted to have a grumpy moan about FactoryMaker. Now, this must >> easily be the most complicated / confusing piece of scala code in >> Lift. >> >> Its totally non-trivial implementation and its levels of miss- >> direction (and total lack of examples) make it an utter nightmare to >> figure out what one needs to do to use it for pre-assigned vals in >> LiftRules. >> >> This brings me neatly onto my next point: LiftRules and its occasional >> use of FactoryMaker, partial functions and mutable vars. I appreciate >> that this is partially a legacy thing as many different people within >> the team add stuff to LiftRules, however I thought FactoryMaker was >> brought in to facilitate object mocking / testing right? Shouldn't it >> be the first-order choice for configuration? weather or not that is >> the case, why oh why are there no explanations in the comments for >> LiftRules where factory maker is used as to how to alter those >> configuration options? >> >> Okay... once the assembla ticket system is up, open a ticket on this and >> assign it to me. >> >> >> For example: >> >> LiftRules.stripComments.default.set(() => false) >> >> >> FactoryMakers allows you to do a number of things: >> define functions that calculate a value for a given thing (like should >> comments be stripped) >> support aggregation into a Factory which can be used for Java-style >> dependency injection (you ask the Factory for a thing of type T and it gives >> it to you) >> supports session, request, and current-thread over-riding of the calculation >> function >> So, why functions vs. values? Because functions are more flexible than >> values... they allow the calculation of values given the current context. >> >> Why not use call-by-name rather than explicit functions? I've found that >> making things explicit functions remove ambiguity. Additionally, there's an >> implicit that's supposed to promote a constant (T) to a function... but it >> doesn't always get invoked. >> >> If it's a function, why have session, request, and thread-based functions? >> Because you have to know at Boot time what you want the function to look >> like in all cases. Kris had some reasonable examples of over-riding the >> functions on a test-by-test basis (thread-based). Additionally, it strikes >> me that you might want to have a snippet that triggers a change in >> particular behavior (request-based) and rather than having to code that >> behavior into the function defined in Boot, you change it at the request >> level (we've got some examples of stuff that does that already, but making >> the common pattern into something that's built into the Factor/FactoryMaker >> makes sense). >> >> Are the names and call patterns optimal? No. But given that >> Factory/FactoryMaker is little used outside of LiftRules, I'd be up for >> breaking changes (as long as they turned into compile-time errors) to make >> things better. Tim -- you want to volunteer? >> >> This is totally non-obvious - if we are going to use stuff like this, >> it really out to be in the comments. Stuff like this can seriously >> affect Lift's ease of use, and considering the current lack of >> documentation we need to be careful about what we are doing here. >> >> Sorry for the grump, i just felt this was warranted. >> >> Cheers, Tim >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> >> >> >> -- >> Lift, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Surf the harmonics >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
