Hello Petr,
I talked with Fabian about that topic and we both agreed that we keep
the solution link this.
But if i come to the part where the server interaction is addressed in
data binding, I will take a closer look at the validation under that
circumstances.
Best,
Martin
Am 08.12.2008 um 11:28 schrieb Petr Kobalíček:
> Hi Martin,
>
> we talked with Guilherme about validation, because we are using some
> kind of DIY validation stuff we wrote:)
>
> But let's go to the problem. The validation you presented should be
> categorized as implicit validation based on function/built-in schema,
> etc. And I think that validation should be explicit, because
> developers needs more control about it. Implicit validation have also
> problems, what about checking if field can contain some value ? This
> will be hard to do in implicit validation schema, but easy in explicit
> one.
>
> Good databinding is not easy task, I think that you will rewrite it
> few times :-)
>
> Cheers
> - Petr
>
> 2008/12/8 Martin Wittemann <[EMAIL PROTECTED]>:
>> Hi Petr,
>>
>> i can see your Problem with the current solution. I will remember
>> that
>> when i come back to validation on a higher level or in data binding
>> itself. As you can see in the code, this is experimental so there can
>> be changes. :)
>>
>> Best,
>> Martin
>>
>>
>> Am 02.12.2008 um 18:54 schrieb Petr Kobalíček:
>>
>>> 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
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
>> Nevada.
>> The future of the web can't happen without you. Join us at MIX09
>> to help
>> pave the way to the Next Web now. Learn more and register at
>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> Nevada.
> The future of the web can't happen without you. Join us at MIX09 to
> help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
