Hello,
thanks for the interests in the data binding component.
First of all to the questions of Guilherme:
1) The initial state will not be validate currently. Perhaps that will
be changed later if it is necessary for the binding. But currently you
can set an initial value via the init tag which will not be validated.
But its a good question if the property should be set if the value is
not valid. I will discuss this in the team and see what‘s their
opinion.
2) Currently that will be the case. With the Data Binding component
there will be some solution which you don‘t have to write any try-
catch block at all if you just like to visualize the invalid state.
Thats just some Ideas. In the end you are right, a user don‘t want to
write 20 try-catch blocks so i will keep an eye on that topic.
As you said right, I do have some ideas on how to implement data
binding in qooxdoo but they are not more than ideas. So I have to work
up the ideas to good concepts. When I have some good and proved
concepts I let you know.
Now to the Feedback of Petr:
I am aware of the Problem that validation on the server is not
possible with the solution out of the box. Perhaps there are some
other, more complex solutions needed. As long as validation is not one
of the key features of the data binding component in qooxdoo I plan
not the get it to perfection during my limited time working on the
binding itself. But I will keep that scenario in mind in my further
researches and designs.
I also thought that the validation will be done in the controller. As
i made up my mind i figured out that its not the binding from model to
its target which has a valid-state. Its the model itself which is
valid or not. So to do the validation where the data is held is a good
idea i think.
Your way of validation describes a form validation. I do have a form
widget on my task list but i did not have the time to think about it
yet.
Just keep in mind that all code that will come to the trunk currently
is designed as a basis of the upcoming data binding. So there will be
some more comfortable features in the future, also for the validation.
Best,
Martin
Am 01.12.2008 um 20:35 schrieb Petr Kobalíček:
> Hi Guilherme,
>
> this is good starting point.
>
> I have some small experiences with data validation and I must agree
> with you. I think that object should be able to be in non-valid state,
> so validation should be explicit, not implicit.
>
> My second idea is, that validation is usually done in control itself
> or more complex validation is done by server, so implementing
> validation in properties is, I think, bad step. Example can be
> situation that something is wrong in the server and you want to fix
> it. If validation is in properties and server replies you bad value,
> you can't instantiate the model object.
>
> I'm implementing validation by this way:
> - I have object that I need to validate
> - I will create validation schema (this can be json schema, or some
> kind of schema with instantiated objects describing each fields)
> - Currently my schema uses also widgets, so for example I have
> TextField, FloatField, ImageField, etc classes that I can instantiate
> and add all together to some form (not ui object). And finally I can
> call, form.validate() or validate() on individual items
>
> So, validation in models/objects itself will be always limiting factor
> in some situations that will always happen and extending this can be
> nightmare for people that wants more control or different approach.
>
> Why not to model validation like this ?:
>
> Instantiated object or dict {} that holds the data (valid or invalid,
> don't care)
> |
> Validator based on validation schemas
> |
> Input/Output
>
> And finally user interface can be like this:
>
> Instantiated object or dict {} that holds the data (valid or invalid,
> don't care)
> |
> User Interface (usually some kind of form), fields based on
> validations schemas, field layout based on different ones (grouping,
> or hand written - more control)
>
> Cheers and sorry for my limited English here
> - Petr
>
> 2008/12/1 Guilherme Aiolfi <[EMAIL PROTECTED]>:
>> Hi Martin,
>>
>> I would like to ask 2 questions about validation:
>>
>> 1) As it is now, I can't have a initial state different of a valid
>> state or
>> can I? Let's say I want the initial value of a properties to be
>> "" (empty)
>> and validate it accepting just strings with more than 2 letters. In
>> this
>> case, is the initial value validated and would throw an error or
>> the initial
>> state is treated differently?
>>
>> 2) Let's say my object has 20 properties, I would have to have 20
>> blocks of
>> try catch to highlighted all errors at once?
>>
>> I'm trying to get as close as I can of data binding functionalities
>> without
>> implementing it. I guess you already have a idea of how data
>> binding should
>> be implemented in qooxdoo. Do you mind sharing these ideas with us?
>> I'm sure
>> a lot of people are interested. I'm not talking about API or so.
>> Just some
>> general thoughts of how integrate it in qooxdoo. I'm sure others are
>> interested as well.
>>
>>
>> Thanks,
>>
>> Guilherme
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
