Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto rendered forms are not usable #118

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

pavolzibrita
Copy link

Probably not the most correct fix, but should be helpful.

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.
@mbr
Copy link
Owner

mbr commented Dec 8, 2015

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).

@pavolzibrita
Copy link
Author

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?

@mbr
Copy link
Owner

mbr commented Jan 2, 2016

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:

  1. The underlying concepts are sound and clean.
  2. It's lacking docs (not only API docs, but examples, etc).
  3. The implementation is incomplete, since not all Widgets are rendered yet.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants