On Sat, Dec 26, 2009 at 8:47 PM, 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?
>
It's really not very hard to code this from scratch. ProtoUser doesn't do
much session management, and password management is handled by using a
MappedPassword field. Just create a mapper class with whatever data you
like, put in its singleton a SessionVar referencing the current user, and
build whatever screens you like however you would build any screen.
> - 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)?
>
I agree that ProtoUser could use some refactoring so that it's split into
independently reusable parts. I would say to file a ticket with specific
suggestions, after discussing them on the list.
> - 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'm not too familiar with CRUDify. Instead I wrote some classes in
net.liftweb.mapper.view and net.liftweb.mapper.util.BindPlus to help you
build pages from scratch more easily.
> - 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?
>
Did you search? I'm not sure offhand but I know it's been discussed. Not to
imply there's something wrong with asking, just telling you that it's there.
I think you have to subclass it and override the relevant members.
> - 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?
>
> 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.
>
Which is why they are called "Proto"User and CRUDify. If you need something
more custom, it's really not hard to build it.
>
> >
> > 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
>
--
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.
