On Jul 7, 3:25 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> > It's okay thouh I'll just work around this issue by replacing the "-"
> > character by something else in the template and then resetting it in
> > the controlelr.
> > I just though it would be good to be able to change the
> > variable_encode and variable_decode default values...
>
> Not really, because that would also mean that all code that *generates* names
> conforming to that (think of various widget packages) needs to be aware of
> that.
>
I see your point, you're right, it would make things more
comlplicated, on the other hand, not knowing that this character
caused this behaviour made me scratch my head for a while before I
could figure it out. I don't remember seeing anything in the doc on it
so if there isn't, might be good to make a note of it.
> > > Use some different naming scheme for these, or even better get rid of
> > > them as names totally. I don't think that using dynamic form input
> > > *names* is a good idea. Why can't you use something like
>
> > > <input type="hidden" name="uuid" value="one-uuid"/>
>
> > > instead?
>
> > Why would that be a bad idea ? Those uuids are unique, so they can't
> > conflict with anything and I'm not the one creating them, they were
> > created before (I use them because I don't really have a choice and I
> > find it silly to use another unique key for my purpose).
> > This just makes things easier.
>
> No, it doesn't. A controller usually defines a fixed set of parameter names it
> expects. Having a design that allows arbitrary names to be passed complicates
> things. And what happens if someone creates a UUID that conflicts with a
> parameter name? Yes, I'm aware that won't likely happen, but you *rely* on
> that - instead of choosing a design that doesn't suffer from this in the
> first hand. Or think of validation - altering names make it impossible to
> validate proper, but you might want to check if the passed UUIDs are known to
> your system.
>
> OTOH I fail to see why my suggestion of passing the UUID as *values* for a
> well-known parameter won't work for you.
>
I see your point and I've decided to use this validate_encode feature
instead of going around it, so basically now I have two inputs for
each items:
<p py:for="count, item in enumerate(list_item)" style="padding-top:
10px; padding-bottom: 10px;">
<input type="hidden" name="item-${count}" value="$
{item[0].uuid_item}"></input>
<input name="item-${count}" type="text" value="$
{item[0].label}"></input>
</p>
In the controller I then have a parameter called item and it's bvalue
is something like this :
[[u'first_uuid', u'firstLabel'], [u'second_uuid', u'second_item'], and
so forth ...]
Thanks for your insight, now all I need is devise a validator that
makes sure all the labels are not null...
> Diez
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
