Max Ischenko wrote:
> Hello Alberto and others,
>
> My feedback on trying out twForms following "part 1" tutorial.
>
> 0. It all worked!
Great!
>
> 1. middleware configuration step could be optional, since I believe you
> could do the same with some magic tweaking of .ini file.
This could be done, TW even exposes a paste.app_filter entrypoint but I
don't think it is a good idea to configure TW this way since it's not a
configuration option users should be able to modify, let alone disable.
It's more or less the same reason why you shouldn't configure Routes'
middleware using the .ini file.
>
> 2. API docs kind of useless.
> I have tried pydoc hint, mentioned in the article.
> "pydoc toscawidgets.api" gives nothing useful, just like "pydoc
> toscawidgets.widgets" and others.
:S I think I'll need to hack around that. I believe that by dynamically
generating an __all__ list pydoc (and others) should be able to better
introspect the symbols.
>
> I knew for sure that besides ListForm forms there should be other
> variant but how I am supposed to find it out? "pydoc
> toscawidgets.widgets.forms" doesn't mention either ListForm or anything
> else in particular but gives a useless list of confusing names. Alice
> down the rabbit hole. ;)
>
> 3. FormEncode's UnicodeString validator didn't work, producing ascii
> error when redisplaying the form. Using TW version did work fine.
I do believe that this is because FE's UnicodeString.from_python returns
a str instead of unicode. I'm not too sure of the rationale behind this
but, given that most template languages now expect unicode to be used
internally (only encoding when finally rendered), I think FE's
from_python should also return unicode. This came up some time ago in
FE's list, if you google for "toscawidgets" and "unicodestring" in it's
archives I'm sure the thread will pop up.
>
> 4. Is it possible to specify error_handler as a full request path, e.g.
> "/pages/contacts/" instead of attrname of the current obj? The default
> approach is too inflexible (as is Pylons default, btw)
I find hard to understand the use-case where one would want to process a
form's submission in a different controller than the one which displayed
it (I personally even use the same method and dispatch on HTTP verb)
However, it's been asked for some times so I guess there should be a
reason... :) I believe InternalRedirect (the only method I can think of
right now that could be used) might work if it's stacked below TW's
middleware (so TW's request-local storage is not destroyed), which I
think it is. Please open an "enhancement" ticket at TG's trac so I or
someone remembers to investigate it some time.
> 5. I think "fancy fields" part could be safely moved to "part X" document
Yep, part 2 should come up shortly (I've been all weekend stranded in
offline-land :( )
>
> 6. I'd really like to see docs that tell how to control layout of the
> HTML code produced. You see, I have a great HTML/CSS guy in my team and
> he is responsible for all HTML/CSS produced by our app. Hence he wants
> to be in control and b able to easily tweak it. As it is, Python code
> essentially obscures what's going on underneath. He even objects to
> web_helpers and so I think twForms magic may be too much to ask. ;)
If he objects to python functions in templates like webhelpers' then I
don't think he'd like twForms at all either since fields are rendered
this way: ${display_child('name')}.
In this scenario twForms might not be a good solution. twForms is a
higher-level layer on top of plain html. As with all abstractions, some
flexibility is lost in exchange for simplicity.
> All in all, it seems good. The only thing it needs is IMO better
> exposure (more users, more use cases, more bugs gets fixed).
>
> It may be a good idea to browse excellent docs for Django's newforms -
> TW competitor.
Err.. s/TW/twForms/g :) I don't think newforms and TW try to address the
same issues... AFAIK, newforms aims at form generation (as twForms
does). TW, on the other hand, aims to provide a way to produce
*portable* (quite different from newforms here :) and self contained
bits you can render on templates which pack their css and javascript
with a python interface to configure them. A good example of this is the
tinymce widget.
Well, I guess I'm just being picky on the names here... :)
You can steal ideas how to organize/present twForms
> concepts and may be some design ideas as well. I also contemplate idea
> to try to port newforms to Pylons, just to see whether it is technically
> feasible.
Would be a good idea. Certainly twForms might be too heavyweight if all
you need is a way to generate markup, without all the
inter-template-engine conversion and support for "plug&play" rich widgets.
Thanks for the feedback!
Alberto
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
