>> /config/user/validate
>> used as a form action, validates values for a added or modified user

> Err, did you mean to say "/config/user/[loginName]/validate"?  If so,
> this makes sense.  If not, how do you know which user to validate?

No, I didn't. I keep the current user as an attribute of the UserForm
object, linked to the session.


> Assuming I'm correct, this looks URL scheme sensible to me.  Of course
> it means that no user can have a login name "add" in your system, but if
> you can live with that, then so can I.  ;-)

Yes, I can. :^) And I already noted this at the end of that email. :^)


> I didn't read Titus' response carefully, so I'm not sure if I'm about to
> duplicate his advice.  Anyways, here's what I'd do:
> [code deleted]
> The trick, of course, is that creating a user and editing a user are
> very similar, and you want to reuse the same code.  You've already
> figured out that you want a UserForm class, but it's not clear that
> you've figured out what to put in it.  Here's a starting point:
> [code deleted]
> See form/form.ptl for how the various Form._render_*() methods interact.
>
> Obviously, the process() and action() methods will also branch on
> self.user: eg. if self.user is None, then process() has to make sure a
> valid user ID was entered and create a new user object, and action() has
> to add it to your database.  Or something like that.

Thanks, I already implemented a more extensively modified subclass of Form.

My doubts concerned the path traversal code before getting to UserForm, and
the possibility to simplify it by means of an index telling at which point
of the path a component appeared.

But nobody seems much interested in it, so I'll have to keep making do.


--
"A true conversation is a creative force -- you could almost say,
*the* creative force -- by which new things come into the world."
   Steve Talbott, NetFuture

Nicola Larosa - nico@tekNico.net