Form API survey

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

Form API survey

Fabian Jakobs
Administrator
Hi,

we would like to get a picture of how the current form API is used in
the wild.

1. Do you know that there is a IFromElement interface?

2. Do you actually use it or depend on it?

3. The interface defines a "name" property. Are you using it? If yes,
how are you using it?

4. The interface defines a "value" property. In the interface no type is
defined for this property. Concrete form widgets defines this property
with different data types and only accept those types. Are you aware of
this? Has this ever been a problem?

5. Is there anything you miss from this interface? Do you have other
ideas of how to improve the form interface.


We would like to hear your comments. Feel free to comment here on the
list or directly in the associated bug report
<http://bugzilla.qooxdoo.org/show_bug.cgi?id=2099>.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form API survey

Jean-Baptiste BRIAUD -- Novlog
On 12 Mar 2009, at 13:03, Fabian Jakobs wrote:

> Hi,
>
> we would like to get a picture of how the current form API is used in
> the wild.
>
> 1. Do you know that there is a IFromElement interface?
>
Yes.

> 2. Do you actually use it or depend on it?
>
Yes.

> 3. The interface defines a "name" property. Are you using it? If yes,
> how are you using it?
>
Plane to use it for automated test, but still not done yet.

> 4. The interface defines a "value" property. In the interface no  
> type is
> defined for this property. Concrete form widgets defines this property
> with different data types and only accept those types. Are you aware  
> of
> this? Has this ever been a problem?
>
Yes, Has not been an issue. In fact, it has been an advantage since I  
can loop on all wodgets to get all the values to submit to the backend  
for example. I'm not sure to see if that would become impossible if  
types are added, but it is important to allow for generic "form  
browsing" in a loop without having to test for type to get the value  
or set the value.
> 5. Is there anything you miss from this interface? Do you have other
> ideas of how to improve the form interface.
>
Few ideas, feel free to comment :-)
* a boolean to represent the valid or invalid state of the widget. qx  
would "magically", depending of decoration, put a red border in case  
of invalid state. This would simplify that on our application code.
* a boolean for mandatory or not so when the form is validated, this  
is checked. This need to have not only iFormElement but also iForm  
(set of iFormElement) and an event system that all iFormElement could  
fired when filled, when valid/invalid, ..
* a dependency on other iFormElement, some element need that some  
other had been filled before. Qx will ensure that like mandatory but  
with interconnection.
* a link to the label, so both may be hidden in one call by us when  
needed
* I didn't fully digg that but some regular expression could be  
attached to a form element to make sure it is valid. (What about  
table ?)

>
> We would like to hear your comments. Feel free to comment here on the
> list or directly in the associated bug report
> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=2099>.
>
> Best Fabian
>
>
> --
> Fabian Jakobs
> JavaScript Framework Developer
>
> 1&1 Internet AG - Web Technologies
> Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
> Telefon: +49 721 91374-6784
> [hidden email]
>
> Amtsgericht Montabaur / HRB 6484
> Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich,  
> Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning  
> Kettler, Dr. Oliver Mauss, Jan Oetjen
> Aufsichtsratsvorsitzender: Michael Scheeren
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
> are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly  
> and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
> development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form API survey

Petr Kobalíček
In reply to this post by Fabian Jakobs
1. Yes
2. No
3. No
4. I have own API that can knows about it
5. I think that current way is unusable for me. I needed to create own
form building API with databinding. I don't know if this is qooxoo
fail or I needs too much, I just wrote own forms and I'm quite happy
with it:)

Note: I don't know how databinding can be used in 0.8.2, I started
with 0.7.3 and ported it to 0.8 when it was released. Currently I have
API that I'm using like model/view controllers. So when I change one
item in one form, all other forms where the model is used are updated.

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form API survey

Ian Horst
In reply to this post by Fabian Jakobs
No to all questions.


However I would like to see interface for live & post filtering & validating of input, and error handling.

I have currently implemented these interfaces as static methods passing input obj and corresponding filter & validator classes.


For example.

To allow to type only digits in TextField, filter listens to key inputs and filters out all inputs except digits.

x.filter.Util.setFilters(textfield, [new x.filter.Digits]);


To validate email address, filter ignores prefixed&suffixed whitespaces and validates input as email address. On input event and invalid field value, sets textcolor to red.

x.filter.Util.setFilters(textfield, [new x.filter.StringTrim]);
x.validator.Util.setValidators(textfield, [new x.validator.EmailAddress]);


Ian Horst


Fabian Jakobs wrote:

