Hi Martin,
yes, you are right that I talkem mainly about form validation:)
Explanation:
Form validation is very similar to model validation for me. In form
its probably everything that is changeable in model, so if you want to
validate something, you will do it in the form (or some external
validator) and you set validated data to the model.
What I'm talking about server side validation is fact, that in some
cases, valid model in the client can be non-valid on the server. Let
me explain it:
- In ajax applications you are usually working with some data. Model
is usually table and instance of model is usually row, connections
between data is usually created using selectbox, listbox and similar
widgets. Imagine that you have selected valid category for the product
and that category was deleted by somebody else. When saving data to
the server, it should be able to tell you where is the problem and in
client you should be able to load new category data.
- This was example from my life, it's rare, but it's possible :)
Cheers
- Petr
2008/12/2 Martin Wittemann <[EMAIL PROTECTED]>:
> 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
>
-------------------------------------------------------------------------
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
