Stefan, Thorsten,
I actually implemented something similar to what Stefan outlined in its
first e-mail.
It works mainly like this:
system-wide configuration files (one for each relevant DB table) exist in a
central location, containing information about HTML widget rendering and JS
validation of each field; here is an example:
<table name="tasks" primary-key="task_id" check-field="title">
<field name="task_id"/>
<field name="title" caption="Titolo" write-style="width:200"
validate="nonempty"/>
<field name="priority" caption="Priorita'"
validate="nonempty, integer" validate-min="0" validate-max="10"/>
<field name="insertion_date" caption="Data di inserimento"
validate="nonempty,date"/>
<field name="expiration_date" caption="Data di scadenza"
validate="date"/>
<field name="description" caption="Descrizione"
widget="textarea"/>
<field name="project_id" caption="Progetto">
<select>
<esql:connection>
<esql:pool>w4b</esql:pool>
<esql:execute-query>
<esql:query>SELECT * FROM projects
ORDER BY name</esql:query>
<esql:results><esql:row-results><option><xsp:attribute
name="value"><esql:get-int
column="project_id"/></xsp:attribute><esql:get-string
column="name"/></option>
</esql:row-results></esql:results>
</esql:execute-query>
</esql:connection>
</select>
</field>
</table>
these are XSP files, meaning that i.e. select boxes can be populated
dynamically and even based on current user data (privileges, etc.);
you can design any number of forms which refer to these common configuration
files: simply use in your XSLs a few custom tags such as:
<w4b:form name="modulo" onSuccess="{//@referer}">
<w4b:row mode="write" table="projects"
pk-value="{project_id}">
<w4b:field src="project_id"
value="{project_id}"/>
<w4b:caption src="customer_id"/>:<w4b:field
src="customer_id" value="{customer_id}"/>
</w4b:row>
</w4b:form>
the form can refer any number of rows belonging to different tables
(multiple w4b:row inside a w4b:form).
Such forms require a few transformations (a first XSL one which detects the
tables involved, and adds <cinclude>'s to load the configuration XSP for
each table; the actual CInclude trasnformation; two final XSLs which build
all the HTML rendering and JS validation. Current renderings include text
boxes, selects (with automatic DB-bound option selection), textareas, etc.
The result is a HTML form where every field is named with a
table-pk_value-fieldname combination.
All this, after user modification, can be POSTed to a general-purpose form
processing action, which loads the required configurations from the same
files as above (PK names, etc.), writes everything to the DB, and redirects
to the desired URL (onSuccess above). To achieve more flexibility, nothing
prevents from POSTing to custom actions, one for each form, or to XSPs. The
only thing to keep is the form fields naming convention.
I built all this about one year and a half ago, and never divulgated it ;-)
because I thought it would be better to build something new related to
XForms (but using XML, not JavaBeans). Though, if you are interested in this
system and wish to use it and help me contribute something new to Cocoon, we
could join our efforts.
With my best regards,
L.
-----Messaggio originale-----
Da: Scherler, Thorsten [mailto:[EMAIL PROTECTED]
Inviato: venerdì 21 marzo 2003 13.50
A: [EMAIL PROTECTED]; Stefan Klein
Oggetto: AW: database forms
hi Stephan,
by the way are you in Spain right now?
see my answer below:
-----Ursprüngliche Nachricht-----
Von: Stefan Klein [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 21. März 2003 10:48
An: [EMAIL PROTECTED]
Betreff: Re: database forms
>Hi Thorsten,
>
>thanks for your reply. I've been pondering about your mail for a little
>while now. The xsl looks like a clever idea. A few things remain unclear to
>me:
>
>What way do you use to get the data out of the DB. SQL-Transformer?
-> No, because I need more logic (e.g. date format ...) [#1]! I use esql and
xsp!
a)cocoon.xconf.snippet
<jdbc name="D200301Insta">
<pool-controller min="5" max="10"/>
<dburl>jdbc:odbc:MyDB</dburl>
<user/>
<password/>
</jdbc>
b) sitemap.snippet
<map:match pattern="report-info-*.xml">
<map:generate type="serverpages" src="global/reports/xsp/info.xsp">
<map:parameter name="pool" value="{1}"/>
</map:generate>
<map:serialize type="xml"/>
</map:match>
c) xsp.snippet compare [#1]
<xsp:logic>...</xsp:logic>
<esql:connection>
<esql:pool><xsp:expr>GETpool</xsp:expr></esql:pool>
<esql:execute-query>
<esql:query>
select * from IDM_info_xml Where info1_date =
#<xsp:expr>timeOfDay</xsp:expr>#
</esql:query>
...
d) I call it like that:
http://localhost:8080/myapp/report-info-D200301Insta.xml?date=13.03.2003
>What do you refer to by static and variable data?
Like I stated I am working with call agent db. For me the adress and the
contact person are static because they have always the same format. I have
to write a <xsl:template match="..."/> for each of this field.
e.g.
<address>
<bname1>Weidmüller GmbH & Co.</bname1>
<bname2 />
<bname3 />
<street>P.O. Box 2807</street>
<ZIP>33058</ZIP>
<City>Paderborn</City>
<country />
<telephone_number>05252-960-350</telephone_number>
</address>
will be always formated like this and should be on a certain place within my
html-form!
Where the campaign is dynamic! I have results of the questions which are
formated like that:
<Aa>yes</Aa>
<Ab>bigger then ...</Ab>
There I have to add the question (different table). the table qusetion might
look like this <Aa>Did you receive our mailing?<Aa>. But there can be 1 to n
answers and questions.
>static=the definition of the form (as in your XML example), variable=the
>data from the DB?
No like I stated before! That was a different example that I fixed at home!
>How do you get the data back into the database? using actions, I suppose?
I am still not really certain about that! I still in development of the html
Form. I tried with SQL-Transformer and esql and both were working fine. But
I think I will have a look at actions as well. But still I first have to
really decide about the data model for the db-server.
>In your example you've only got textboxes. With listboxes (<select> in
HTML)
>it gets a bit trickier, since you'll have to get the possible values from a
>different table first. Have you got an idea for that, too?
>Maybing using XSP-ESQL?
nested esql like that:
<esql:connection>
<esql:pool>
<xsp:expr>GETpool</xsp:expr>
</esql:pool>
<esql:execute-query>
<esql:query>
select * from IDM_info_xml Where info1_date =
#<xsp:expr>timeOfDay</xsp:expr>#
</esql:query>
<esql:results>
<esql:row-results>
<xsp:logic>int xid =<esql:get-int column="info_1empf"/>;</xsp:logic>
<client>
<xsp:attribute name="id">
<esql:get-string column="Cust_No"/>
</xsp:attribute>
<address>
<bname1>
<esql:get-string column="business_name"/>
</bname1>
<bname2>
<esql:get-string column="business_name_2"/>
</bname2>
<bname3>
<esql:get-string column="business_name_3"/>
</bname3>
<street>
<esql:get-string column="address"/>
</street>
<ZIP>
<esql:get-string column="zip_code"/>
</ZIP>
<City>
<esql:get-string column="city"/>
</City>
<country>
<esql:get-string column="country"/>
</country>
<telephone_number>
<esql:get-string column="telephone_number"/>
</telephone_number>
</address>
<aps>
<esql:execute-query>
<esql:query>
select * from ap_tab where ap_id =<xsp:expr>xid</xsp:expr>
</esql:query>
<esql:results>
<esql:row-results>
<ap>
<salutation>
<esql:get-string column="salutation"/>
</salutation>
<titel>
<esql:get-string column="titel"/>
</titel>
<forename>
<esql:get-string column="forename"/>
</forename>
<department>
<esql:get-string column="department"/>
</department>
<surname>
<esql:get-string column="surname"/>
</surname>
<textension>
<esql:get-string column="direct_dial_"/>
</textension>
</ap>
</esql:row-results>
</esql:results>
<esql:no-results>
<no-results/>
</esql:no-results>
<esql:error-results/>
</esql:execute-query>
</aps>
</client>
</esql:row-results>
</esql:results>
<esql:no-results/>
<esql:error-results/>
</esql:execute-query>
</esql:connection>
What do you think?
King regards
Thorsten
Reference:
[1] http://wiki.cocoondev.org/Wiki.jsp?page=XSPTransformCustomDate
----- Original Message -----
From: "Scherler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 20, 2003 5:58 PM
Subject: Re: database forms
> Hi Stefan,
>
> I have to master the same task. I am working in a telephone marketing
> department and writing the call agent DBs. I will introduce the 3 tier
> modell and will have to get rid of my formulars (VBA).
> We have some static fields (which are always the same -> address &
> contact person) and some variable (we have different campaigns where the
> questions to ask will always be different)
>
> I thought about that:
> 1) select a db (pool) => campaign Example
> 2) get the static data with <xsl:template match="static"/>
> 3) get the variable data and put it in a different tag
> 4) use a transform to create a html form (including validation through
> JavaScript)
>
> to 4) like that xslt:
> <xsl:template match="input/*">
> <input>
> <xsl:attribute name="type"><xsl:value-of
> select="name()"/></xsl:attribute>
> <!-- -->
> <xsl:choose>
> <xsl:when test="normalize-space(text())!=''">
> <xsl:attribute name="value"><xsl:value-of
> select="normalize-space(text())"/></xsl:attribute>
> </xsl:when>
> </xsl:choose>
> </input>
> </xsl:template>
>
> with this xml:
> <form action="http://www.google.com/search"; name="f">
> <input>
> <hidden name="ie">UTF-8</hidden>
> <hidden name="oe">UTF-8</hidden>
> <hidden name="hl">eng</hidden>
> <text name="q" maxLength="256" size="55"/>
> <submit name="btnG">Google-Search</submit>
> </input>
> <script>document.f.q.focus();</script>
> </form>
>
> ...
>
> King regards
> Thorsten
>
> Stefan Klein wrote:
>
> >Hi all,
> >
> >I am looking for the quickest way to write database forms. It is
something
> >that I will be doing thousands of times, so the goal is to find some
really
> >efficient way.
> >
> >Ideally it would look something like:
> ><table>table name</table> - selects the table
> >
> ><inputbox ref="field" /> - a simple input field bound to a field in
the
> >table
> >
> ><listbox ref="field" values="table.field" entries="table.field"/> - a
> >listbox bound to a field, entries defines the options visible to the
user,
> >values defines what is internally stored in the field. obviously the
table
> >would be the same (useful for foreign key entries)
> >
> ><checkbox ...
> >
> >
> >The form would be populated automatically with the database values (the
> >current record being selected by a request parameter) and update the
values
> >on submit.
> >
> >What I've been pondering about for quite a while now is what would be the
> >best way to implement this in cocoon.
> >
> >I looked into the "departments and employees"-tutorial delivered with
> >cocoon2, which is quite close to what I'd like, but still not it. For
> >example I don't like having to define listboxes and populate the form by
> >using separate esql-statements. What data to fill into the form should
> >already be specified in the form definition.
> >My first idea was to start from there and implement a logicsheet that
would
> >allow me to define tags like the ones above.
> >
> >Then I looked into xmlforms and liked them a lot. However:
> >1. I am still looking for a tag reference. Maybe someone can help out.
> >2. I am still not entirely sure how they might help me. Surely it would
be
> >possible to write a JavaBean that accesses the database, but doing that
> >every time again is not the simplification I am looking for. Is there a
way
> >to reference database fields directly from the forms?
> >
> >
> >Basically, I would be very grateful for any kind of hint you can offer on
> >how to use xmlforms for this or on other ways of accomplishing the task
> >(maybe there would even be ways to take the database description and
> >generate a form from it?). I am quite stuck for ideas, but it seems a
> >standard job so I am sure many people have already found sufficient ways
to
> >do it.
> >
> >
> >Thanks in advance
> >Stefan
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
