Forms support?
Voltron
testing it on a new application I'm developing.
Thanks
Christopher S Coté
Hopefully today or tomorrow I can wrap it up.
Christopher S Coté
exactly.
In Humongolus the base document objects handle all the validation. It
would appear you would basically be creating duplicate objects for your
forms.
What I was thinking for the Forms, was basic form rendering as well as
parsing a GET/POST request to a Model allowing you to handle any errors.
The interesting thing about Humongolus is the somewhat "recursive"
nature of the object structure, you can create endlessly embedded
documents, so handling name spacing is crucial.
Please let me know your thoughts.
On 02/22/2012 12:21 AM, Voltron wrote:
Voltron
Sorry about the mixup. Actually, I just wanted you to take a look at
the Form class in WTForms for pointers, nothing more. :) Let us know
when you are finished.
Thanks
Christopher S Coté
check out test.py at the bottom to see the implementation.
Tutorials coming soon!
On 02/22/2012 04:32 PM, Voltron wrote:
> Hi Christopher!
>
> Sorry about the mixup. Actually, I just wanted you to take a look at
> the Form class in WTForms for pointers, nothing more. :) Let us know
> when you are finished.
>
> Thanks
>
Voltron
a few issues with the Form Class
1. One cannot iterate over the form fields easily as in other Form
frame works. I have a generic Jinja2 template that iterates over all
the fields for rendering.
form = PersonForm(obj=voltron, data=submit)
for field in form._fields:
print field
the above was not an option either because it did not work and
"._fields" looks like a "private" property
"print field.render()" emitted a traceback error
2. Form field errors should accumulate in a list. One should be able
to iterate over this list of errors too for rendering. Some forms
render all the errors at the top for example.
class Human(orm.Document):
_db = "test"
_collection = "humans"
human_id = field.AutoIncrement(collection="human")
name = field.Char(required=True, min=2, max=25)
age = field.Integer(required=True, min=0, max=3000)
try:
form.validate()
except orm.DocumentException as e:
print e.errors
I made 2 fields required, and only one error was printed
3. The CSS ID, CSS class, action and method should be calss properties
that one can dynamically change if necessary
I will let you know if I find anything else
Christopher Coté
The iteration is definitely doable, as well as the list of errors. I'll look into why only one error was propagating up.
Hey Christopher! I just did a quick test. Its a good start but I have
a few issues with the Form Class
1. One cannot iterate over the form fields easily as in other Form
frame works. I have a generic Jinja2 template that iterates over all
the fields for rendering.
form = PersonForm(obj=voltron, data=submit)
for field in form._fields: # <- this was not an option either because
it did not work and it looks like a "private" property of the form
class
print field
2. Form field errors should accumulate in a list. One should be able
to iterate over this list of errors too for rendering. Some forms
render all the errors at the top for example. I cr
class Human(orm.Document):
_db = "test"
_collection = "humans"
human_id = field.AutoIncrement(collection="human")
name = field.Char(required=True, min=2, max=25)
age = field.Integer(required=True, min=0, max=3000)
try:
form.validate()
except orm.DocumentException as e:
print e.errors
I made 2 fields required, and only one error was printed
I will let you know if I find anything else.
Voltron
when a form use <button> tags or AJAX to submit data.
Christopher S Coté
On 02/23/2012 10:36 AM, Voltron wrote:
> Cool, another thing, the submit button must be optional for the cases
> when a form use<button> tags or AJAX to submit data.
>
Voltron
Christopher Coté
As far as your required validation issue.
If you were using test.py directly and just added the required
attribute, it in fact already has a value from setting it earlier.
rather than removing the "age" attribute from the submit dict, set it
to "None" or None, basically anything in the EMPTY tuple at the top of
__init__.py.
Let me know if that makes sense.
Voltron
would be great if you made Humongolus also available from Pypi. A lot
of people including myself automate installing and deployment of
modulesl
Christopher S Coté
available in the DocumentException that's thrown.
for k,v in form.errors.iteritems():
print "%s: %s" % (k, v)
for fi in form:
if fi._object._error: print fi._object._error
On 02/23/2012 11:45 AM, Voltron wrote:
> Great! That was fast! I am downloading the new version right now. It
> would be great if you made Humongolus also available from Pypi. A lot
> of people including myself automate installing and deployment of
> modulesl
>
> On Feb 23, 6:40 pm, Christopher Cot�<ch...@entropealabs.com> wrote:
>> Added form iteration. Again look at test.py
>>
>> As far as your required validation issue.
>>
>> If you were using test.py directly and just added the required
>> attribute, it in fact already has a value from setting it earlier.
>> rather than removing the "age" attribute from the submit dict, set it
>> to "None" or None, basically anything in the EMPTY tuple at the top of
>> __init__.py.
>>
>> Let me know if that makes sense.
>>
>> On Feb 23, 10:40 am, Voltron<nhy...@googlemail.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Ahh! OK, got it,
Voltron
comfortable. Let me explain with a Tornado snippet I use:
{% for field in form %}
{% raw _(field.label()) %}
{% if field.errors or field.description %}
{% if field.errors %}
<ul class="fm-error">
{% for error in field.errors %}
<li>{% raw _(error) %}</li>
{% end %}</ul>
{% end %}
{% else %}
{% raw _(field.description) %}
{% end %}
Why not just field.errors instead field ._object._error ? A field
could be validated against multiple schemas?
Christopher S Coté
Let me see what I can do.
On 02/23/2012 12:11 PM, Voltron wrote:
> OK. almost there, sorry to nag :) Its almost there but not
> comfortable. Let me explain with a Tornado snippet I use:
>
> {% for field in form %}
> {% raw _(field.label()) %}
>
> {% if field.errors or field.description %}
> {% if field.errors %}
> <ul class="fm-error">
> {% for error in field.errors %}
> <li>{% raw _(error) %}</li>
> {% end %}</ul>
> {% end %}
> {% else %}
> {% raw _(field.description) %}
> {% end %}
>
> Why not just field.errors instead field ._object._error ? A field
> could be validated against multiple schemas?
>
Christopher Coté
Added description and a label method as well.
On Feb 23, 12:30 pm, Christopher S Coté <ch...@entropealabs.com>
wrote:
Christopher Coté
Voltron
implementing the features so quickly
Christopher S Coté
what they say.
If it's not tested, it's broken ;)
It will be tested by the end of this weekend, just want to make sure
it's usable for you so I can get some more feedback.
Thanks for being patient.
On 02/23/2012 02:03 PM, Voltron wrote:
> You are the "Flash"! Christopher "Flash Cote :) Thanks for
> implementing the features so quickly
>
> On Feb 23, 8:18 pm, Christopher Cot�<ch...@entropealabs.com> wrote:
>> I'll be adding the form stuff to the unit-tests over the weekend.
>>
>> On Feb 23, 12:54 pm, Christopher Cot�<ch...@entropealabs.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Boom, pull the latest.
>>> Added description and a label method as well.
>>> On Feb 23, 12:30 pm, Christopher S Cot�<ch...@entropealabs.com>
Voltron
wonder how I can lazy connect to MongoDB
Christopher S Coté
you want to lazy load individual attributes?
On 02/23/2012 04:02 PM, Voltron wrote:
> No problem, I will let you know if I have any issues. For now, I
> wonder how I can lazy connect to MongoDB
>
Voltron
as an attribute of my request handlers for use. With Humogolus, its
different, I would probably have to pass the connection directly to
the ORM classes when instantiating
On Feb 23, 11:05 pm, Christopher S Coté <ch...@entropealabs.com>
wrote:
Christopher S Coté
humongolus.
In my startup script i generally create one connection and pass that to
humongolus.settings()
you should also pass in a logger object.
On 02/23/2012 04:41 PM, Voltron wrote:
> No the mongoDB connection, normally I init one connection and pass it
> as an attribute of my request handlers for use. With Humogolus, its
> different, I would probably have to pass the connection directly to
> the ORM classes when instantiating
>
> On Feb 23, 11:05 pm, Christopher S Cot�<ch...@entropealabs.com>