form field naming schema

classic Classic list List threaded Threaded
6 messages Options
Amarookie Amarookie
Reply | Threaded
Open this post in threaded view
|

form field naming schema

Checking out the ATExtensions Product, I noticed that there seems to be
some kind of "secret" naming schema for HTML form fields (e.g the "name"
attribute of an input element).

It seems to look like this:

name= {fieldName}:{type}:{widget-/field-type}:{emptyFlag}

{fieldName}: the name of the AT-Schema field
{type}: primitive type name like string, int, float,...
{widget-/field-type}: the registered name of the field-type/widget-type?
{emptyFlag}: I'v seen an "ignore_empty" here

It seems that these values are used to to some validating/preprocessing
e.g. if {type} is 'float' and you enter a non-float value, you get a
SiteError, stating:
Error Type: ValueError
Error Value: A floating-point number was expected in the value '1,1'

Now the question:
Where does this preprocessing happen? As far as I could see, not in the
BaseObject.processForm() and not in the widgets process_form either.

Is the naming schema documented some where?

Thanks for any pointer!

Bernd Hofner







-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Archetypes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/archetypes-users
Raphael Ritz Raphael Ritz
Reply | Threaded
Open this post in threaded view
|

Re: form field naming schema

Bernd Hofner wrote:
> Checking out the ATExtensions Product, I noticed that there seems to be
> some kind of "secret" naming schema for HTML form fields (e.g the "name"
> attribute of an input element).

Correct, except that there is nothing 'secret' about this ;-)

>
> It seems to look like this:
>
> name= {fieldName}:{type}:{widget-/field-type}:{emptyFlag}
>
> {fieldName}: the name of the AT-Schema field
> {type}: primitive type name like string, int, float,...
> {widget-/field-type}: the registered name of the field-type/widget-type?
> {emptyFlag}: I'v seen an "ignore_empty" here
>
> It seems that these values are used to to some validating/preprocessing
> e.g. if {type} is 'float' and you enter a non-float value, you get a
> SiteError, stating:
> Error Type: ValueError
> Error Value: A floating-point number was expected in the value '1,1'
>
> Now the question:
> Where does this preprocessing happen? As far as I could see, not in the
> BaseObject.processForm() and not in the widgets process_form either.
>
> Is the naming schema documented some where?

Ever heard of Zope?

Zope's ZPublisher understands a couple of packaging and
format handling directives that are also used by ATExtensions.
You'll even understand why I called the RecordField that way ;-)

 > Thanks for any pointer!

http://www.plope.com/Books/2_7Edition/ScriptingZope.stx#1-6
http://www.zope.org/Members/Zen/howto/FormVariableTypes
http://zopewiki.org/ZPublisher

Raphael



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Archetypes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/archetypes-users
Amarookie Amarookie
Reply | Threaded
Open this post in threaded view
|

Re: form field naming schema

Hello Raphael,

> Ever heard of Zope?

What this? Do I need it for washing? ;-)

>
> http://www.plope.com/Books/2_7Edition/ScriptingZope.stx#1-6
> http://www.zope.org/Members/Zen/howto/FormVariableTypes
> http://zopewiki.org/ZPublisher

Ahh, this enligthens me! It's kind of hard to unpeel all these software
layers...

BTW I'm looking into the issue of l10n of numeric fields.
Zope 2.8.1+ introduces a nice package (zope.i18n) for parsing and
formatting of internationalized data values.

I thougth to add such a language aware parsing/formatting capability to
the RecordField.

The general idea is:

* Add a property "subfield_formats = { 'subfieldName1' : '#,##0.00', ...}
to the RecordField.
* Make the RecordField aware of the current locales language.
* The record field formats the stored float subfield values NLS aware
according to the given format (e.g de: 10,23 en: 10.23)
* The record field parses the float form field according to the current
locale and stores them as float (e.g. de: '10,23' => 10.23 en: '10.23'
=> 10.23)

I already build a small l10nTool which uses the PloneLanguageTool to
determine the current language and caches the Locale data provided by
the zope.i18n.locales package.