> Hi,
>
> we would like to get a picture of how the current form API is used in
> the wild.
>
> 1. Do you know that there is a IFromElement interface?
>
> 2. Do you actually use it or depend on it?
>
> 3. The interface defines a "name" property. Are you using it? If yes,
> how are you using it?
>
> 4. The interface defines a "value" property. In the interface no type is
> defined for this property. Concrete form widgets defines this property
> with different data types and only accept those types. Are you aware of
> this? Has this ever been a problem?
>
> 5. Is there anything you miss from this interface? Do you have other
> ideas of how to improve the form interface.
>
>
> We would like to hear your comments. Feel free to comment here on the
> list or directly in the associated bug report
> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=2099>.
>
> Best Fabian
>
>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form API survey

Krycek
Hi,

I've tried to create a class to load/retrieve informations from/to a form. And that: "The user is forced to know, which type a concrete form element expects and has to code accordingly." (from http://bugzilla.qooxdoo.org/show_bug.cgi?id=2099) resumes what I've faced.

So:
1 and 2: Yes
3: No
4: Yes
5. It would be specially useful if that interface define methods to serialization and the widget itself was aware of the converstions needed to set/get data (others interfaces could be created here).

On Thu, Mar 12, 2009 at 1:05 PM, Ian Horst <[hidden email]> wrote:
No to all questions.


However I would like to see interface for live & post filtering & validating of input, and error handling.

I have currently implemented these interfaces as static methods passing input obj and corresponding filter & validator classes.


For example.

To allow to type only digits in TextField, filter listens to key inputs and filters out all inputs except digits.

x.filter.Util.setFilters(textfield, [new x.filter.Digits]);


To validate email address, filter ignores prefixed&suffixed whitespaces and validates input as email address. On input event and invalid field value, sets textcolor to red.

x.filter.Util.setFilters(textfield, [new x.filter.StringTrim]);
x.validator.Util.setValidators(textfield, [new x.validator.EmailAddress]);


Ian Horst


Fabian Jakobs wrote:
> Hi,
>
> we would like to get a picture of how the current form API is used in
> the wild.
>
> 1. Do you know that there is a IFromElement interface?
>
> 2. Do you actually use it or depend on it?
>
> 3. The interface defines a "name" property. Are you using it? If yes,
> how are you using it?
>
> 4. The interface defines a "value" property. In the interface no type is
> defined for this property. Concrete form widgets defines this property
> with different data types and only accept those types. Are you aware of
> this? Has this ever been a problem?
>
> 5. Is there anything you miss from this interface? Do you have other
> ideas of how to improve the form interface.
>
>
> We would like to hear your comments. Feel free to comment here on the
> list or directly in the associated bug report
> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=2099>.
>
> Best Fabian
>
>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Form API survey

Gaetan de Menten
In reply to this post by Jean-Baptiste BRIAUD -- Novlog
On Thu, Mar 12, 2009 at 14:08, Jean-Baptiste BRIAUD -- Novlog
<[hidden email]> wrote:
> On 12 Mar 2009, at 13:03, Fabian Jakobs wrote:

>> we would like to get a picture of how the current form API is used in
>> the wild.
>>
>> 1. Do you know that there is a IFromElement interface?

Yes

>> 2. Do you actually use it or depend on it?

No. I started writing my own form code with data binding for 0.6.x and
only ported it  "straight forwardly" to 0.7.x and 0.8.x. Not sure if I
could have use the API as when I looked at it (a while ago), it didn't
fit my needs, but haven't looked at it since.

>> 3. The interface defines a "name" property. Are you using it? If yes,
>> how are you using it?

N/A

>> 4. The interface defines a "value" property. In the interface no
>> type is
>> defined for this property. Concrete form widgets defines this property
>> with different data types and only accept those types. Are you aware
>> of this? Has this ever been a problem?

N/A

>> 5. Is there anything you miss from this interface? Do you have other
>> ideas of how to improve the form interface.

> Few ideas, feel free to comment :-)
> * a boolean to represent the valid or invalid state of the widget. qx
> would "magically", depending of decoration, put a red border in case
> of invalid state. This would simplify that on our application code.

Same here. I've implemented this on my own API.

> * a boolean for mandatory or not so when the form is validated, this
> is checked. This need to have not only iFormElement but also iForm
> (set of iFormElement) and an event system that all iFormElement could
> fired when filled, when valid/invalid, ..

Same here.

> * a link to the label, so both may be hidden in one call by us when
> needed

Same here :). Also useful to set focus on the input when the label is
clicked, as in pure HTML.

--
Gaëtan de Menten
http://openhex.org

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel