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?

- 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'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?

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.

> 
> 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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to