OK so most of your problems are around Mapper which is just a portion of Lift. Please see my notes inline but other people more Mapper knowlegeable then myself will likely reply. Hopefully their feedback will be materialize on Lift Wiki.
Br's, Marius On Dec 27, 3:47 am, David Flemström <[email protected]> wrote: > On Saturday 26 December 2009 15:30:34 Marius wrote:> So I believe it is much > more constructive for ALL of us to ask > > concrete questions, described concrete problems and let's see how we > > can fix it. Many things though may be subjective and leading to > > endless discussions without substance. > > OK, then, concrete cases it is. I will try to transform the problems I > mentioned before into concrete scenarios. Hopefully, this will shed some more > light on what I mean. > > - I want a user system where each user registers with an user name and a > password, nothing else (not First Name, Last Name, E-mail etc; there shouldn't > be any entries for them in the DB either). For this, I would prefer to use > pre-existing utility classes in the Lift framework so that I don't have to > start from scratch (by extending LongKeyedMetaMapper etc), because, oh I don't > know, I don't want to code the whole user session management and password > exchange process by hand (even though it might not be too difficult; it's > reinventing the wheel nonetheless). How do I proceed? In \liftweb\lift-examples\hellolift\src\main\scala\com\hellolift\model \User.scala ... one of the Lift examples There is something like: object User extends User with MetaMegaProtoUser[User] { override def dbTableName = "users" override def screenWrap = Full(<lift:surround with="default" at="content"> <lift:bind /></lift:surround>) // LiftNote: 6 override def signupFields = firstName :: lastName :: email :: locale :: timezone :: password :: blogtitle :: Nil override val skipEmailValidation = true // LiftNote: 4 override val basePath: List[String] = "user_mgt" :: "usr" :: Nil } Have you tried setting the signupField list to use only the override def signupFields = firstName :: password :: Nil ? > > - I'd like to use ProtoUser, but need to change the labels for some of the > fields in the registration form because I want to localize the site. Please > remember that ProtoUser uses "S.??", which makes it impossible to add > translations and/or change the default wordings from the outside. How do I > proceed with the least amount of hacks (like by writing > field.displayName.replace("First Name", S.?("...")) + overriding the correct > functions with slightly changed versions of their original code)? Why it makes it impossible? You can take lift-core.properties file and put it in your WEB-INF/classes/i18n. Another approach is to tell Lift from where it should take the core resource bundle. Thus in your boot youcan say: LiftRules.liftCoreResourceName = "my_bundles" this is currently set to "i18n.lift-core" > > - I'd like to take a mapped object that I have, and CRUDify it (hint, hint). > In my mapped object (e.g. an user), I have some fields that should always > appear (e.g. basic contact information), some that should appear only to > administrators (e.g. email addresses), and some that should be read-only to > normal users and editable by administrators and specific users but not appear > to unregistered users (e.g. user profile images). Columns that should be > invisible should not be rendered in the CRUDify "list" with contents like > "permission denied"; their rendered columns should rather not appear at all. > How do I proceed with the least amount of hacks? > > - I'd like to use CRUDify again, but I need to use external templates (inside > of HTML files) for the "list", "edit", etc... pages, since I need to change > these templates after the application was compiled (or for some similar > reason, like that view/model code should be separate). How do I proceed? > > - Same situation like the above (need to control the CRUDify templates from > the outside), but I want to use a different HTML snippet depending on which > field is being rendered (I don't want to use an uniform table for the view, > but > maybe one where some fields are stacked over another, or arranged in a > different > constellation). Like this: > ============================================= > <lift:surround with="default" at="content"> > <lift:crudifyList><!--...or some other snippet name...--> > <table> > <tr> > <th> > <list:header forField="name"><em><header:value/></em></list:header> > </th><!--snip, more headers...--> > </tr> > <list:row><!--repeats for every row--> > <tr> > <row:entry forField="name"><td><entry:value/></td></row:entry> > <td> > <row:entry forField="userimage"><entry:value/></row:entry><br/> > <row:entry forField="imageDescription"><em><entry:value/></em></row:entry> > </td> > </tr> > </list:row> > </table> > </lift:crudifyList> > </lift:surround> > ============================================= > The "<em>"s etc above are of course template-specific view code that mustn't > be > in the logic code. > How do I do this with the least amount of hacks? Unfortunately I cannot help you with CRUDify since I didn't use it but I'm sure others will. > > These are of course scenarios that are fabricated but I've experienced similar > ones that I've had problems with before; I don't know if there's some kind of > solution to them that I've just missed (after some through looking, I gave up > on most of them and just wrote everything form scratch by copy-pasting Lift > source code). It all boils down to there being very specialized "starter" > classes like ProtoUser and CRUDify, that cannot be used for anything but very > small test sites in practice since they aren't extensible. I disagree about extensibility. Most of the Lift stuff is extensible and Mapper is one of them. Sure it's not perfect and there is room for improvements but in both code and documentation but IMHO this is far from "not extensible". > > > > > Br's, > > Marius > > PS. It may be that a lot of the quirks of Lift are explained in the Lift book, > and I think that that's a good start. That doesn't make them any more > intuitive, however. You can make any man (almost) into a rocket scientist by > using education, but that doesn't make rockets any easier to understand. > > David Flemström > > signature.asc > < 1KViewDownload -- 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.
