"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Thanks. I found a bit of an example at
> http://trac.turbogears.org/turbogears/wiki/WidgetlessForm but
I was looking for this page, but I couldn't find it there, then I tried
rewriting it from memory. :-)
> unfortunately most of the rest seems to be either for esoteric stuff or
> for 0.9. There is a real lack of explanation on how to perform basic
> tasks, it seems. There's lots on SQLObject but I'm not interested in
> that at the moment unfortunately.
You can use the 20 minute wiki notes for that. It is targeted towards 0.8.
> I don't see how it really helps at all. Could you elaborate? Why would
It makes your code more clear and with less deviations.
> I want 2 different methods that are going to essentially show the same
> page anyway? Isn't that breaking some sort of web maxim about having 1
One for showing the page, one for processing data sent by it. As you saw in
the code I've sent, you can return the page from one method only...
> url per resource? I don't think the initial showing of the form and a
> showing of the same form with some errors should be considered as 2
> separate resources.
To me, showing and submitting is different. What do you do while editing
data? I submit data and come back to the same edition page, with the new data
entered, of course.
> Is this just to have multiple URLs go through the same Controller
> method? I don't think I'd want to do it that way since I would expect
> every distinct URL to have a different behaviour.
No, it is not multiple URLs.
index() -> when you access "someurl/" you'll get the index for "someurl"
default() -> when no other expose()d method satisfy the URL traversal
controller() -> this is what is actually shown in my "boilerplate", since the
two above call it to send the output
save() -> receives an action to insert a new record on the database
update() -> receives an action to update a record
delete() -> removes a record from the database
This is how I structured my code... All three methods return controller()
with the right parameters here... So, only controller() calls the template.
I could have an "edit()" method to show data and avoid having to test for it
in controller(), but I thought it was too much...
>
>> @turbogears.expose() # If returning a different page, you have
>> to
>> # pass the template here as I did in
>> controller()
>> @formencode.validators(...) # Will become turbogears.validators in 0.9
>
> Unfortunately that is now the 3rd different way I've seen to use
> validators, which is part of why I don't particularly want to touch
> them at this point.
This is using formencode directly. Widgets encapsulate all the "from_python",
"to_python" calls, making it easier for you. At least they make it easier to
me. :-)
> Ok, that's quite helpful, thanks. Is there anywhere in the official
> documentation that shows that, in addition to strings and dicts, you
> can return... well, whatever that object is, to do a redirect? I would
> never have known to dig through the cherrypy documentation for that.
I'd refrain from using anything other than strings or dicts. But I believe (I
haven't tried) that you can return lists and use positional elements to get
data from it...
In fact, you can return anything: the problem is what will be done with it.
If you return an object to the browser, without a template, I believe it will
show its __repr__() or __str__()... Give it a try.
> I'm not complaining at you, of course. You've been very helpful. I am
> just trying to make it clear to anyone reading that this is really all
> very obscure.
:-) Even if you were complaining to me there's no problem at all. :-) You
have to complain to somebody/somewhere... :-)
Take a look at the 20 minute wiki tutorial (for 0.8) and you'll see all of
that and it might really help you getting started with TG.
>> <input type="text" id="my_id" name="my_name" />
>> <span py:if="errors">${errors.get('my_name_error', '')</span>
>
> Yes, that makes sense to me, from my PHP background.
Good! It isn't all lost then! ;-)
>> For this hypothetical "form", when submitted you'd process and test
>> kword['my_name']. To fill in the form you'll have to change it a little:
>>
>> <input type="text" id="my_id" name="my_name"
>> py:value="data.get('my_name', '')" />
>> <span py:if="errors">${errors.get('my_name_error', '')</span>
>>
>> and pass a "data" dictionary. If you're reusing forms to enter and show
>> data,
>> this will work. You can use data['my_name'] if you're sure it exists
>> (otherwise you'd get an AttributeError in your template).
>
> I assume I can just fill data with the contents of kword, and as you
> say use 'get' in case the values haven't been submitted.
Yes, in this case I called the dictionary "data", just to be more explicit
about it. I use "kword" to receive input and "data" to send output.
> Perhaps I just picked a bad time to start using TurboGears when the
> knowledgeable users seem to be mostly using a version that differs
> significantly from the last stable one.
TG 0.9 is coming out really soon now. There's an RC already (I thought I read
that today on some bug report or here at the mailing list). Maybe it would be
better if you started with it? At least you'd have much more to work and
wouldn't have to reinvent the wheel...
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