Alas, the Zope form preprocessing took me by surprise. Now you just need
to tell me that you can make the ZPublisher language aware by just
setting this nifty litte configuration parameter...


Thanks,

Bernd



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Archetypes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/archetypes-users
Raphael Ritz Raphael Ritz
Reply | Threaded
Open this post in threaded view
|

Re: form field naming schema

Bernd Hofner wrote:

Hi Bernd,

[..]
> BTW I'm looking into the issue of l10n of numeric fields.
> Zope 2.8.1+ introduces a nice package (zope.i18n) for parsing and
> formatting of internationalized data values.
>
> I thougth to add such a language aware parsing/formatting capability to
> the RecordField.

Good idea! Do you have write access to the AT repository?

> The general idea is:
>
> * Add a property "subfield_formats = { 'subfieldName1' : '#,##0.00', ...}
> to the RecordField.
> * Make the RecordField aware of the current locales language.
> * The record field formats the stored float subfield values NLS aware
> according to the given format (e.g de: 10,23 en: 10.23)
> * The record field parses the float form field according to the current
> locale and stores them as float (e.g. de: '10,23' => 10.23 en: '10.23'
> => 10.23)

Sounds good.

> I already build a small l10nTool which uses the PloneLanguageTool to
> determine the current language and caches the Locale data provided by
> the zope.i18n.locales package.

Maybe the PloneLanguageTool should just be extended to do this

> Alas, the Zope form preprocessing took me by surprise. Now you just need
> to tell me that you can make the ZPublisher language aware by just
> setting this nifty litte configuration parameter...

Sorry, not that I know :-(

Any Zope 3 gurus out there who know whether and if so how
Zope 3 handles this?

Raphael



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Archetypes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/archetypes-users
Amarookie Amarookie
Reply | Threaded
Open this post in threaded view
|

Re: form field naming schema

Hello Raphael,

> Good idea! Do you have write access to the AT repository?

Nope.

> Maybe the PloneLanguageTool should just be extended to do this

Yes, I had the same idea, but I'm a bit shy of the administrative
overhead involved...

>
>> Alas, the Zope form preprocessing took me by surprise. Now you just
>> need to tell me that you can make the ZPublisher language aware by
>> just setting this nifty litte configuration parameter...
>

Basically, I would suggest to avoid using the ZPublisher "float"
conversion altogether. The error message you get when entering a "wrong"
float value is kind of user unfriendly anyway.
I think changing the record/records.pt to use
        ${fieldName}.${key}:string:records:ignore_empty
instead of
        ${fieldName}.${key}:${type}:records:ignore_empty
might do the deed.

Probably it's better to place an "automagic" validator at the begin of
the validation chain, that tries to parse the value and report parsing
errors via the errors collection.
I haven't looked into the validation mechanism, yet, but I think this
should be possible.
This validator would then also replace the raw string value in the form
collection with the parsed float value. Then user defined validators
need not do their own parsing...

We'll see where I get.

Bernd

Bernd



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Archetypes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/archetypes-users
Amarookie Amarookie
Reply | Threaded
Open this post in threaded view
|

Re: form field naming schema

<sigh>, I think I have something like a working prototype.
The form processing framework is a maze.
Why is the widgets process_form called so often (8-10 times after a post)?

Well here is what I did:

records_widget.pt
        ${type} replaced by string for float/int/long subfields

RecordsField.getSubfieldValues:
        now does a NLS format for float subfields

RecordField.set:
        now does a NLS parse of float subfields,
        if they are passed in as a string

RecordField.validate:
        now does a NLS parse of float subfields,
        if they are passed in as a string. The parsed strings (then floats) are
passed down the validation chain, but the original form values are left
untouched. So in case of a validation error, the original user string
input is posted back to the form, not the raw float values.
       
This still needs some testing, especially some special cases like
* no format given for a float subfield,
* wrong format strings given for subfields,
* usage with RecordField....

Bernd




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Archetypes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/archetypes-users