Re: database forms
The problem with the logicsheet is the missing validation. I didn't include it, but it could be done: a) by the FormValidator Action and the corresponding logicsheet b) doing JavaScript validation (just as you proposed in your first message) The problem with the XMLFormXindice approach is the custom programming. If I compare your reference I find the ArtistAction.java that I have to edit and fill that with my fields. But like I stated before what will happen if I don't know this fields. I don't understand this paragraph. Could you help me? In XML-Forms you have to write customary actions anyway to define the control flow between the form pages. That's a bit more work, but a lot more powerful, too. I am a bit confused, Stefan, do you want to use Xindice to store the options? Do you consider Xindice only as tool or do you want to use it? No, I don't want to use Xindice. I am using MySQL. I just found the tutorial an interesting read. What they are doing is use an XML-File instead of a JavaBean as datamodel in the XMLForm. The model is then populated from and written to a Xindice database. I was wondering whether it might be possible to do the same with a MySQL database, automatically generating the XML-model, using it as datastore and afterwards write its contents back to the database. 4) Thought: DTD/Schema approach (in the spirit of DB2XML) Some time ago I found this tool http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/index.html DB2XML. The nice thing on it that the dtd will be generate on the fly. Using that this could give us the validation input. I admit it is quite similar to the Xindice approach. But the problem with Xindice is (in my opinion) the validation of dynamic data. The question remain whether DTD is enough or do we have to use schemas? I don't get this either, I am afraid. Please help, with examples if possible. Yesterday popped up another interesting thread on the list: Cocoon-based Database Administration. They make reference to some tools that provide persistence between Java objects and RDBMS. I've started to look into it. Hibernate looks easy to use and useful. This might be a way to use XMLForms using JavaBeans and then right the bean straight back to the database. I'll go on reading and will be back. Stefan AGAINST THE WAR! King regards Thorsten Any advice is highly appreciated. Stefan AGAINST THE WAR! Against Cesar Bush and the war! - 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]
RE: database forms
Hi Stefan, hi Lorenzo, The solution to go with an action seems to be quite practical because both of you have proposed that. While I had a glance on the book Professional XML Schema I was think that our validation is existent but quite rudimental. 1) The select problem xsl:template match=dbf:listbox esql:connection esql:poolxsp:exprdbfpool/xsp:expr/esql:pool esql:execute-query esql:querySELECT xsl:value-of select=@entries-column/ FROM xsl:value-of select=@entries-table//esql:query esql:results select esql:row-results option esql:get-string column=name/ /option /esql:row-results /select /esql:results /esql:execute-query /esql:connection /xsl:template note: dbfpool is a variable that might be set by a sitemap-parameter Then use it in an xsp-page like: dbf:listbox entries-table=author entries-column=name/ That get's you in one line a listbox filled with all the names in the author-table. Defining another parameter like ref=authorid you could then bind it to a field in the book table. I had the same approach when I was coding the selectoption - block. I think that is your (Stefan) solution of The select problem 2) The Lorenzo approach 2. Reply to Lorenzo That is quite close to what I was talking about. However I don't like having to write an extensive configuration file. For example, I don't like having to define listboxes using a block of esql every time. I'd very much prefer something like I outlined above. Besides I don't need to use the same form elements again and again in different contexts (which your system seems to be very useful for), it's more about being able to write one single form really quickly and directly without loads of support code (like the esql) around it. Stefan got a point there! Your example (Lorenzo) is very good and advanced. The only problem was mentioned by Stefan. If we use your example for further development we have to simplify the structure. Especially if I keep in mind that I have a block of question were I do not know the name. 3) XMLFormXindice 3. More thoughts: XMLForms I'd been looking into XMLForms before and reading Lorenzo's note at the end of his last message I took another deeper look. I found a quite interesting tutorial that describes how to replace the form model (currently incorporated by a JavaBean) by a model defined by an XML-File that is linked to an XIndice database: http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice I was wondering whether this would be worth a thought in this case as well, since XML may be generated from any ordinary relational database, too. You would generate an XML-Model from the database, use it to keep the form data and in the end send the data back to the database. That would also have the advantage that you could build multi-page forms to gather the data for one table (for example one form to gather the book data and a separate one to select the author from a long list) and then in the end send it to the database altogether (otherwise you would have to store the book data without the author being filled in which wouldn't be possible, cause the author field can't be empty...) So I am currently pondering about what to go for: an XSP logicsheet approach as outlined above - that might be easier to implement right now - or try to use XMLForms which would be a lot more flexible. The problem with the logicsheet is the missing validation. The problem with the XMLFormXindice approach is the custom programming. If I compare your reference I find the ArtistAction.java that I have to edit and fill that with my fields. But like I stated before what will happen if I don't know this fields. I am a bit confused, Stefan, do you want to use Xindice to store the options? Do you consider Xindice only as tool or do you want to use it? 4) Thought: DTD/Schema approach (in the spirit of DB2XML) Some time ago I found this tool http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/index.html DB2XML. The nice thing on it that the dtd will be generate on the fly. Using that this could give us the validation input. I admit it is quite similar to the Xindice approach. But the problem with Xindice is (in my opinion) the validation of dynamic data. The question remain whether DTD is enough or do we have to use schemas? King regards Thorsten Any advice is highly appreciated. Stefan AGAINST THE WAR! Against Cesar Bush and the war! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
Re: database forms
Hi Thorsten, Lorenzo 1. reply to Thorsten: 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: [...] I'm not sure we undertand each other right there. The problem was not to get all the recordsets from a table (say books) that are related to another one (say authors), but to implement listboxes in an easy way. (e.g. a column in table books contains a foreign key from table authors, then in a form you'll want a listbox to easily select one author). I've been thinking a bit myself and came up with the following: Define a XSP-logicsheet with namespace e.g. dbf. Snippet: xsl:template match=dbf:listbox esql:connection esql:poolxsp:exprdbfpool/xsp:expr/esql:pool esql:execute-query esql:querySELECT xsl:value-of select=@entries-column/ FROM xsl:value-of select=@entries-table//esql:query esql:results select esql:row-results option esql:get-string column=name/ /option /esql:row-results /select /esql:results /esql:execute-query /esql:connection /xsl:template note: dbfpool is a variable that might be set by a sitemap-parameter Then use it in an xsp-page like: dbf:listbox entries-table=author entries-column=name/ That get's you in one line a listbox filled with all the names in the author-table. Defining another parameter like ref=authorid you could then bind it to a field in the book table. 2. Reply to Lorenzo That is quite close to what I was talking about. However I don't like having to write an extensive configuration file. For example, I don't like having to define listboxes using a block of esql every time. I'd very much prefer something like I outlined above. Besides I don't need to use the same form elements again and again in different contexts (which your system seems to be very useful for), it's more about being able to write one single form really quickly and directly without loads of support code (like the esql) around it. 3. More thoughts: XMLForms I'd been looking into XMLForms before and reading Lorenzo's note at the end of his last message I took another deeper look. I found a quite interesting tutorial that describes how to replace the form model (currently incorporated by a JavaBean) by a model defined by an XML-File that is linked to an XIndice database: http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice I was wondering whether this would be worth a thought in this case as well, since XML may be generated from any ordinary relational database, too. You would generate an XML-Model from the database, use it to keep the form data and in the end send the data back to the database. That would also have the advantage that you could build multi-page forms to gather the data for one table (for example one form to gather the book data and a separate one to select the author from a long list) and then in the end send it to the database altogether (otherwise you would have to store the book data without the author being filled in which wouldn't be possible, cause the author field can't be empty...) So I am currently pondering about what to go for: an XSP logicsheet approach as outlined above - that might be easier to implement right now - or try to use XMLForms which would be a lot more flexible. Any advice is highly appreciated. Stefan AGAINST THE WAR! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
R: database forms
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:poolw4b/esql:pool
esql:execute-query
esql:querySELECT * FROM projects
ORDER BY name/esql:query
esql:resultsesql:row-resultsoptionxsp:attribute
name=valueesql:get-int
column=project_id//xsp:attributeesql: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/
dburljdbc: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:poolxsp:exprGETpool/xsp:expr/esql:pool
esql:execute-query
esql:query
select * from IDM_info_xml Where
Re: R: database forms
Lorenzo De Sio wrote:
[...]
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.
[...]
ok, I haven't understood every line you wrote but I think I got the picture.
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.
ok please send me the files (DTD, XML) and how to use them because you
are refering to
w4b:... I need to know what that is.
king regards
Thorsten
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:poolw4b/esql:pool
esql:execute-query
esql:querySELECT * FROM projects
ORDER BY name/esql:query
esql:resultsesql:row-resultsoptionxsp:attribute
name=valueesql:get-int
column=project_id//xsp:attributeesql: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
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/
dburljdbc: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:poolxsp:exprGETpool/xsp:expr/esql:pool
esql:execute-query
esql:query
select * from IDM_info_xml Where info1_date = #xsp:exprtimeOfDay/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
bname1Weidmüller GmbH Co./bname1
bname2 /
bname3 /
streetP.O. Box 2807/street
ZIP33058/ZIP
CityPaderborn/City
country /
telephone_number05252-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:
Aayes/Aa
Abbigger then .../Ab
There I have to add the question (different table). the table qusetion might look like
this AaDid 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:exprGETpool/xsp:expr
/esql:pool
esql:execute-query
esql:query
select * from IDM_info_xml Where info1_date = #xsp:exprtimeOfDay/xsp:expr#
/esql:query
esql:results
esql:row-results
xsp:logicint 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:exprxid/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
database forms
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: tabletable 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]
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=typexsl:value-of
select=name()//xsl:attribute
!-- --
xsl:for-each select=@*
xsl:attribute name={name()}xsl:value-of
select=.//xsl:attribute
/xsl:for-each
xsl:choose
xsl:when test=normalize-space(text())!=''
xsl:attribute name=valuexsl: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=ieUTF-8/hidden
hidden name=oeUTF-8/hidden
hidden name=hleng/hidden
text name=q maxLength=256 size=55/
submit name=btnGGoogle-Search/submit
/input
scriptdocument.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:
tabletable 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]
