cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <m...@digikartta.net>
Subject Re: data binding
Date Wed, 28 Mar 2012 08:36:06 GMT

 Yep,
 something like that if simplifying. And the table that holds the actual 
 data has columns for each data type. And each field value in the form 
 will create its own row in that table. So in any circumstance, we don't 
 have to add any columns in the table structure whether we have form with 
 one field or with 100 fields.

 - mika -

 On Wed, 28 Mar 2012 11:27:59 +0300, Andre Juffer <andre.juffer@oulu.fi> 
 wrote:
> OK, thus each data TYPE decides the form element to be used?
>
> On 03/28/2012 11:23 AM, mika@digikartta.net wrote:
>>
>> Hi André,
>> form element themselves are changing based upon data that is 
>> received
>>
>> Forms have a number of fields defined in the db, UI-controls are 
>> defined in the db, even the validation restrictions will be defined in 
>> the db. So this is highly dynamical system.
>> Basically the administrator has tools to create form (and other) 
>> types, tools to create instances based on those types and tools for 
>> creating hierarcial structure.
>> So a form type or an instance of it can be constructed of any number 
>> of different elements. There is no theoretical limit for the number of 
>> different form types.
>>
>> - mika -
>>
>> On Wed, 28 Mar 2012 10:48:40 +0300, Andre Juffer 
>> <andre.juffer@oulu.fi> wrote:
>>> Hi Mika,
>>>
>>> not sure if I completely understood your question. By stating "my
>>> forms are created dynamically based on data in database" you mean 
>>> to
>>> say that form elements values constitute the dynamical aspect of 
>>> the
>>> form (thus the data) or do you mean to say the form element 
>>> themselves
>>> are changing based upon data that is received. Thus, suppose you 
>>> would
>>> be dealing with a form for car information. The form has e.g. form
>>> element for entering the license plate number. This form element 
>>> could
>>> be say a simple input form element of type text for one set of 
>>> data,
>>> while for another data set the same input is now an text area?
>>>
>>> Best,
>>> André
>>>
>>> On 03/28/2012 10:34 AM, mika@digikartta.net wrote:
>>>>
>>>> Suggesting to myself:
>>>> Modular Database Actions?
>>>> Right?
>>>>
>>>> On Tue, 27 Mar 2012 22:50:56 +0300, Mika M Lehtonen 
>>>> <mika@digikartta.net> wrote:
>>>>> Hi,
>>>>> what is the right and the proper way of inserting  form data to
>>>>> database table (PostgreSQL)?
>>>>> What makes this more "interesting" is that instead of horizontal 
>>>>> data
>>>>> in table, the data is stored in a vertical manner because of the
>>>>> highly dynamic nature of the application and the relation model. 
>>>>> That
>>>>> is, my forms are created dynamically based on data in database. 
>>>>> In the
>>>>> same way, the values shoud be stored vertically, because the the 
>>>>> table
>>>>> structure would otherwise have to vary based on form types and
>>>>> eventually I would have hundreds of different tables.
>>>>>
>>>>> I have done some testing with XSP and ESQL in order to retrieve 
>>>>> my
>>>>> forms. That works fine, although if I have understood right, 
>>>>> XSPs'
>>>>> aren't recommended to use, am I right?
>>>>>
>>>>> But now I would have to insert form values to another table
>>>>> vertically (different columns for different datatypes). How 
>>>>> should I
>>>>> approahce the challenge? Any thoughts?
>>>>>
>>>>> Sorry if I am asking entirely obvious questions. I don't have 
>>>>> such a
>>>>> long experience with the Cocoon. Testing things now with the 2.11 
>>>>> and
>>>>> am going to shift to 2.2, even 3.0 some day later or sooner. Also
>>>>> coming more from .NET side.. forgive me..
>>>>>
>>>>> - mika -
>>>>>
>>>>>
>>>>>
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>>
>>>>
>>>>
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>>
>>
>>
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message