The way I typically do things is to rely on Spring and Hibernate, the
latter for mapping between the tables and domain entities. Postgresql is
employed for SQL databases. Spring of course for creating objects, but
also for transaction boundaries. I have transferred all (but one) C2
applications to C3, and work always with facades. The database
transactions start and end at the facades, while REST resources receives
requests and call upon facades to fulfill the requests. I return JSON or
XML to the client and the GUI is based upon the Dojo toolkit. I do not
use XSP or ESQL.
The reason for using facades is that one can very easily test everything
outside of cocoon (whatever version one uses) before preparing a
Cocoon-based web application. The facades returns DTOs with getters
(return Strings) to build the response in JSON or XML (or anything
else). Building the response with Cocoon's sitemap concepts is extremely
convenient. At no point one ever has to write code in Java for producing
XML or JSON (well, I wrote a simple JSON transformer). In my mind, this
is far more easier accomplished with C3 pipelines using XSLT and string
templates.
In your case, one could return a JSON object with actual data and data
type names, the latter is them employed to create the correct forms with
Dojo (or any other framework) on the client. I do not think that one
should do this on the server. If you use Hibernate, you would need
decide upon the (domain) entities to which your table correspond
(actually one should do this the other way around).
On 03/28/2012 11:36 AM, m...@digikartta.net wrote:
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.juf...@oulu.fi> wrote:
OK, thus each data TYPE decides the form element to be used?
On 03/28/2012 11:23 AM, m...@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.juf...@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, m...@digikartta.net wrote:
Suggesting to myself:
Modular Database Actions?
Right?
On Tue, 27 Mar 2012 22:50:56 +0300, Mika M Lehtonen
<m...@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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juf...@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StrucBioCat | WWW: www.strucbiocat.oulu.fi
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
