Conversation
Wrapped inputs get rendered without name and so the form object does not work correctly. I'm not sure what is the correct fix for this, this looks to me more as a quickfix as probably more node's attributes should be put there. Or, why not just use the node render itself? Even the sample app's example form does not work because of this.
|
Thanks for submitting. I can't look at it right now, but I'll hopefully be able to do so later (and release the new upstream release). |
|
Hi Marc, actually I wanted to ask, how the form generator was meant to work, because maybe I'm just doing something wrong. I'm using the appengine, so one can never know. Also, I found that moest of the generated components have the problem, so this is only partial fix from the bigger one. Is this project active? Is this part of the project active? |
|
Sorry for the delay, I've been quite busy. The project is very much active. Currently, there are two ways of rendering forms, the "old" macro-based way and the visitor/dominate-based generation. The macro way is the currently stable one. You can tell because the visitor/dominate version does not have any docs published. I would like to introduce it gently, while not breaking any old code; however I continuously underestimate the willingness of developers to read my code instead of just the docs. I guess I don't write good enough docs. =) While is visitor/dominate version is not officially "released" (it's officially undocumented, but the code is shipped and you can import it if you want), it is a much cleaner approach and I hope it will become the default way of doing things in the coming months. The macro-based way is not a good way forward, because it becomes a tangled mess very quickly if you want to customize things. I never intended for form generation to be used this widely, initially, I assumed developers would use a quick-and-dirty form and handcraft a "real" form before release. The fact that I myself never do this should have told me something. Since a new way of doing things was needed, I've added the visitor approach, which worked quite well with Flask-Nav as well (and is neatly factored out in the visitor library). The current state of the code is this:
If you want to use the code, you're welcome, it will most likely be the way forward. Be warned that there may not be all batteries included yet. |
Probably not the most correct fix, but should be helpful.