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.
