generic forms handling - looking for solution hints

[christian.ruess]

Hi - 

I'm looking for a solution for a form handling problem. I'm beginner to cocoon 
and would appreciate 
any hint.

I extract an xml fragment like the following from a relational database. The 
structure is 
not static.


asset
id /
title /
description /
keywords
keyword
id/
word/
/keyword
/keywords
/asset

I would like to present the user a html form with checkboxes for each element 
in the structure. The generation of this form via xslt is easy and no problem.
To make the form elements (checkboxes) unique, I use 
   xsl:number level=multiple...
to name the checkbox fields.

The problematic part for me is the form submission. I would like to get an xml 
struct 
like...

asset read=true
id read=false /
title read=true /
description read=true /
keywords read=true
keyword read=true
id read=false/
word read=true /
/keyword
/keywords
/asset

with the attribute values set according to the checkboxes. I would like to 
write this 
XML fragment as a blob back to the database.

How could this be accomplished with cocoon in a generic way - the 
structure/elements
are dynamic and may change. 
Writing an action with a DOM tree of the structure seems not very effective to 
me.
Writing a custom transformer which fills in the form values to the source 
structure 
seems to be one solution, but how could I store the complete XML fragment in 
the database 
when using a SAXTransformer.
Is there a more elegant solution?

Tanks - regards -
Christian





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Dynamically generated forms with dynamically generatedverification

[Mathias Wiegard]

Hi,
I have to generate dynamically a form out of the structure Information of
some XML-data (it's SCORM for learning metadata). Is there a way to verify
dynamically the data entries when submitting the form? If yes, how does it
function or where can I get further informations?
Best regards,
Matze


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

generating woody forms without xml-definition

[andi]

Hi,

I'd like to use the woody form framework, but as the
forms i want to create base on data from a database i
thought about creating the FormDefinition inside my
javacode (transformer). this seems more performant
than dynamically creating the xml-definiton for the
form which is then dom-parsed and turned in a
formdefinition ...

anyone any ideas ?!

thanks.

andi


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

PDF Forms and XSL:FO

[cocoon user]

Is it possible to generate PDF forms (editable fields within PDF) using XSL:FO?Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

Re: PDF Forms and XSL:FO

[Tony Collen]

On Thu, 3 Apr 2003, cocoon user wrote:

 Is it possible to generate PDF forms (editable fields within PDF) using XSL:FO?

I think it depends on the XSLFO spec, as well as FOP (the current fo2pdf
serializer).  I seem to recall a discussion earlier about FOP not having
any forms support currently.  It's a shame because Acrobat 5 files can
post XML to a remote server over HTTP, which could open a whole new world
for Cocoon and forms handling.



Tony


 --
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/
--


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PDF Forms and XSL:FO

[J.Pietschmann]

cocoon user wrote:
Is it possible to generate PDF forms (editable fields within PDF) using XSL:FO?
No. Check the spec for details.

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: database forms

[Stefan Klein]

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

[Scherler, Thorsten]

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

[Stefan Klein]

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

[Lorenzo De Sio]

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

[webmaster]

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

[Scherler, Thorsten]

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

[Stefan Klein]

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

[Scherler]

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]

Forms

[Ines Robbers]

Hello list,

We want to use Cocoon for our forms (application forms etc.).
It should be something like a form center.
What is the best approach to realise this?
Are there any examples on the net?

Many thanks!

Ines 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Forms

[Antonio Gallardo]

Hi:

Please be a little more specific. The forms will be filled online or just
printed by your customer and sended back to you via.

Best Regards,

Antonio Gallardo

Ines Robbers dijo:
 Hello list,

 We want to use Cocoon for our forms (application forms etc.).
 It should be something like a form center.
 What is the best approach to realise this?
 Are there any examples on the net?

 Many thanks!

 Ines



 - 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: Forms

[Ines Robbers]

Dear Antonio,

These forms should be available online as well as being printable.
Depending on the form it can either be filled in and send back online or
in case of serious issues such as an application the form should be
printable so that people can send it back by post.
Only in the future online applications will be allowed when the digital
signature has been established.

The current format of the forms are pdf (example:
http://www.uni-potsdam.de/u/studium/formulare/a_wechsel_studiengang.pdf)

I guess it would be nice to have versions in XHTML and PDF at least.

The problem is that I have no idea how Cocoon handles forms and how I
should go about this.

I'd appreciate your help!

Ines


Antonio Gallardo:
* Please be a little more specific. The forms will be filled 
* online or just printed by your customer and sended back to you via.

 
Ines Robbers:
*  We want to use Cocoon for our forms (application forms etc.). It 
*  should be something like a form center. What is the best 
*  approach to realise this? Are there any examples on the net?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Forms

[Antonio Gallardo]

The (X)HTML forms can be easily done using Cocoon. You can use the
FormValidator Transformer to Validate the forms.

If you wish database support you can also make use of Modular Database
Actions.

On the other hand. I have no experience in writting XSL-FO forms. I dont
know if we can use the PDF Serializer to create PDF Forms. :-(

I already use XSL-FO but not to create forms.

Best Regards,

Antonio Gallardo

Ines Robbers dijo:
 Dear Antonio,

 These forms should be available online as well as being printable.
 Depending on the form it can either be filled in and send back online or
 in case of serious issues such as an application the form should be
 printable so that people can send it back by post.
 Only in the future online applications will be allowed when the digital
 signature has been established.

 The current format of the forms are pdf (example:
 http://www.uni-potsdam.de/u/studium/formulare/a_wechsel_studiengang.pdf)

 I guess it would be nice to have versions in XHTML and PDF at least.

 The problem is that I have no idea how Cocoon handles forms and how I
 should go about this.

 I'd appreciate your help!

 Ines


 Antonio Gallardo:
 * Please be a little more specific. The forms will be filled
 * online or just printed by your customer and sended back to you via.


 Ines Robbers:
 *  We want to use Cocoon for our forms (application forms etc.). It  *
 should be something like a form center. What is the best
 *  approach to realise this? Are there any examples on the net?



 - 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: multi-part forms

[Christian Haul]

On 20.Feb.2003 -- 04:58 PM, David Kavanagh wrote:
 I'm looking over documentation on cocoon and can't find anything that 
 deals with handling multi-part forms. Specificly, I'd like to be able to 
 upload an XLS file, use POI to convert to XML, then mess with it a bit. 
 So, as far as I can tell, there are two part I might have to write, the 
 multi-part form handling, and the XSL-XML part. Two questions about 

On multipart forms see
http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithCocoon
in addition, there's an upload example included with the database
samples. 

 that... looks lke XSP is used to process forms. Is there anything I can 

There are a lot actions related to forms around. Have a look at the
XMLForms stuff for example. Don't know how that behaves with uploads,
though.

 put in a pipeline that will turn form parameters into XML? (some 

See request generator.

 generator?) Should something that converts XSL-XML be a generator? I 
 know POI generates SAX events, which means it can be a generator, but, 
 how would it get the multi-part form data on the input side? It would be 
 nice not to need a temporary file...

One - not necessarily good - way would be to write an input module
that calls POI, operates on another module (i.e. raw request
parameters) and returns a DOM. But since you plan to use XSL on the
output (?) it might not make sense.

Perhaps the best way is indeed to write a generator and call it in an
extra pipeline.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

multi-part forms

[David Kavanagh]

I'm looking over documentation on cocoon and can't find anything that 
deals with handling multi-part forms. Specificly, I'd like to be able to 
upload an XLS file, use POI to convert to XML, then mess with it a bit. 
So, as far as I can tell, there are two part I might have to write, the 
multi-part form handling, and the XSL-XML part. Two questions about 
that... looks lke XSP is used to process forms. Is there anything I can 
put in a pipeline that will turn form parameters into XML? (some 
generator?) Should something that converts XSL-XML be a generator? I 
know POI generates SAX events, which means it can be a generator, but, 
how would it get the multi-part form data on the input side? It would be 
nice not to need a temporary file...
Thanks in advance,
David


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

[article] xml.com: XML Forms, Web Services and Apache Cocoon

[Ivelin Ivanov]

XML Forms, Web Services and Apache Cocoon
http://www.xml.com/pub/a/2003/01/29/cocoon-xforms.html?page=last#thread


-=Ivelin=-


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: XMLForms Versus Traditional HTML forms.

[Geoff Howard]

not a problem - i figured you were in anger management counseling to deal
with that last screw up of mine ... ;)

Geoff

 -Original Message-
 From: Christian Haul [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, January 29, 2003 3:31 AM
 To: [EMAIL PROTECTED]
 Subject: Re: XMLForms Versus Traditional HTML forms.


 On 29.Jan.2003 -- 12:29 AM, Geoff Howard wrote:
  Modular in this case refers to the use of input modules.
 Christian Haul
  on the list appears to be the author/resident guru on both.

 *blush*

  As a side note, I recently worked with Chris to make some trivial
  modifications that allow multipart form file uploads to
 populate db blobs
  automatically.

 Sorry, that I haven't gotten back to you on this but I have been
 banging my head with some other stuff. Anyway, I'm almost done with it
 and your sample will show up shortly in CVS.

   Chris.
 --
 C h r i s t i a n   H a u l
 [EMAIL PROTECTED]
 fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]





-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Greetings. I would like to know what people favor 
using. 

By my, admittedly limited, knowledge, the 
traditional HTML forms will still work with cocoon as the request will still 
have access to the data. Alternatively if I use XMLForms, I'm not sure how much 
learning effort Id have to invest. I read the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.htmland 
am still a but unclear how I define how the form will be rendered. Does the user 
have control over that at all? If I use HTML forms then I would be imbedding a 
form into an XSL transform which would print out the form for the user. 


So basically I am asking what reasons are there to 
use XMLForms. 

-- Robert

Re: XMLForms Versus Traditional HTML forms.

[Niclas Hedhman]

On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
 Greetings. I would like to know what people favor using.

 By my, admittedly limited, knowledge, the traditional HTML forms will still
 work with cocoon as the request will still have access to the data.
 Alternatively if I use XMLForms, I'm not sure how much learning effort Id
 have to invest. I read the XMLForm tutorial at
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I see 
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic on 
the posted request in XSL (XSL is Turing complete, right?), without writing 
any Java/XSP code. For some people (those who know XSL better than Java) that 
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Well actually I already have some generators running to fetch data from the
database. I have put that data in manually. Now I want to do it dynamically.
Simplicity wise I should use conventional forms, but I am not sure if that
is the right way to do it.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 4:39 AM
Subject: Re: XMLForms Versus Traditional HTML forms.


On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
 Greetings. I would like to know what people favor using.

 By my, admittedly limited, knowledge, the traditional HTML forms will still
 work with cocoon as the request will still have access to the data.
 Alternatively if I use XMLForms, I'm not sure how much learning effort Id
 have to invest. I read the XMLForm tutorial at
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java) that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

AW: XMLForms Versus Traditional HTML forms.

[Kirchhoff, Lars]

But why you need then cocoon for? If you just use traditional html
isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
just use jsp or something similar?

The main advantage of cocoon and xmlform for me is still to create
a xml document, which then can be transformed through the pipeline
in nearly every possible format. This means creating applications or 
websites, which can serve multiple devices. 

Especially for xmlforms  there is a strong seperation of concerns, 
which in the first moment and for small application is a bit to 
much, but helps to divide the programming of the actual dataflow and
business logic from the presentation layer and keeps the code 
manageable. I don't like to mix up any program code with tags from 
either xml or html. That's why I use and tried xmlform and don't
feel comfortable with xsp.

Of course you can transform the xmlform tags to html form tags, 
as long as there are not to many browser out, which are 
understanding xforms, which are still in draft.

BTW does anybody know an reference implementation of an xforms 
browser?

regards
Lars 


 -Ursprüngliche Nachricht-
 Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Gesendet: Mittwoch, 29. Januar 2003 11:50
 An: [EMAIL PROTECTED]
 Betreff: Re: XMLForms Versus Traditional HTML forms.
 
 
 Well actually I already have some generators running to fetch 
 data from the
 database. I have put that data in manually. Now I want to do 
 it dynamically.
 Simplicity wise I should use conventional forms, but I am 
 not sure if that
 is the right way to do it.
 
 -- Robert
 
 - Original Message -
 From: Niclas Hedhman [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 4:39 AM
 Subject: Re: XMLForms Versus Traditional HTML forms.
 
 
 On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
  Greetings. I would like to know what people favor using.
 
  By my, admittedly limited, knowledge, the traditional HTML 
 forms will still
  work with cocoon as the request will still have access to the data.
  Alternatively if I use XMLForms, I'm not sure how much 
 learning effort Id
  have to invest. I read the XMLForm tutorial at
  
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
m-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I
see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java)
that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Lets not lump cocoon to XMLForms or no XMLForms. Nor should we pick out any
other one feature of cocoon and say that if you don't use this feature you
shouldn't use cocoon. Nor should we say something like if you aren't going
pure XML XSL XSP that you shouldn't use cocoon. Cocoon is a toolkit and you
should pick those tools appropriate to your use. I chose cocoon over JSP
because I get the multi format content and clear separation of logic and
presentation. To me, a form is presentation.

As for multi-content, I could easily write a transform that converts things
to WML based forms. Its a matter of taste. Its also a matter of necessity. I
have already spent too long working on the presentation layer to my project
and I don't care to invest another month. I am not merely a learner but a
professional with tight deadlines. I'm not sure its worth the extra effort.
But the not sure is why I posted the question. If I was sure, I wouldn't
have posted.

Another thing is if it is in draft than that would be one reason for me to do
it the old way. Real business applications require something that works. That
isn't always the same thing as something that is cool.

-- Robert

- Original Message -
From: Kirchhoff, Lars [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 5:09 AM
Subject: AW: XMLForms Versus Traditional HTML forms.


But why you need then cocoon for? If you just use traditional html
isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
just use jsp or something similar?

The main advantage of cocoon and xmlform for me is still to create
a xml document, which then can be transformed through the pipeline
in nearly every possible format. This means creating applications or
websites, which can serve multiple devices.

Especially for xmlforms  there is a strong seperation of concerns,
which in the first moment and for small application is a bit to
much, but helps to divide the programming of the actual dataflow and
business logic from the presentation layer and keeps the code
manageable. I don't like to mix up any program code with tags from
either xml or html. That's why I use and tried xmlform and don't
feel comfortable with xsp.

Of course you can transform the xmlform tags to html form tags,
as long as there are not to many browser out, which are
understanding xforms, which are still in draft.

BTW does anybody know an reference implementation of an xforms
browser?

regards
Lars


 -Ursprüngliche Nachricht-
 Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Gesendet: Mittwoch, 29. Januar 2003 11:50
 An: [EMAIL PROTECTED]
 Betreff: Re: XMLForms Versus Traditional HTML forms.


 Well actually I already have some generators running to fetch
 data from the
 database. I have put that data in manually. Now I want to do
 it dynamically.
 Simplicity wise I should use conventional forms, but I am
 not sure if that
 is the right way to do it.

 -- Robert

 - Original Message -
 From: Niclas Hedhman [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 4:39 AM
 Subject: Re: XMLForms Versus Traditional HTML forms.


 On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
  Greetings. I would like to know what people favor using.
 
  By my, admittedly limited, knowledge, the traditional HTML
 forms will still
  work with cocoon as the request will still have access to the data.
  Alternatively if I use XMLForms, I'm not sure how much
 learning effort Id
  have to invest. I read the XMLForm tutorial at
 
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
m-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I
see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java)
that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e

RE: XMLForms Versus Traditional HTML forms.

[Geoff Howard]

 -Original Message-
 From: Robert Simmons [mailto:[EMAIL PROTECTED]]

 As for multi-content, I could easily write a transform that
 converts things
 to WML based forms. Its a matter of taste. Its also a matter of
 necessity. I
 have already spent too long working on the presentation layer to
 my project
 and I don't care to invest another month. I am not merely a learner but a
 professional with tight deadlines. I'm not sure its worth the
 extra effort.
 But the not sure is why I posted the question. If I was sure, I wouldn't
 have posted.

One potential upside is the fact that XMLForms uses beans for the datamodel
(I think).  that being the case, I have assumed there'd be a way to let
ejb's fill that role (which based on past discussions I assume you're using
here) and you'd get the binding to/from the form for free as you can in jsp.


 Another thing is if it is in draft than that would be one reason
 for me to do
 it the old way. Real business applications require something that
 works. That
 isn't always the same thing as something that is cool.

I've not used xmlform yet because of the draft status and the time to
learn - same issues you raise.  Looks quite promising though, especially if
the bean hunch pans out.



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: XMLForms Versus Traditional HTML forms.

[Geoff Howard]

also there's supposed to be support for validation, error handling, and
persistence across calls, right?

 -Original Message-
 From: Geoff Howard [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, January 28, 2003 11:59 PM
 To: [EMAIL PROTECTED]
 Subject: RE: XMLForms Versus Traditional HTML forms.


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 
  As for multi-content, I could easily write a transform that
  converts things
  to WML based forms. Its a matter of taste. Its also a matter of
  necessity. I
  have already spent too long working on the presentation layer to
  my project
  and I don't care to invest another month. I am not merely a
 learner but a
  professional with tight deadlines. I'm not sure its worth the
  extra effort.
  But the not sure is why I posted the question. If I was sure,
 I wouldn't
  have posted.

 One potential upside is the fact that XMLForms uses beans for the
 datamodel
 (I think).  that being the case, I have assumed there'd be a way to let
 ejb's fill that role (which based on past discussions I assume
 you're using
 here) and you'd get the binding to/from the form for free as you
 can in jsp.

 
  Another thing is if it is in draft than that would be one reason
  for me to do
  it the old way. Real business applications require something that
  works. That
  isn't always the same thing as something that is cool.

 I've not used xmlform yet because of the draft status and the time to
 learn - same issues you raise.  Looks quite promising though,
 especially if
 the bean hunch pans out.



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]





-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Well, if you want my advice stay away from entity beans. They are evil in the
extreme. As for forms being in draft, that bothers me. I do, however, have
allot of actions I need to write and some common method of outputting the
forms automatically based on the command being run would be interesting to
me. I might take a hybrid approach here.

What Id like to have happen is that a user decides to execute a command which
hits a generator with the name of the command and any initialization
parameters. Then the generator spits out a document containing the structure
of needed information from the form. Then the style sheets take over and
render the forms and then the user can submit them. To do this I might just
borrow the XML form namespace and have the generator spit out valid XML form
documents.

Just thinking out loud.

-- Robert


- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 5:59 AM
Subject: RE: XMLForms Versus Traditional HTML forms.


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 
  As for multi-content, I could easily write a transform that
  converts things
  to WML based forms. Its a matter of taste. Its also a matter of
  necessity. I
  have already spent too long working on the presentation layer to
  my project
  and I don't care to invest another month. I am not merely a learner but a
  professional with tight deadlines. I'm not sure its worth the
  extra effort.
  But the not sure is why I posted the question. If I was sure, I
wouldn't
  have posted.

 One potential upside is the fact that XMLForms uses beans for the datamodel
 (I think).  that being the case, I have assumed there'd be a way to let
 ejb's fill that role (which based on past discussions I assume you're using
 here) and you'd get the binding to/from the form for free as you can in
jsp.

 
  Another thing is if it is in draft than that would be one reason
  for me to do
  it the old way. Real business applications require something that
  works. That
  isn't always the same thing as something that is cool.

 I've not used xmlform yet because of the draft status and the time to
 learn - same issues you raise.  Looks quite promising though, especially if
 the bean hunch pans out.



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Theoretically, but if you were trying to deliver an action driven system,
this would be difficult. You would have to validate inside the pipeline and
that would be problematic for a number of reasons. You would have to write
some sort of custom validator. The problem here is that configuration is
being done at the sitemap level and that is resource intensive. IT would be
much more efficient if you could drop in a set of beans, have a Java class
read them via introspection and then generate forms based upon the needs of
that command. Then you would have a command driven architecture that would be
quickly adaptable. all you have to do is drop in another command (a bean
object) and viola, a new form gets spit out the far end. I will screw with
this and see if I can get it to work. Call it reflexive form generation =)

-- Robert

- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:06 AM
Subject: RE: XMLForms Versus Traditional HTML forms.


 also there's supposed to be support for validation, error handling, and
 persistence across calls, right?

  -Original Message-
  From: Geoff Howard [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, January 28, 2003 11:59 PM
  To: [EMAIL PROTECTED]
  Subject: RE: XMLForms Versus Traditional HTML forms.
 
 
   -Original Message-
   From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  
   As for multi-content, I could easily write a transform that
   converts things
   to WML based forms. Its a matter of taste. Its also a matter of
   necessity. I
   have already spent too long working on the presentation layer to
   my project
   and I don't care to invest another month. I am not merely a
  learner but a
   professional with tight deadlines. I'm not sure its worth the
   extra effort.
   But the not sure is why I posted the question. If I was sure,
  I wouldn't
   have posted.
 
  One potential upside is the fact that XMLForms uses beans for the
  datamodel
  (I think).  that being the case, I have assumed there'd be a way to let
  ejb's fill that role (which based on past discussions I assume
  you're using
  here) and you'd get the binding to/from the form for free as you
  can in jsp.
 
  
   Another thing is if it is in draft than that would be one reason
   for me to do
   it the old way. Real business applications require something that
   works. That
   isn't always the same thing as something that is cool.
 
  I've not used xmlform yet because of the draft status and the time to
  learn - same issues you raise.  Looks quite promising though,
  especially if
  the bean hunch pans out.
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Hmm .. I cant seem to even find the samples on my cocoon installation. Are
they not in the current binary distribution ?

-- Robert

- Original Message -
From: Kirchhoff, Lars [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 5:09 AM
Subject: AW: XMLForms Versus Traditional HTML forms.


But why you need then cocoon for? If you just use traditional html
isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
just use jsp or something similar?

The main advantage of cocoon and xmlform for me is still to create
a xml document, which then can be transformed through the pipeline
in nearly every possible format. This means creating applications or
websites, which can serve multiple devices.

Especially for xmlforms  there is a strong seperation of concerns,
which in the first moment and for small application is a bit to
much, but helps to divide the programming of the actual dataflow and
business logic from the presentation layer and keeps the code
manageable. I don't like to mix up any program code with tags from
either xml or html. That's why I use and tried xmlform and don't
feel comfortable with xsp.

Of course you can transform the xmlform tags to html form tags,
as long as there are not to many browser out, which are
understanding xforms, which are still in draft.

BTW does anybody know an reference implementation of an xforms
browser?

regards
Lars


 -Ursprüngliche Nachricht-
 Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Gesendet: Mittwoch, 29. Januar 2003 11:50
 An: [EMAIL PROTECTED]
 Betreff: Re: XMLForms Versus Traditional HTML forms.


 Well actually I already have some generators running to fetch
 data from the
 database. I have put that data in manually. Now I want to do
 it dynamically.
 Simplicity wise I should use conventional forms, but I am
 not sure if that
 is the right way to do it.

 -- Robert

 - Original Message -
 From: Niclas Hedhman [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 4:39 AM
 Subject: Re: XMLForms Versus Traditional HTML forms.


 On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
  Greetings. I would like to know what people favor using.
 
  By my, admittedly limited, knowledge, the traditional HTML
 forms will still
  work with cocoon as the request will still have access to the data.
  Alternatively if I use XMLForms, I'm not sure how much
 learning effort Id
  have to invest. I read the XMLForm tutorial at
 
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
m-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I
see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java)
that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: XMLForms Versus Traditional HTML forms.

[Geoff Howard]

 As for forms being in draft, that bothers me.

Don't rely on my word here - that is my memory of what I learned (and
someone just said that tonight, too right?) looking into xmlform again about
2-3 months ago, so things may have moved on.

 I do, however, have
 allot of actions I need to write and some common method of outputting the
 forms automatically based on the command being run would be interesting to
 me. I might take a hybrid approach here.

I have recently been converted to the modular database actions which may
provide some inspiration and groundwork for actions hitting session beans
(assuming that's what you meant).  One xml config file with db table
structure and a few other tidbits handles my insert, update and deletes (for
simple cases) with no coding.  I think they're in 2.0.4 but not positive.
Modular in this case refers to the use of input modules.  Christian Haul
on the list appears to be the author/resident guru on both.

As a side note, I recently worked with Chris to make some trivial
modifications that allow multipart form file uploads to populate db blobs
automatically.


 What Id like to have happen is that a user decides to execute a
 command which
 hits a generator with the name of the command and any initialization
 parameters. Then the generator spits out a document containing
 the structure
 of needed information from the form. Then the style sheets take over and
 render the forms and then the user can submit them. To do this I
 might just
 borrow the XML form namespace and have the generator spit out
 valid XML form
 documents.

This sounds great - is there no overlap with the current stuff?

Geoff



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Niclas Hedhman]

On Wednesday 29 January 2003 13:01, Robert Simmons wrote:
 IT would be
 much more efficient if you could drop in a set of beans, have a Java class
 read them via introspection and then generate forms based upon the needs of
 that command. Then you would have a command driven architecture that would
 be quickly adaptable. all you have to do is drop in another command (a bean
 object) and viola, a new form gets spit out the far end. I will screw with
 this and see if I can get it to work. Call it reflexive form generation

You need to bring this to cocoon-dev mailing list, I think...

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

If there is any overlap, I'm not aware of it. Cocoon is XML centric and not
Java centric. What I'm thinking of is a way to drive XML with Java. So if you
had a bean like ...


public class ChangeAge extends Command {
  private int age;
  private String name;

 // getter and setters.
}

Than a java class would spit out the following:

xf:form id=ChangeAge view= action=ChangeAge.html

xf:captionRegistration/xf:caption

error
  xf:violations class=error/
/error

xf:textbox ref=/name
xf:captionName:/xf:caption
xf:violations class=error/
/xf:textbox

xf:textbox ref=/age
xf:captionage/xf:caption
xf:helpNew age/xf:help
xf:violations class=error/
/xf:textbox

 xf:submit id=submit class=button
  xf:captionChange Age/xf:caption
 /xf:submit

  /xf:form

And then the user could use XSLT to dynamically transform the form into what
they wanted.  The problem is that the sitemap could no longer be effectively
used to configure individual actions because they would largely depend upon
what actions exist in the object model of the beans. But I do have a few
ideas. ;)

-- Robert

- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:29 AM
Subject: RE: XMLForms Versus Traditional HTML forms.


  As for forms being in draft, that bothers me.

 Don't rely on my word here - that is my memory of what I learned (and
 someone just said that tonight, too right?) looking into xmlform again
about
 2-3 months ago, so things may have moved on.

  I do, however, have
  allot of actions I need to write and some common method of outputting the
  forms automatically based on the command being run would be interesting
to
  me. I might take a hybrid approach here.

 I have recently been converted to the modular database actions which may
 provide some inspiration and groundwork for actions hitting session beans
 (assuming that's what you meant).  One xml config file with db table
 structure and a few other tidbits handles my insert, update and deletes
(for
 simple cases) with no coding.  I think they're in 2.0.4 but not positive.
 Modular in this case refers to the use of input modules.  Christian Haul
 on the list appears to be the author/resident guru on both.

 As a side note, I recently worked with Chris to make some trivial
 modifications that allow multipart form file uploads to populate db blobs
 automatically.

 
  What Id like to have happen is that a user decides to execute a
  command which
  hits a generator with the name of the command and any initialization
  parameters. Then the generator spits out a document containing
  the structure
  of needed information from the form. Then the style sheets take over and
  render the forms and then the user can submit them. To do this I
  might just
  borrow the XML form namespace and have the generator spit out
  valid XML form
  documents.

 This sounds great - is there no overlap with the current stuff?

 Geoff



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Niclas Hedhman]

On Wednesday 29 January 2003 13:11, Robert Simmons wrote:
 Hmm .. I cant seem to even find the samples on my cocoon installation. Are
 they not in the current binary distribution ?

Provided you have dropped the cocoon.war into $TOMCAT_HOME/webapps, you should 
find samples in;

$TOMCAT_HOME/webapps/cocoon/samples/


Niclas

 -- Robert

 - Original Message -
 From: Kirchhoff, Lars [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 5:09 AM
 Subject: AW: XMLForms Versus Traditional HTML forms.


 But why you need then cocoon for? If you just use traditional html
 isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
 just use jsp or something similar?

 The main advantage of cocoon and xmlform for me is still to create
 a xml document, which then can be transformed through the pipeline
 in nearly every possible format. This means creating applications or
 websites, which can serve multiple devices.

 Especially for xmlforms  there is a strong seperation of concerns,
 which in the first moment and for small application is a bit to
 much, but helps to divide the programming of the actual dataflow and
 business logic from the presentation layer and keeps the code
 manageable. I don't like to mix up any program code with tags from
 either xml or html. That's why I use and tried xmlform and don't
 feel comfortable with xsp.

 Of course you can transform the xmlform tags to html form tags,
 as long as there are not to many browser out, which are
 understanding xforms, which are still in draft.

 BTW does anybody know an reference implementation of an xforms
 browser?

 regards
 Lars

  -Ursprüngliche Nachricht-
  Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Gesendet: Mittwoch, 29. Januar 2003 11:50
  An: [EMAIL PROTECTED]
  Betreff: Re: XMLForms Versus Traditional HTML forms.
 
 
  Well actually I already have some generators running to fetch
  data from the
  database. I have put that data in manually. Now I want to do
  it dynamically.
  Simplicity wise I should use conventional forms, but I am
  not sure if that
  is the right way to do it.
 
  -- Robert
 
  - Original Message -
  From: Niclas Hedhman [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Wednesday, January 29, 2003 4:39 AM
  Subject: Re: XMLForms Versus Traditional HTML forms.
 
  On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
   Greetings. I would like to know what people favor using.
  
   By my, admittedly limited, knowledge, the traditional HTML
 
  forms will still
 
   work with cocoon as the request will still have access to the data.
   Alternatively if I use XMLForms, I'm not sure how much
 
  learning effort Id
 
   have to invest. I read the XMLForm tutorial at
 
  http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor

 m-wizard-3.ht

 ml and am still a but unclear how I define how the form will be rendered.
  Does the user have control over that at all? If I use HTML forms then I
  would be imbedding a form into an XSL transform which would print out the
  form for the user.

 Slightly beyond my experience (I also use 'conventional' approach), but I
 see
 it as;

 1. The XMLForm generator creates a XML document of the POST request.
 2. You can aggregate that with other XML documents, static or dynamic.
 3. Feed that to the transformer(s).
 4. Output

 Meaning, the main advantage would be that you can do a fair amount of logic
 on
 the posted request in XSL (XSL is Turing complete, right?), without writing
 any Java/XSP code. For some people (those who know XSL better than Java)
 that
 is more power with less hazzle.

 Niclas

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Yeah .. well I meant the XMLForms samples. And I still haven't found those.
The other samples I found easily.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:25 AM
Subject: Re: XMLForms Versus Traditional HTML forms.


On Wednesday 29 January 2003 13:11, Robert Simmons wrote:
 Hmm .. I cant seem to even find the samples on my cocoon installation. Are
 they not in the current binary distribution ?

Provided you have dropped the cocoon.war into $TOMCAT_HOME/webapps, you
should
find samples in;

$TOMCAT_HOME/webapps/cocoon/samples/


Niclas

 -- Robert

 - Original Message -
 From: Kirchhoff, Lars [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 5:09 AM
 Subject: AW: XMLForms Versus Traditional HTML forms.


 But why you need then cocoon for? If you just use traditional html
 isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
 just use jsp or something similar?

 The main advantage of cocoon and xmlform for me is still to create
 a xml document, which then can be transformed through the pipeline
 in nearly every possible format. This means creating applications or
 websites, which can serve multiple devices.

 Especially for xmlforms  there is a strong seperation of concerns,
 which in the first moment and for small application is a bit to
 much, but helps to divide the programming of the actual dataflow and
 business logic from the presentation layer and keeps the code
 manageable. I don't like to mix up any program code with tags from
 either xml or html. That's why I use and tried xmlform and don't
 feel comfortable with xsp.

 Of course you can transform the xmlform tags to html form tags,
 as long as there are not to many browser out, which are
 understanding xforms, which are still in draft.

 BTW does anybody know an reference implementation of an xforms
 browser?

 regards
 Lars

  -Ursprüngliche Nachricht-
  Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Gesendet: Mittwoch, 29. Januar 2003 11:50
  An: [EMAIL PROTECTED]
  Betreff: Re: XMLForms Versus Traditional HTML forms.
 
 
  Well actually I already have some generators running to fetch
  data from the
  database. I have put that data in manually. Now I want to do
  it dynamically.
  Simplicity wise I should use conventional forms, but I am
  not sure if that
  is the right way to do it.
 
  -- Robert
 
  - Original Message -
  From: Niclas Hedhman [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Wednesday, January 29, 2003 4:39 AM
  Subject: Re: XMLForms Versus Traditional HTML forms.
 
  On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
   Greetings. I would like to know what people favor using.
  
   By my, admittedly limited, knowledge, the traditional HTML
 
  forms will still
 
   work with cocoon as the request will still have access to the data.
   Alternatively if I use XMLForms, I'm not sure how much
 
  learning effort Id
 
   have to invest. I read the XMLForm tutorial at
 
  http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor

 m-wizard-3.ht

 ml and am still a but unclear how I define how the form will be rendered.
  Does the user have control over that at all? If I use HTML forms then I
  would be imbedding a form into an XSL transform which would print out the
  form for the user.

 Slightly beyond my experience (I also use 'conventional' approach), but I
 see
 it as;

 1. The XMLForm generator creates a XML document of the POST request.
 2. You can aggregate that with other XML documents, static or dynamic.
 3. Feed that to the transformer(s).
 4. Output

 Meaning, the main advantage would be that you can do a fair amount of logic
 on
 the posted request in XSL (XSL is Turing complete, right?), without writing
 any Java/XSP code. For some people (those who know XSL better than Java)
 that
 is more power with less hazzle.

 Niclas

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 -
 Please check that your

sending forms does not work

[Wolle]

Hi Guys!

I made a registration-form for the portal-framework. If I want to sent the
data the form will not be processed by IE and Netscpape. Nothing happens
if I press the submit-button.

Everything works fine if i use Opera.

I am really confused! Has anybody made the same experience?

Bye for now

Wolfgang



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: FORMS

[Josema Alonso]

Sure. I have tried different ways but using it directly from the Action with
a helper class seems to be the easiest solution by now.

I'm too busy this week, please give me a few days and I'll prepare and send
something to Wiki for example.

Btw, I read your message about loading content into a Node a few days ago.
You recommended using a Container. Since I didn't know about them I'm using
DOM Nodes  directly and it's working just fine. Would it be a better
approach to use the container?

Best.


-Mensaje original-
De: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
Enviado el: miércoles, 18 de diciembre de 2002 5:01
Para: [EMAIL PROTECTED]
Asunto: Re: FORMS



Josema,

Many people requested an example of XMLForm with Xindice.
Can you submit some source code or even better a HOW-TO doc?

Thank you,

Ivelin



- Original Message -
From: Josema Alonso [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 9:59 AM
Subject: Re: FORMS


FORMSHello,
Yes, you must download 2.1 from CVS and build it. Information on how to get
it and build it step by step is available at:
http://xml.apache.org/cocoon/installing/index.html

Then you could test the XMLForm samples. I've been succesfully using them
for a few months backed by a Xindice respository.

Best.

ps: please, not HTML next time, thanks.


- Original Message -
From: Carlos González
To: [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 3:34 PM
Subject: FORMS


Hi All,
I am very interested in something that would let me fill some forms, and
bind these form data to xml.
I am evaluating products like Altova's Authentic Web Edition (very
expensive, 30k USD per 50 concurrent users), but the functionality, except
the client behavior that allows to edit the whole xml before sending it to
the server, is near from what I'm looking for.
I have seen Cocoon Forms, and it seems that is what I need.
Could you give me some suggestions, hints, ..., whatever.
Also, Cocoon forms page says that Cocoon 2.1 must be downloaded in order to
test the example at url http://localhost:8080/cocoon/samples/xmlform/, but I
am unable to get this version neither in the download page nor in the cvs.
Where could I find this package?. Is it present in other releases, or only
in 2.1?
Thank you very much in advance.
Carlos.


Carlos Gonzalez-Cadenas
Software Architect
e-xtendnow



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

FORMS

[Carlos González]

Title: FORMS





Hi All, 


I am very interested in something that would let me fill some forms, and bind these form data to xml.


I am evaluating products like Altova's Authentic Web Edition (very expensive, 30k USD per 50 concurrent users), but the functionality, except the client behavior that allows to edit the whole xml before sending it to the server, is near from what I'm looking for.

I have seen Cocoon Forms, and it seems that is what I need.


Could you give me some suggestions, hints, ..., whatever.


Also, Cocoon forms page says that Cocoon 2.1 must be downloaded in order to test the example at url http://localhost:8080/cocoon/samples/xmlform/, but I am unable to get this version neither in the download page nor in the cvs.

Where could I find this package?. Is it present in other releases, or only in 2.1?


Thank you very much in advance.


Carlos.



Carlos Gonzalez-Cadenas
Software Architect
e-xtendnow

Re: FORMS

[Josema Alonso]

FORMSHello,
Yes, you must download 2.1 from CVS and build it. Information on how to get
it and build it step by step is available at:
http://xml.apache.org/cocoon/installing/index.html

Then you could test the XMLForm samples. I've been succesfully using them
for a few months backed by a Xindice respository.

Best.

ps: please, not HTML next time, thanks.


- Original Message -
From: Carlos González
To: [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 3:34 PM
Subject: FORMS


Hi All,
I am very interested in something that would let me fill some forms, and
bind these form data to xml.
I am evaluating products like Altova's Authentic Web Edition (very
expensive, 30k USD per 50 concurrent users), but the functionality, except
the client behavior that allows to edit the whole xml before sending it to
the server, is near from what I'm looking for.
I have seen Cocoon Forms, and it seems that is what I need.
Could you give me some suggestions, hints, ..., whatever.
Also, Cocoon forms page says that Cocoon 2.1 must be downloaded in order to
test the example at url http://localhost:8080/cocoon/samples/xmlform/, but I
am unable to get this version neither in the download page nor in the cvs.
Where could I find this package?. Is it present in other releases, or only
in 2.1?
Thank you very much in advance.
Carlos.


Carlos Gonzalez-Cadenas
Software Architect
e-xtendnow



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: FORMS

[Ivelin Ivanov]

Title: FORMS




XMLForm is not supported in version before 2.1.

You can download 2.1 here:
http://cvs.apache.org/snapshots/xml-cocoon2/


  - Original Message - 
  From: 
  Carlos 
  González 
  To: [EMAIL PROTECTED] 
  
  Sent: Tuesday, December 17, 2002 8:34 
  AM
  Subject: FORMS
  
  Hi All, 
  I am very interested in something that would let me fill some 
  forms, and bind these form data to xml. 
  I am evaluating products like Altova's Authentic Web Edition 
  (very expensive, 30k USD per 50 concurrent users), but the functionality, 
  except the client behavior that allows to edit the whole xml before sending it 
  to the server, is near from what I'm looking for.
  I have seen Cocoon Forms, and it seems that is what I 
  need. 
  Could you give me some suggestions, hints, ..., 
  whatever. 
  Also, Cocoon forms page says that Cocoon 2.1 must be 
  downloaded in order to test the example at url http://localhost:8080/cocoon/samples/xmlform/, but I am 
  unable to get this version neither in the download page nor in the 
  cvs.
  Where could I find this package?. Is it present in other 
  releases, or only in 2.1? 
  Thank you very much in advance. 
  Carlos. 
  Carlos Gonzalez-Cadenas Software 
  Architect e-xtendnow 

Re: FORMS

[Ivelin Ivanov]

Josema,

Many people requested an example of XMLForm with Xindice.
Can you submit some source code or even better a HOW-TO doc?

Thank you,

Ivelin



- Original Message -
From: Josema Alonso [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 9:59 AM
Subject: Re: FORMS


FORMSHello,
Yes, you must download 2.1 from CVS and build it. Information on how to get
it and build it step by step is available at:
http://xml.apache.org/cocoon/installing/index.html

Then you could test the XMLForm samples. I've been succesfully using them
for a few months backed by a Xindice respository.

Best.

ps: please, not HTML next time, thanks.


- Original Message -
From: Carlos González
To: [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 3:34 PM
Subject: FORMS


Hi All,
I am very interested in something that would let me fill some forms, and
bind these form data to xml.
I am evaluating products like Altova's Authentic Web Edition (very
expensive, 30k USD per 50 concurrent users), but the functionality, except
the client behavior that allows to edit the whole xml before sending it to
the server, is near from what I'm looking for.
I have seen Cocoon Forms, and it seems that is what I need.
Could you give me some suggestions, hints, ..., whatever.
Also, Cocoon forms page says that Cocoon 2.1 must be downloaded in order to
test the example at url http://localhost:8080/cocoon/samples/xmlform/, but I
am unable to get this version neither in the download page nor in the cvs.
Where could I find this package?. Is it present in other releases, or only
in 2.1?
Thank you very much in advance.
Carlos.


Carlos Gonzalez-Cadenas
Software Architect
e-xtendnow



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Forms

[Christian Haul]

On 13.Nov.2002 -- 06:12 PM, Jos? Moreira wrote:
 hello, in my company we use apache+ php + postgre and we spend most of the
 time building table-manipulation forms ( for insert,update,delete,etc)
 
 is it possible to ( in cocoon ) create standard actions ( or else) to
 manipulate a xml file containing the data to be manipulated like the keys,
 key fields and what type of html input to atatch ( text, memo, radio, ... )
 and more ...
 
 then we whould have a xml file for every dataset needed in a website and 4
 'actions' (insert/view/delete/update)called when the situation demanded ?

Consider yourself lucky, those actions already exist in cocoon. See
the modular database actions (docs provide all info).

You need to provide the form and a database description for
that. Since both, form and description, can be cocoon resources, you
could even generate them from your database meta data.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Forms and XML

[Tuomo L]

Hi all,

I need to build a system, which will include a lot of forms for the users
to feed data into the system. The system should also have the possibility
to search data using different kinds of search forms.

I read the how-to about the XMLForms, and I think it's a great way to do
things. One thing I'm not quite clear about: What is the role of the
beans? Do I have to write a bean
for every single form in my system, or is there a way to hold the data in
one bean? Or some session context perhaps? I mean, in this project, it
should be possible for people who
don't
know Java to add forms easilly to the system, with validation
instructions they can specify. Also, how do I dump the data collected to
the database actions, or mailer action?

This should also be possible: When user is selecting a value from a select
list, and the value he/she is looking for isn't there, the same user could
switch to another form, add a value (to db for example), and then
switch
back to the original form where the item he/she was looking for would now
be available for select. Has anyone done this?

Thanks in advance,
Tuomo


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: session timeout and XML Forms

[Ivelin Ivanov]

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 07, 2002 11:52 AM
Subject: session timeout and XML Forms



Hello,

   i have the following problem:

   I set my session timeout in the web.xml to 1 minute (only to try),
   but as soon as I am in my registration flow I am never loosing
   the session.
   I am using XML Forms with map:parameter name=xmlform-scope
value=session /
   If I change the scope to request the session times out after one
minute, but not
   if its set to session.
   Is there always a new session crated in the session scope


[Ivelin] Yes, the framework will automatically create a new session if one
is not available, along with a new data model instance.
This behaviour is similar to Struts' implementation.




 or is it using its own session?
   Do I have to set the timeout then  differently?

   Thanx again for any help,


   miHam


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

session timeout and XML Forms

[michael_hampel]

Hello,

 i have the following problem:

 I set my session timeout in the web.xml to 1 minute (only to try),
 but as soon as I am in my registration flow I am never loosing
 the session.
 I am using XML Forms with map:parameter name=xmlform-scope value=session /
 If I change the scope to request the session times out after one minute, but not
 if its set to session.
 Is there always a new session crated in the session scope or is it using its own session?
 Do I have to set the timeout then differently?

 Thanx again for any help,


 miHam

XML Forms without JavaBeans

[Alex Romayev]

Hello,

I've looked through XMLForm documentation, but haven't really read it in 
detail yet. Quick question before I went off in the wrong direction.

I would like to build forms which whould save information to XML files 
rather than the database. I would also like to use 
SourceWritingTransformer for that. Would XMLForms framework still be 
applicable, i.e. do I have to use JavaBeans or can a pipeline segment with 
SourceWritingTrasformer be plugged in?

Thanks,
-Alex

Creating PDF for dynamic queried result after processing in XSP using forms

[Sreenivasan N.]

Hi ALL

1.i am using this part of the sitemap for generating an xsp .

map:match pattern=xsp/*
 map:generate src=docs/samples/xsp/{1}.xsp type=serverpages/
 map:transform src=stylesheets/dynamic-page2html.xsl
 /map:transform
 map:serialize type=html/
/map:match

the xsp generated will be a html form with two list boxes populated with 
data from the oracle database(using the query already in the xsp) and a 
submit query button.
On clicking the submit button after selecting values from the list boxes , 
a query is dynamically executed based on these values and the result is 
shown in html format.
Till now it works fine..
will it be possible to show the final result in xml or pdf format.

2.

  i have an UploadAction.java file.But i don't know how to add it as a 
class file and invoke it as an Action sitemap component.

Regards
Sreenivasan.







Attitudes are much more important than aptitudes.
Nothing is impossible for a willing heart

Sreenivasan N.
Sony SARD
Ext 5816

Email. [EMAIL PROTECTED]
Per: [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: forms

[Barbara Post]

Actions were invented after XSPs, and their field / way of control is
different. Actions set visible control in the sitemap (structured here).

Look for former thread partially entitled avoid use of xsp or something
similar. [EMAIL PROTECTED]

So you'll see what best fits your needs...

Babs
- Original Message -
From: Gabor Bartha [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 19, 2002 10:24 AM
Subject: forms


 Hi,

 I'm new in xml, xsl, ... I try to understand how to make forms with
 post/get methods, ... but I begin to implicate the solutions.

 1. I can make an xml, and an xsl (for the xml) to make a html form and
 post it to the other html. In this case I have to insert the
 map:parameter name=use-request-parameters value=true/ row in the
 sitemap, then I can access to the posted parameter from another xsl.
 This is clear.

 2. There are actions. As I read I can use actions to post, obtain posted
 parameters, ... When have I use actions? eg for databeses

 3. There is the request 2.0 logicsheet (xmlns:xsp-request=...)

 Can anybody explain the differences between these methods, and when can
 they be user and for what?

 many thanks,
 Gabor


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Question on forms

[Hahn Kurt (CHA)]

Hi,
I'm trying to build a form in Cocoon.

My first question: I'm a complete newbie concerning forms (meaning passing
the parameter in GET/POST requests and all that stuff), but I'm getting to
know Cocoon better. Should I first work my way through forms in a neutral
environnement, or is it not more difficult to start writing them directly in
Cocoon, using xsp and actions etc.?

My second: In the pipeline below (which I copied from the samples), I
couldn't figure out what the parameter name view-source does. In the
transformer documentation, there's no reference to this one. Can anybody
help me with this?

Thanks in advance

map:match pattern=forms/*
 map:generate type=serverpages src=docs/samples/forms/{1}.xsp/
 map:transform src=stylesheets/dynamic-page2html.xsl
map:parameter name=view-source
value=docs/samples/forms/{1}.xsp/
 /map:transform
 map:serialize/
   /map:match

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Forms Failed

[Richard]

Hi Guys,

Attached with this email is form and my 
sitemap.
The problem is I am able to load the form into the 
browser but after clicking on the Submit button
it still gives me back the form.

Thanks


New-Employee.xsp
Description: Binary data


sitemap.xmap
Description: Binary data

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Fw: Forms Failed

[Richard]

HI Guys,

Ithink Ihave foundtheerror. After clickicking on save employee the 
browser now displays the
Confirm-Employee.xml. the problem is it is not 
saving any records

any idea???

thanks!


- Original Message - 
From: Richard 
To: Hiloliddin Karimov ; [EMAIL PROTECTED] 
Sent: Friday, August 02, 2002 2:34 PM
Subject: Forms Failed

Hi Guys,

Attached with this email is form and my 
sitemap.
The problem is I am able to load the form into the 
browser but after clicking on the Submit button
it still gives me back the form.

Thanks



-Please 
check that your question has not already been answered in theFAQ 
before posting. http://xml.apache.org/cocoon/faq/index.htmlTo 
unsubscribe, e-mail: 
[EMAIL PROTECTED]For additional commands, 
e-mail: [EMAIL PROTECTED]


New-Employee.xsp
Description: Binary data


sitemap.xmap
Description: Binary data

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Forms

[Ivelin Ivanov]

Are you using C2.0.3 or C2.1?

In the latter case, you may want to look here:
http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html


  - Original Message - 
  From: 
  Richard 
  
  To: [EMAIL PROTECTED] 
  
  Sent: Thursday, August 01, 2002 12:53 
  AM
  Subject: Forms 
  
  
  Hi Guys,
  
  Good Day!
  
  On http://xml.apache.org/cocoon/tutorial/tutorial-develop-webapp.html
  
  It is written that...
  The website 
  specification is missing the tags for form building, we will provide an 
  example here: 
  
  Where can I find the "tags for form building" syntax and description?
  
  in the codes... 
  
  form 
  handler="create-dept.html" 
  p You can 
  create a department by typing in 
  the name and 
  pressing the "submit" button. 
  /p 
  p Name: 
  text name="name" size="30" 
  required="true"/ 
  /p submit 
  name="Create Department"/ 
  note * These 
  fields are required. 
  /note/form
  
  How does the handler="create-dept.html" attribute work?
  
  The note element is not requiredby 
  the FormValidatorAction right? 
  This element were used onlyby the xsl 
  transformation.
  
  Thanks!

Re: Forms

[Richard]

Thanks Ivelin,

I got C2.1 on Tomcat 4.0.4 and jdk 
1.3


  - Original Message - 
  From: 
  Ivelin Ivanov 
  
  To: Richard ; [EMAIL PROTECTED] 
  
  Sent: Thursday, August 01, 2002 9:06 
  PM
  Subject: Re: Forms 
  
  
  Are you using C2.0.3 or C2.1?
  
  In the latter case, you may want to look here:
  http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html
  
  
- Original Message - 
From: 
Richard 

To: [EMAIL PROTECTED] 

Sent: Thursday, August 01, 2002 12:53 
AM
Subject: Forms 


Hi Guys,

Good Day!

On http://xml.apache.org/cocoon/tutorial/tutorial-develop-webapp.html

It is written that...
The website 
specification is missing the tags for form building, we will provide an 
example here: 


Where can I find the "tags for form building" syntax and description?

in the codes... 


form 
handler="create-dept.html" 
p You can 
create a department by typing in 
the name and 
pressing the "submit" button. 
/p 
p Name: 
text name="name" size="30" 
required="true"/ 
/p submit 
name="Create Department"/ 
note * 
These fields are required. 
/note/form

How does the handler="create-dept.html" attribute work?

The note element is not 
requiredby the FormValidatorAction right? 
This element were used onlyby the xsl 
transformation.

Thanks!

Forms

[Richard]

Hi Guys,

Good Day!

On http://xml.apache.org/cocoon/tutorial/tutorial-develop-webapp.html

It is written that...
The website specification 
is missing the tags for form building, we will provide an example 
here: 

Where can I find the "tags for form building" syntax and description?

in the codes... 

form 
handler="create-dept.html" 
p You can 
create a department by typing in 
the name and pressing 
the "submit" button. 
/p 
p Name: 
text name="name" size="30" 
required="true"/ 
/p submit name="Create 
Department"/ 
note * These 
fields are required. 
/note/form

How does the handler="create-dept.html" attribute work?

The note element is not requiredby 
the FormValidatorAction right? 
This element were used onlyby the xsl 
transformation.

Thanks!

XML Forms and i18n

[michael_hampel]

Hello,

   first I want to thank you for your great help in the last days.
   We have solved the problem now with your proposed
   solution: tagging the xml with a stylesheet.
   Our xml now looks like this:

xsl:template match=document
  document
xsl:apply-templates/
  /document
/xsl:template

xsl:template match=xf:violation
  xf:violation
i18n:text
  xsl:value-of select=./
/i18n:text
  /xf:violation
/xsl:template

xsl:template match=node() priority=-1
  xsl:copy
xsl:copy-of select=@*/
xsl:apply-templates/
  /xsl:copy
/xsl:template

Thanx again,

 miHam


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: XML Forms and i18n

[Piroumian Konstantin]

 From: [EMAIL PROTECTED] 
 
 Hello,
 
first I want to thank you for your great help in the last days.
We have solved the problem now with your proposed
solution: tagging the xml with a stylesheet.

Great to hear that.

Would you let us know when your application is ready and if't available
online? 
A small howto on multilingual XMLForm would be also fine.

Konstantin

Our xml now looks like this:
 
 xsl:template match=document
   document
 xsl:apply-templates/
   /document
 /xsl:template
 
 xsl:template match=xf:violation
   xf:violation
 i18n:text
   xsl:value-of select=./
 /i18n:text
   /xf:violation
 /xsl:template
 
 xsl:template match=node() priority=-1
   xsl:copy
 xsl:copy-of select=@*/
 xsl:apply-templates/
   /xsl:copy
 /xsl:template
 
 Thanx again,
 
  miHam
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

XML Forms and i18n

[michael_hampel]

Hello,

I was just trying to change the XMLFormTransformer to add an
i18n:text tag, when the Transformer is dealing with violations.
I tried the following in the startElementViolations method:

  1.) I tried to add the tag like this:

  // render violation tag
super.startElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION, attributes );
 // set message
   String startInter = i18n:text;
String endInter = /i18n:text;
String vm = nextViolation.getMessage();
   String result = startInter + vm + endInter;
super.characters( result.toCharArray(), 0, result.length());

super.endElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION);

  2.) and like this:

  INTER_PREFIX = i18n
  TAG_VIOLATION=text
  Here I thought that I could create the i18n tag like the
xf:validation tag is created

  // render violation tag
super.startElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION, attributes );
AttributesImpl emptyAttributes = new AttributesImpl();
super.startElement(null, null, INTER_PREFIX + : + TAG_INTER,
emptyAttributes);
String vm = nextViolation.getMessage();
super.characters( vm.toCharArray(), 0, vm.length());
super.endElement(null, null, INTER_PREFIX + : + TAG_INTER);
super.endElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION);

Both ways did not work. In the first case I got an error message like this:
  i18n:texterror_message/i18n:text
but it was not translated - so I think that there were no real tags.
The second case was ignored completely  - according to the log.

Maybe somebody can advise if I do this at the right place, or if I should
try somewhere else
or how the Transformer works regarding the super.startElement() - if this
is the way how
to add a new element to the xml or if this is done differently?

thanx again for any help,

miHam


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Antwort: Re: Antwort: RE: XML Forms and i18n

[Ivelin Ivanov]

The fact that nested tags in assert messages aren't copied is a known bug in
the SchematronValidator. It uses jxptr.getValue() of the assert( or rule)
element which in turn returns the text() value of the XML element.
A text() value of an XML element does not include it's subelements.
Dmitri had a suggestion for fixing it.
Dmitri, can you please post your solution again since I lost it.

Interested to look into it?


Another option would be to write a trivial XSLT which acts against the
XMLForm namespace and replaces all xf:violation tags with i18n:text

xslt:template match=xf:violation
  i18n:text
value-of select=.
  /i18n:text
/xf:violation


then you can include this stylesheet in the pipeline. It acts independent
from the form document.



Ivelin




- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 26, 2002 8:50 AM
Subject: Antwort: Re: Antwort: RE: XML Forms and i18n


Hello,

   Yes, I tried this, but I don´t think that the i18n tags are copied with
the error message, as
   the translation is not working.
   I have the internationalisation running with the XML-form example.
   There it is quite easy , as you only have to alter the wizard2html.xml.
   In there you are doing something like
  ifxf:violation
  value-of select =.

   I only wrap this with
  i18n:textvalue-of select=./i18n:text

   and run the i18n Transformer. This works fine.
   The problem is, that in the xml I have I would have to write a new
stylesheet for
   every xml file again to find the xf:violation tags as each xml file
differs a lot
   from another.
   To avoid this I tried to find an other solution.
   I of course agree that adding the i18n tag  in the FormTransormer is not
the
   best solution, but in my case it would not matter, because every error
message
   has to get translated.
   What I am trying now is to translate the error message in my
RegistrationAction, where
   I also do my customized validation.
   For this I am trying to use the functionality of the i18nTransormer and
the ResourceBundleFactory
   to find and to translate the messages.
   This of course will mean, that I can´t use Schematron validation anymore
and also it is not
   running yet:)
   So, maybe you have a hint how I could wrap the message in the
FormTransformer, if this would
   then be easier.


   Thanx again for any help,

   miHam


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

XML-Forms and i18n

[michael_hampel]

Hello,

I was just trying to change the XMLFormTransformer to add an
i18n:text tag, when the Transformer is dealing with violations.
I tried the following in the startElementViolations method:

  1.) I tried to add the tag like this:

  // render violation tag
super.startElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION, attributes );
 // set message
   String startInter = i18n:text;
String endInter = /i18n:text;
String vm = nextViolation.getMessage();
   String result = startInter + vm + endInter;
super.characters( result.toCharArray(), 0, result.length());

super.endElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION);

  2.) and like this:

  INTER_PREFIX = i18n
  TAG_VIOLATION=text
  Here I thought that I could create the i18n tag like the
xf:validation tag is created

  // render violation tag
super.startElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION, attributes );
AttributesImpl emptyAttributes = new AttributesImpl();
super.startElement(null, null, INTER_PREFIX + : + TAG_INTER,
emptyAttributes);
String vm = nextViolation.getMessage();
super.characters( vm.toCharArray(), 0, vm.length());
super.endElement(null, null, INTER_PREFIX + : + TAG_INTER);
super.endElement(uri, TAG_VIOLATION, NS_PREFIX + : +
TAG_VIOLATION);

Both ways did not work. In the first case I got an error message like this:
  i18n:texterror_message/i18n:text
but it was not translated - so I think that there were no real tags.
The second case was ignored completely  - according to the log.

Maybe somebody can advise if I do this at the right place, or if I should
try somewhere else
or how the Transformer works regarding the super.startElement() - if this
is the way how
to add a new element to the xml or if this is done differently?

thanx again for any help,

miHam




-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

xml-forms

[michael_hampel]

Hello,

   i have a new problem:)
   In my FormAction I want to send back a request parameter with my page to
use
  this parameter in a xsl-stylesheet.
  Therefore I tried the following:
   if(view == first)
  if(cmd == next)
request.setAttribute(show, no);
return(NEXT_PAGE);


Then I would like to use this parameter in the stylesheet for NEXT_PAGE.
Am I doing here something completely wrong?

Thanks for any help,

miHam


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: xml-forms

[Piroumian Konstantin]

 From: [EMAIL PROTECTED] 
 
 Hello,
 
i have a new problem:)
In my FormAction I want to send back a request parameter 
 with my page to
 use
   this parameter in a xsl-stylesheet.
   Therefore I tried the following:
if(view == first)
   if(cmd == next)
 request.setAttribute(show, no);
 return(NEXT_PAGE);
 
 
 Then I would like to use this parameter in the stylesheet for 
 NEXT_PAGE.
 Am I doing here something completely wrong?

To use a parameter returned by an action as stylesheet parameter you should
do the following:
- add parameter value to a Map object (you can add it also to request
attributes if needed)
- return the Map from your action
- use that parameter as a transformer parameter using this syntax:

  map:act type=form
map:generate .../
map:transform ...
map:parameter name=next-page value={show} /
/map:transform
  /map:act

Konstantin

 
 Thanks for any help,
 
 miHam
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: XML Forms again

[Piroumian Konstantin]

 From: [EMAIL PROTECTED] 
 
 Hello,
 
...
 
Still I am wondering, if I can use the bean used for the 
 model, outside
 of my FormAction or if it is only
   possible to use it in this action.

The map:parameter name=xmlform-scope value=session/ indicates the
scope of your instance data (e.g. your bean), so if you set it to 'session'
then your bean should be available everywhere where the session is
available, until you remove it.

Konstantin

 
   Thanks again for any help!
 
miHam
 
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XML Forms again

[Ivelin Ivanov]

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 05, 2002 8:34 AM
Subject: XML Forms again


Hello,

   another issue concerning XML-forms:
   In the action  for the form processing, the method
filterRequestParameters(..) should be used for validation that
   exceeds Schematron validation.
   Could someone please provide an example, or give an explanation how to
use this method.
   I don´t understand if I am supposed to do the validation within this
method (but why then: return false if the
   request parameter should not be filtered), or if something happens
according to the value returned?
   What follows is then how to get error messages back?

You will use this method to tell XMLForm to *ignore* certain request
parameters when going through the automatic population and validation.
In most cases you don't need to override this method.

What kind of validation do you need to do which a Schematron schema can't
provide.
You can do additional custom validation in your perform() method.


   Still I am wondering, if I can use the bean used for the model, outside
 of my FormAction or if it is only
  possible to use it in this action.

A form and its model are stored in the servlet session or request. You can
get it with Form.lookup( YourFormId )
The XMLFormTransformer accesses the same Form as the action.


Ivelin



  Thanks again for any help!

   miHam



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

XML-Forms

[michael_hampel]

Hello,

   Before I start working with the xml-form implementation in Cocoon,
   I want to find out if it is possible to use xml_form together with the
   i18n Transformer to display
  xf:captionFirst Namexf:caption
   in different languages:
  xf:captioni18n:textfirstName/i18n:text/xf:caption

   Also, how can I use Internationalisation with Schematron error messages?
   Will it work, if I specify the key of the message as the Schematron
Error message
  assert test=string-length(.)=0
 Error121

  and in the xml File I do:
  error
  i18n:textxf:violations class=error//i18n:text
  /error

  If this works when will I run the i18n Transformer - before or after the
XMLFormTransformer?

  Thanks very much for any help!!

   miHam


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

XML-Forms

[michael_hampel]

Hello,

   Before I start working with the xml-form implementation in Cocoon,
   I want to find out if it is possible to use xml_form together with the
   i18n Transformer to display
  xf:captionFirst Namexf:caption
   in different languages:
  xf:captioni18n:textfirstName/i18n:text/xf:caption

   Also, how can I use Internationalisation with Schematron error messages?
   Will it work, if I specify the key of the message as the Schematron
Error message
  assert test=string-length(.)=0
 Error121

  and in the xml File I do:
  error
  i18n:textxf:violations class=error//i18n:text
  /error

  If this works when will I run the i18n Transformer - before or after the
XMLFormTransformer?

  Thanks very much for any help!!

   miHam


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: XML-Forms

[Piroumian Konstantin]

 From: [EMAIL PROTECTED] 
 
 Hello,
 
Before I start working with the xml-form implementation in Cocoon,
I want to find out if it is possible to use xml_form 
 together with the
i18n Transformer to display
   xf:captionFirst Namexf:caption
in different languages:
   xf:captioni18n:textfirstName/i18n:text/xf:caption
 
Also, how can I use Internationalisation with Schematron 
 error messages?
Will it work, if I specify the key of the message as the Schematron
 Error message
   assert test=string-length(.)=0
  Error121
 
   and in the xml File I do:
   error
   i18n:textxf:violations class=error//i18n:text
   /error
 
   If this works when will I run the i18n Transformer - before 
 or after the
 XMLFormTransformer?
 
   Thanks very much for any help!!

To answer your question: I think that it should work the way you've
described. You should run i18n transformer after the XMLFormTransformer, so
it could translate also the violations.

You raise a very interesting issue. I've promised to make a sample of
multilanguage XML Form, but, unfortunately, have no free time at all now.
Please, let us know about the results and any problems that you encounter.

Konstantin

 
miHam
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Elegant solution for filling forms

[Andrei Svirida]

Hello Cocooners,

I have a simple problem filling the values of my form fields.
As it seems to be rather common and oft occuring problem i hope somebody knows a 
solution.

I have a form described in XML file test.xml (used with Stylebook
Stylesheets) :

---
 form name=testform
  Text:text name=city size=20/
 /form
---

I also have an Cocoon Action GetCityAction which sets the parameter
city in the sitemap.

I want the user to see the current value of the field city in browser, so
the content of test.xml must be changed to
---
 form name=testform
  Text:text name=city size=20 value=cologne/
 /form
---
before passing it to Stylebook stylessheets transformer.

Is there some elegant way to do it?

I know that could be achieved by writing a stylesheets like

xsl:param name=city/
xsl:template match=text
 xsl:if test=@name='city'
text name=city size=@size value=$city /
 /xsl:if
 
/xsl:template

and sitemap like:
map:act type=GetCityAction
  map:generate src=test.xml
  map:transform src=stylesheets/apache.xsl
map:parameter name=city value={city} /
  /map:transform
  ...
/map:act
-

but i don't want to change my stylesheets every time i add a new
variable to the form.
  

--
Andrei Svirida, Projekte  Entwicklung
MIDRAY GmbH - a debitel company
Phone:  +49.221.8884 435 
Fax:+49.221.8884 455

http://www.midray.com/


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

RE: Elegant solution for filling forms

[Piroumian Konstantin]

 From: Andrei Svirida [mailto:[EMAIL PROTECTED]] 
 
 Hello Cocooners,
 
 I have a simple problem filling the values of my form fields.
 As it seems to be rather common and oft occuring problem i 
 hope somebody knows a solution.

Take a look at the XMLForm. It solves this kind of problems, such as mapping
your data to your form fields, mapping request parameters to your data
model, rules-based validation. See below for more:

 
 I have a form described in XML file test.xml (used with Stylebook
 Stylesheets) :
 
 ---
  form name=testform
   Text:text name=city size=20/
  /form
 ---
 
 I also have an Cocoon Action GetCityAction which sets the parameter
 city in the sitemap.
 
 I want the user to see the current value of the field city 
 in browser, so
 the content of test.xml must be changed to
 ---
  form name=testform
   Text:text name=city size=20 value=cologne/
  /form
 ---
 before passing it to Stylebook stylessheets transformer.
 
 Is there some elegant way to do it?

If for some reason you don't want to use XMLForm then you can simply write a
transformer that performs this. 

 
 I know that could be achieved by writing a stylesheets like
 
 xsl:param name=city/
 xsl:template match=text
  xsl:if test=@name='city'
 text name=city size=@size value=$city /
  /xsl:if
  
 /xsl:template
 
 and sitemap like:
 map:act type=GetCityAction
   map:generate src=test.xml
   map:transform src=stylesheets/apache.xsl
 map:parameter name=city value={city} /
   /map:transform
   ...
 /map:act
 -
 
 but i don't want to change my stylesheets every time i add a new
 variable to the form.

And you would also add another action too. I'd use one action to get the
data and then will use either request attributes or session to pass the data
to a transformer which would fill in your form. It really worth to take a
look at the XMLForm.

Konstantin

   
 
 --
 Andrei Svirida, Projekte  Entwicklung
 MIDRAY GmbH - a debitel company
 Phone:  +49.221.8884 435 
 Fax:+49.221.8884 455
 
http://www.midray.com/


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Elegant solution for filling forms

[Ivelin Ivanov]

http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html

Piroumian Konstantin wrote:
From: Andrei Svirida [mailto:[EMAIL PROTECTED]] 

Hello Cocooners,

I have a simple problem filling the values of my form fields.
As it seems to be rather common and oft occuring problem i 
hope somebody knows a solution.
 
 
 Take a look at the XMLForm. It solves this kind of problems, such as mapping
 your data to your form fields, mapping request parameters to your data
 model, rules-based validation. See below for more:
 


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: multipart/forms binary upload in mysql

[John Austin]

On Wednesday 05 June 2002 07:31 pm, you wrote:

I use PostgreSQL but use a Blob. There is a note somewhere in the 
Momjian book to the effect that it is easy to get file perms problems. 
Remember that the file will be read by the database engine with the 
effective userid of the database engine not the id used by your Servlet 
container to generate and submit the SQL statements.

 Has anyone successfully configured mysql to store binary data in blob
 fields?

 As soon as I try to upload e. g. an image I get an
 _org.apache.cocoon.ProcessingException:
 Could not add record: java.io.FileNotFoundException:
 org.apache.cocoon.components.request.multipart.FilePartFile@2bfa91
 (Datei oder Verzeichnis nicht gefunden)_

 The file itself is correctly uploaded in the upload-dir

 I used the howto from
 http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=101468178609584w=
2 but only getting the error above.

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: multipart/forms binary upload in mysql

[Christian Haul]

On 06.Jun.2002 -- 06:56 AM, Andrew Timberlake wrote:
 Gerhard
 
 I think that your problem is not mysql but the use of the
 DatabaseAddAction.
 Looking through the source for the DatabaseAddAction indicates no
 awareness of Uploaded Files.
 The error you are receiving below shows that cocoon is correctly
 retrieving your file and placing it in a FilePartFile object but the
 DatabaseAddAction is retrieving the data through request.getParameter()
 which only returns a string showing you the toString() results of the
 FilePartFile object.
 If you handle the database work in your own action you will have no
 problem adding the binary data (Correction: using mysql's default
 limits, you will only be able to store 1M of information (Change
 max_allowed_packet if you need more)).
 
 You should be able to write a small action which reads the FilePart and
 places the actual file into a request Attribute.

And if you were using the new database actions (scratchpad in 2.0.3,
o.a.c.acting.modular package in HEAD), you would just write your custom
InputModule (o.a.c.components.modules.input) which is *really*
simple. Ahem, well, currently the setColumn method does not allow to
provide an InputStream or a Reader to it but that would be POC to
change. 

Chris.

-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

multipart/forms binary upload in mysql

[Gerhard Hipfinger]

Hi!

Has anyone successfully configured mysql to store binary data in blob 
fields?

As soon as I try to upload e. g. an image I get an
_org.apache.cocoon.ProcessingException:
Could not add record: java.io.FileNotFoundException:
org.apache.cocoon.components.request.multipart.FilePartFile@2bfa91
(Datei oder Verzeichnis nicht gefunden)_

The file itself is correctly uploaded in the upload-dir

I used the howto from
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=101468178609584w=2
but only getting the error above.

Anyone out there who can confirm mysql troubles?

Regards,
Gerhard


-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: multipart/forms binary upload in mysql

[Andrew Timberlake]

Gerhard

I think that your problem is not mysql but the use of the
DatabaseAddAction.
Looking through the source for the DatabaseAddAction indicates no
awareness of Uploaded Files.
The error you are receiving below shows that cocoon is correctly
retrieving your file and placing it in a FilePartFile object but the
DatabaseAddAction is retrieving the data through request.getParameter()
which only returns a string showing you the toString() results of the
FilePartFile object.
If you handle the database work in your own action you will have no
problem adding the binary data (Correction: using mysql's default
limits, you will only be able to store 1M of information (Change
max_allowed_packet if you need more)).

You should be able to write a small action which reads the FilePart and
places the actual file into a request Attribute.
I refer to the setColumn method in AbstractDatabaseAction which looks
for form elements in the following sequence:
snip
Object value = request.getParameter(param);
if (value == null) value = request.getAttribute(param);
if (value == null) value = request.get(param);
/snip
Here it will locate the uploaded file through the getParameter so it
won't keep checking.
I would use a different name for the form field than actually used in my
HTML form and then I would read the FilePart in my own action saving the
File into a request attribute using the field name specified to the
DatabaseAddAction which will cause the DatabaseAddAction to find the
File in the request.getAttribute in the code above.

I hope this helps a little.

Andrew

On Thu, 2002-06-06 at 01:31, Gerhard Hipfinger wrote:
 Hi!
 
 Has anyone successfully configured mysql to store binary data in blob 
 fields?
 
 As soon as I try to upload e. g. an image I get an
 _org.apache.cocoon.ProcessingException:
 Could not add record: java.io.FileNotFoundException:
 org.apache.cocoon.components.request.multipart.FilePartFile@2bfa91
 (Datei oder Verzeichnis nicht gefunden)_
 
 The file itself is correctly uploaded in the upload-dir
 
 I used the howto from
 http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=101468178609584w=2
 but only getting the error above.
 
 Anyone out there who can confirm mysql troubles?
 
 Regards,
 Gerhard
 
 
 -
 Please check that your question has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faqs.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 



-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dynamic forms

[Matthieu Benéteau]

This is not a Cocoon2 but a DHTML issue.
You have to use JavaScript.

Try this tutorial page :
http://www.pageresource.com/jscript/jforms.htm

Regards,
Matthieu


 -Message d'origine-
 De : Cocoon Newbie [mailto:[EMAIL PROTECTED]]
 Envoyé : mercredi 17 avril 2002 22:31
 Objet : Dynamic forms


 Has anyone been able to create a form where the validation rules for
 some fields dynamically change based on selections made in other fields?
 For example, postalcode would be validated differently based on the
 choice of country? Any ideas would be appreciated.

 Thanks,

 Ed


 -
 Please check that your question has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faqs.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamic forms

[Cocoon Newbie]

Matthieu:

I see your point, however since the validation is done on the server 
rather than on the client, I was hoping it to be something that Cocoon 
could accomplish.

I have played it with it some more and am stuck on the last mile. I 
can switch the validation rules, however, I still need to figure out how 
to reset the validation results from the prior validation attempt before 
re-submitted results are validated again. Otherwise, the validator seems 
to remember the prior validation result for the field, validation rule 
of which has changed, and fails it.

Regards,

Ed

Matthieu Benéteau wrote:

This is not a Cocoon2 but a DHTML issue.
You have to use JavaScript.

Try this tutorial page :
http://www.pageresource.com/jscript/jforms.htm

Regards,
Matthieu




-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Dynamic forms

[Matthieu Benéteau]

Hi Ed,

Sorry, I hadn't really understood what you meant.
Well, I found it easier to process all the form validations on the client
side, because I have large forms with lots of elements. I check and process
them before sending, so the server task is far lighter.

I haven't tried the server-side validation.

Regards,
Matthieu


 I see your point, however since the validation is done on the server
 rather than on the client, I was hoping it to be something that Cocoon
 could accomplish.

 I have played it with it some more and am stuck on the last mile. I
 can switch the validation rules, however, I still need to figure out how
 to reset the validation results from the prior validation attempt before
 re-submitted results are validated again. Otherwise, the validator seems
 to remember the prior validation result for the field, validation rule
 of which has changed, and fails it.

 Regards,

 Ed

 Matthieu Benéteau wrote:

 This is not a Cocoon2 but a DHTML issue.
 You have to use JavaScript.
 
 Try this tutorial page :
 http://www.pageresource.com/jscript/jforms.htm
 
 Regards,
 Matthieu
 


-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Dynamic forms

[Cocoon Newbie]

Has anyone been able to create a form where the validation rules for 
some fields dynamically change based on selections made in other fields? 
For example, postalcode would be validated differently based on the 
choice of country? Any ideas would be appreciated.

Thanks,

Ed


-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: I'd really love to POST forms...

[Matthieu Beneteau]

Ok, my mistake...
I must confess I hadn't even tried (!), and it perfectly worked at the first
try.
My apologies...

Thanks Vadim !

Matthieu


 -Message d'origine-
 De : Vadim Gritsenko
 [mailto:[EMAIL PROTECTED]@quaternove.fr]
 Envoye : jeudi 14 mars 2002 19:54
 Objet : RE: I'd really love to POST forms...


  From: Matthieu BenÊteau [mailto:[EMAIL PROTECTED]]
 
  Hi folks,
 
  I'm using Cocoon-2.0.1 with Tomcat-4.0.1.
 
  I'm working on a Cocoon-based editor that allows to edit and modify
 XML
  files with a web browser. It uses several HTML forms.
 
  RequestGenerator is just fine to retrieve the parameters of a GET
 request.
  But as my application is growing, my forms are getting bigger and I
 need to
  submit them with the POST method.

 RequestGenerator *should* work with posted forms also. Please try it;
 get back if it does not work with patches ;) or bug report.

 Vadim

  Unfortunately, it seems that the only generator dealing with POST is
 the
  StreamGenerator, which expects some XML data. And I have no way to
 submit
  the content of my forms as XML data.
 
  Does anyone know why there is no generator to make me happy?
  I would really love to POST forms!...
 
 
  Matthieu
 
 
  -
  Please check that your question has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faqs.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]


 -
 Please check that your question has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faqs.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

I'd really love to POST forms...

[Matthieu Benéteau]

Hi folks,

I'm using Cocoon-2.0.1 with Tomcat-4.0.1.

I'm working on a Cocoon-based editor that allows to edit and modify XML
files with a web browser. It uses several HTML forms.

RequestGenerator is just fine to retrieve the parameters of a GET request.
But as my application is growing, my forms are getting bigger and I need to
submit them with the POST method.

Unfortunately, it seems that the only generator dealing with POST is the
StreamGenerator, which expects some XML data. And I have no way to submit
the content of my forms as XML data.

Does anyone know why there is no generator to make me happy?
I would really love to POST forms!...


Matthieu


-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: I'd really love to POST forms...

[Vadim Gritsenko]

 From: Matthieu BenÊteau [mailto:[EMAIL PROTECTED]]
 
 Hi folks,
 
 I'm using Cocoon-2.0.1 with Tomcat-4.0.1.
 
 I'm working on a Cocoon-based editor that allows to edit and modify
XML
 files with a web browser. It uses several HTML forms.
 
 RequestGenerator is just fine to retrieve the parameters of a GET
request.
 But as my application is growing, my forms are getting bigger and I
need to
 submit them with the POST method.

RequestGenerator *should* work with posted forms also. Please try it;
get back if it does not work with patches ;) or bug report.

Vadim
 
 Unfortunately, it seems that the only generator dealing with POST is
the
 StreamGenerator, which expects some XML data. And I have no way to
submit
 the content of my forms as XML data.
 
 Does anyone know why there is no generator to make me happy?
 I would really love to POST forms!...
 
 
 Matthieu
 
 
 -
 Please check that your question has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faqs.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

write xml files with forms included with FileWriter to disk

[Erik Stunkat]

Hi,

I want to build a web application with forms included. Now some users gonna
fill the forms and press Submit or whatever. Is it possible to use
FileWriter to save the new files on disk?

thanks!

erik stunkat


-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Complex Forms

[Madel,Kurt]

The company that I work for builds web front-ends for database editing,
viewing, report generation, etc.  I am using Cocoon2 to generate dynamic PDF
reports, and we use ASP for the rest of the site.  I would like to use
Cocoon for the entire site, but have yet to see any examples of extremely
complex forms.

Has anybody created complex multi-page forms with validation to insert
complicated records into a database, and then manipulate those records, and
if so did you add any non-standard components to Cocoon (ie. databinding)?

What is the status of exformula??

If this just isn't Cocoon's cup of tea, do any users have an opinion of what
is the best web framework/templating system for complex, validated, data
intensive html forms.

Thanks,
Kurt

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Complex Forms

[Max Larsson]

Hi,

i had a similar task to solve. But i think i didn't had such
complex form like you will have. I solved it with couples
of self coded action and data binding framework. The databinding
farmework is self coded, too. But it will be replaced with something
much beter. I know about two packges, which could replace 
my framework: The castor project and the persitence/databinding
part from Trubine (Apache).
But i will first move on, when i know how exformula works??

HTH

Max

 -Original Message-
 From: Madel,Kurt [mailto:[EMAIL PROTECTED]]
 Sent: Mittwoch, 31. Oktober 2001 22:58
 To: '[EMAIL PROTECTED]'
 Subject: Complex Forms
 
 
 The company that I work for builds web front-ends for 
 database editing,
 viewing, report generation, etc.  I am using Cocoon2 to 
 generate dynamic PDF
 reports, and we use ASP for the rest of the site.  I would like to use
 Cocoon for the entire site, but have yet to see any examples 
 of extremely
 complex forms.
 
 Has anybody created complex multi-page forms with validation to insert
 complicated records into a database, and then manipulate 
 those records, and
 if so did you add any non-standard components to Cocoon (ie. 
 databinding)?
 
 What is the status of exformula??
 
 If this just isn't Cocoon's cup of tea, do any users have an 
 opinion of what
 is the best web framework/templating system for complex, 
 validated, data
 intensive html forms.
 
 Thanks,
 Kurt
 
 -
 Please check that your question has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faqs.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: xml-schema / validate forms

[Martin Man]

On Wed, Oct 24, 2001 at 10:40:07AM +0200, Kenneth Petersen wrote:
 Hi all!
 
 I was wondering why efforts have been made to generate and maintain the 
FormValidatorAction. Why not just use xml-schemas and xml-validation to validate 
input from froms?
 
the effort was put there (by me as the author and others) becuse at the time
of writing I was not that failiar with XML schema, and actually I never
thought about it, ..., but as I'm actually almost rewriting the validator I'm
immediately going to take a look at it ang possibly give it a chance (in case
it will save me coding and will make the things simpler)...


 The only problem I can see in using xml-schemas is that it does not support I18N. On 
the other hand neither does FormValidatorAction. The lack of I18N can be solved with 
xml-schemas when generation the xml-file from parameters from the Request.
 
 If it is already possible to use xml-schemas in Cocoon2, I would very much like to 
know.
 
 
 Best Regards
 KP

thanx,
martin

p.s. you might check archives for recent discussion about [RT] New Validator
Infrastructure or how it was called :)

-- 
2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06 0223
http://mman.dyndns.org/mman.gpg

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

xml-schema / validate forms

[Kenneth Petersen]

Hi all!

I was wondering why efforts have been made to generate and maintain the 
FormValidatorAction. Why not just use xml-schemas and xml-validation to validate input 
from froms?

The only problem I can see in using xml-schemas is that it does not support I18N. On 
the other hand neither does FormValidatorAction. The lack of I18N can be solved with 
xml-schemas when generation the xml-file from parameters from the Request.

If it is already possible to use xml-schemas in Cocoon2, I would very much like to 
know.


Best Regards
KP

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: umlauts in html forms

[Arno Illmann]

For which encoding is the database configured?

mfg, Arno

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: umlauts in html forms

[Michael Gerzabek]

Database is encoded for ISO-8859-1 also.

But I found a switch at the serializer. When you use the tag
map:serializer name=html mime-type=text/html
src=org.apache.cocoon.serialization.HTMLSerializer
encodingISO-8859-1/encoding
/map:serializer
then everything works fine!

thanx

Michael


-Ursprungliche Nachricht-
Von: Arno Illmann [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 3. Oktober 2001 18:06
An: [EMAIL PROTECTED]
Betreff: Re: umlauts in html forms


For which encoding is the database configured?

mfg, Arno

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

umlauts in html forms

[Michael Gerzabek]

hi all,

I'm implementing forms that write to a backend via cocoon2-actions. I use
encoding ISO-8859-1 to render the data to the clients and all umlauts are
coded well. But when I get umlauts from the clients they go in an obscure
manner to the database. Has anyone experience with this problem?

bye

Michael


-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Forms pseudo and passwd encryption

[cib]

Thanks, 
I'll try and install pgp.
But is there a command in xsp to encrypt datas in a 
form, and to decode it when using the formvalidator? (Like in mysql, the encrypt 
function)
Otherwise, password is send in plain text inside 
the post/get method.
Thanks for your help

Cib

France, Bordeaux, xml and gay pride.

  - Original Message - 
  From: 
  Karl Øie 
  To: [EMAIL PROTECTED] ; cib 
  Sent: Friday, August 17, 2001 11:04 
  AM
  Subject: RE: Forms pseudo and passwd 
  encryption
  
  ssl 
  now secures the actual connection between your server and the client, but it 
  is still uncrypted on both the client and server machine.
  
  to 
  further secure your form data you should use an encryption on whatever medium 
  you store the data in on the server, and preferably an encryption that can 
  create a public key to send to the user, and a private key to store data on 
  the server. (f.eks PGP)
  
  then 
  comes the problem that your application will have to contain your public and 
  private key, so now it is very very very important to secure the operating 
  system and network you run your application on.
  
  mvh 
  karl
  
  
-Original Message-From: cib 
[mailto:[EMAIL PROTECTED]]Sent: 16. august 2001 
23:22To: Cocoon User Mail ListSubject: Forms pseudo 
and passwd encryption
Hi, 
With help of tomcat user list, I've got my ssl 
working .
I wonder now how to completely secure my forms 
datas? 
How should I encrypt names and password from 
the register form?

Thanks for any help,
I'm learning a lot, but still a newbie in 
security things.

Cib

France, Bordeaux, xml and gay 
pride.

Re: AW: forms in coocon2, is SchemoX dead ?

[Steffen Stundzig]

Hi,

I'm one of the maintainers of SchemoX at the infozone group.

SchemoX isn't dead. I would say, it sleeps. It's maintainers hasn't
that time to develop it as desired, because of economical reasons.

For now, I could say that SchemoX will go the way of extending the full blown
form generator/validator/handler stuff in the future.

For german readers, in the next Java Spektrum, there is a article about the
SchemoX framework. This articles contains also the information about the next
SchemoX versions. Sorry for this advertising, but this article is, as I know,
the newest information about the framework.

If somebody would willing to help on developing SchemoX, I would wake it up
ASAP.

Regards
Steffen...

On Mon, 16 Jul 2001 you wrote:
 I agree about the xform and xfdl..In future, i guess,
 these concepts would go beyond just form validation
 and handling..
 
 For now, from this discussion, I understand that we
 are all looking for some form of automated/simplified
 form generation/validation and handling..am i right?..
 
 There is a design proposal on SchemoX website to make
 it run with cocoon2..anyone had look at it?
 
 And also, there are efforts on going with current
 cocoon reg form validation and other stuff...they seem
 to follow the xform approach from nanotech..but not
 sure if the original author has intent of extending it
 to be full blown form generator/validator/handler or
 not...



-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: forms in coocon2, is SchemoX dead ?

[Christian Haul]

On 16.Jul.2001 -- 09:28 PM, java guru wrote:
 I agree about the xform and xfdl..In future, i guess,
 these concepts would go beyond just form validation
 and handling..

To me it looks like xfdl is not actively maintained by W3C, since the
document is rather old.

 For now, from this discussion, I understand that we
 are all looking for some form of automated/simplified
 form generation/validation and handling..am i right?..

Right.

 And also, there are efforts on going with current
 cocoon reg form validation and other stuff...they seem
 to follow the xform approach from nanotech..but not
 sure if the original author has intent of extending it
 to be full blown form generator/validator/handler or
 not...

Well, I'm not the original author but have supplied some of the
validations. Indeed, I would like to extend this to a more complete
form generator/validator. But I haven't made up my mind, which way to
follow.

To me, XForms looks like the most importand standard on this but I
think it is not advisable to aim for a fully compliant implementation
for C2 because (please correct any errors)

a) XForms expects XML encoded parameters. I'm not 100% sure on
   this, but I think few to none of the available browsers
   support this. I don't think it would make sense to convert
   request parameters to a XML representation before processing
   them since this would probably be too costly. A Javascript
   solution to post parameters as XML is propably out of the
   question.

b) XForms allow besides the basic types arbitrary types definable
   in XML Schema. While this might be possible for validation, it
   is expensive but seems only necessary if parameters are XML
   encoded. 

c) XForms declare forms within the HEAD/ section of a
   document. XSP don't have such a concept.

d) XForms' forms can be mixed and nested. This is not possible
   with current XHTML forms.

e) XForms specify validation as XPath expressions. Makes only
   sense if form data is accessible through XPath.

f) XForms specify active behaviour: triggers, conditionals
   ... This is probably out of scope.

g) XForms provide sliders, subpages, lists c. This is too complex
   for short term availability.

h) XForms specify subpages. Whiles this could be done it's also
   probably too complex for short term availability.

i) XForms don't specify error messages.

j) Since validation is (at least additionally) server based, this
   should keep the already filled in elements.

From this follows, that a fully compliant implementation should not be
the goal.

To do would be (not necessarily in order of importance)

   1) enhance form validator action to validate more XForms basic
  types. 

   2) provide a taglib that combines necessary features from
  formval.xsl and request.xsl plus some form specification that
  produces valid XForms

   3) provide stylesheets that render HTML-4.0 forms (probably
  separate ones for IE, NS c), XSL-FO c.
 
   4) provide javascript routines that do client side checking (as
  well for major platforms)

Suggestions, ideas and helping hands welcome :-)

Chris.

-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: forms in coocon2, is SchemoX dead ?

[Ulrich Mayring]

Christian Haul wrote:
 
 To me, XForms looks like the most importand standard on this but I
 think it is not advisable to aim for a fully compliant implementation
 for C2 because (please correct any errors)

What I don't like about XForms is mainly that it needs a so-called
XFormsProcessor, i.e. yet another special server application. The other
thing is that it only applies to forms, I'd like a more general tool for
modelling workflows. The fancy UI Widgets that XForms calls for (e.g.
sliders), are unsupported by any Browser I know of.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: forms in coocon2, is SchemoX dead ?

[Christian Haul]

On 17.Jul.2001 -- 10:07 AM, Berin Loritsch wrote:
  a) XForms expects XML encoded parameters. I'm not 100% sure on

 Which means that for the two standard submission types (url encoded
 and multipart), the XPath expression is used to reconstruct the XML
 document.

So, do you think this is advisable, to reconstruct the XML?

  c) XForms declare forms within the HEAD/ section of a
 document. XSP don't have such a concept.
 
 This is a markup issue.  Basically, the instance/schema/binding info
 is stored at the top of the document in an xform tag.

As there's no part of an XSP that is an equivalent of the HEAD/
part, the question arises where to put it instead. Just anywhere at
the top? Anywhere before the first form element? Or, what the hell,
like before with HTML forms, all form elements nested?

  d) XForms' forms can be mixed and nested. This is not possible
 with current XHTML forms.
 
 This is true.  There are two potential solutions:
 
 1) only have one form for the whole document and separate the
markup and validation at server side.

This is probably the way to go. Although different target URIs for
different forms would be cleaner, this could be achieved by action +
matchers on parameter values instead of URIs. Such matchers already
exist in C2.

 2) force the user to use XHTML form constraints.

 
  e) XForms specify validation as XPath expressions. Makes only
 sense if form data is accessible through XPath.
 
 In an XForms implementation this is a requirement.  Validation is
 done via Schema (current spec), as well as Dynamic Constraint Language
 (based in part on ECMAscript).
 
 References are by XPath.

I think this could be postponed to a later evolution of such a
package, can it? 

  f) XForms specify active behaviour: triggers, conditionals
 ... This is probably out of scope.
 
 This can only be in scope if you have a transformer that creates
 Javascript on the fly.  As different browsers have different methods
 of referencing form parts, this is where the BrowserSelector can
 come in handy.
 
 Again, this is not easy.

So, again, this shouldn't be part of an initial offering.

  h) XForms specify subpages. Whiles this could be done it's also
 probably too complex for short term availability.
 
 I would implement it as another page in the form.  In other words, we
 do validation on the information we have, and go to the subpage, etc.

This is a (minor?) breach from C2 philosophy, to split different views
into separate XSPs. OK, this is not really relevant here and therefore
more or less OK. Again, an issue for later revisions.

  i) XForms don't specify error messages.
 
 This is my biggest beef with it.  They have heard this complaint before.

Well, we could extent and embrace ;-) A similar functionality could be
done with the switch/ contructs in XForms and those triggers. For
usability error messages would be quite important to be available in a
clean and simple way. And as you said, XForms is a moving target, so
perhaps, this is going to happen anyway :-)

  To do would be (not necessarily in order of importance)
  
 1) enhance form validator action to validate more XForms basic
types.
 
 XForms is now completely Schema based.  Throw the generated XML through
 Xerces and see what gets kicked out.  I would implement the ErrorHandler
 so that all errors can be cached.

Mmmh, another source of errors in C2. Not valid Schema
definitions. And a reason to really reconstruct the XML. Think I'll
need to look a bit closer at XForms :-|

 3) provide stylesheets that render HTML-4.0 forms (probably
separate ones for IE, NS c), XSL-FO c.
 
 I started on this a while ago.  The overall style really depends on
 the site.  Bottom line is that XForms is a moving target.

Granted. But there need to be an example so that a form package is
usable and as a starting point for every one else to customize. Of
course there're a number of design alternatives in the XForms
spec. e.g. selectOne/ - radio buttons, check boxes (?!), drop down
boxes (select size=1/), select boxes (select/), ... and such a
stylesheet would probably provide only one or two of these i.e. based
on the number of item/s.

 4) provide javascript routines that do client side checking (as
well for major platforms)
 
 This really would have to be both platform and XForm specific.  The
 Javascript would need to be auto-generated.

I think some basic checking could be done independantly, check that a
field only contains numbers and display a pop-up if there's a
violation should be manageable.

Chris.

-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

forms in coocon2, is SchemoX dead ?

[Thorsten Mauch]

Hi All
Does anyone knows a MVC  framework for from processing in cocoon2 ?
I downloaded the CVS from SchemoX , but the last change was in January. So
it my impression is that SchemoX is dead. Is this correct ?
Are there other projetcs related to Form processing ?

Thanx Thorsten



-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: forms in coocon2, is SchemoX dead ?

[java guru]

I have posted similar requirement sometime back but no
response...Meantime here is what i found

1. XForm from nanoworks
http://xform.nanoworks.org/

I tried this but didnt feel comfortable to fit in with
cocoon2..

I think the form processing in c2 with form-validator
stuff is slowly moving towards this goal of full blown
form processing and validation..

I was really(and desperately) looking for simple and
effective mechanism to describe forms in xml and have
someother component deal with preparing form and
handling the validation stuff...Hope that arrives
soon...


 --- Thorsten Mauch [EMAIL PROTECTED] wrote:  Hi
All
 Does anyone knows a MVC  framework for from
 processing in cocoon2 ?
 I downloaded the CVS from SchemoX , but the last
 change was in January. So
 it my impression is that SchemoX is dead. Is this
 correct ?
 Are there other projetcs related to Form processing
 ?
 
 Thanx Thorsten
 
 
 

-
 Please check that your question has not already been
 answered in the
 FAQ before posting.
 http://xml.apache.org/cocoon/faqs.html
 
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
  


Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: forms in coocon2, is SchemoX dead ?

[Sergio Carvalho]

I also need form generation and validation. I am basing mu implementation 
in XFDL, a W3C recomendation for generic business forms (not wonly web-based, but 
paper-based ones too).

If there's interest in a joint effort, I think we could set up a repository
somewhere (sourceforge...) and release it under a BSD type license. Reply if 
interested.

On Mon, 16 Jul 2001 16:39:26 +0100 (BST), java guru [EMAIL PROTECTED] wrote:
--
 I have posted similar requirement sometime back but no
 response...Meantime here is what i found
 
 1. XForm from nanoworks
 http://xform.nanoworks.org/
 
 I tried this but didnt feel comfortable to fit in with
 cocoon2..
 
 I think the form processing in c2 with form-validator
 stuff is slowly moving towards this goal of full blown
 form processing and validation..
 
 I was really(and desperately) looking for simple and
 effective mechanism to describe forms in xml and have
 someother component deal with preparing form and
 handling the validation stuff...Hope that arrives
 soon...
 
 
  --- Thorsten Mauch [EMAIL PROTECTED] wrote:  Hi
 All
  Does anyone knows a MVC  framework for from
  processing in cocoon2 ?
  I downloaded the CVS from SchemoX , but the last
  change was in January. So
  it my impression is that SchemoX is dead. Is this
  correct ?
  Are there other projetcs related to Form processing
  ?
  
  Thanx Thorsten
  
  
  
 
 -
  Please check that your question has not already been
  answered in the
  FAQ before posting.
  http://xml.apache.org/cocoon/faqs.html
  
  To unsubscribe, e-mail:
  [EMAIL PROTECTED]
  For additional commands, e-mail:
  [EMAIL PROTECTED]
   
 
 
 Do You Yahoo!?
 For regular News updates go to http://in.news.yahoo.com
 
 -
 Please check that your question has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faqs.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 



--
Sergio Carvalho
---
[EMAIL PROTECTED]

If at first you don't succeed, skydiving is not for you

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: forms in coocon2, is SchemoX dead ?

[Jakob Praher]

hi,

after talking to the founder of the schemoX project (and asking the same
question) I know that it is not dead, suspended though.

As I am highly in need for a (X)form rendering and validating engine, I will
try to play with the schemoX codebase..
It would be great if anyone would join my efforts!

BTW: How are you currently doing form validation?

thanks

jp


-Ursprüngliche Nachricht-
Von: java guru [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 16. Juli 2001 21:02
An: [EMAIL PROTECTED]
Betreff: Re: forms in coocon2, is SchemoX dead ?


Great.,
   I am positively interested in this...please let me
know the details..


 --- Sergio Carvalho [EMAIL PROTECTED] wrote:

 I also need form generation and validation. I am
 basing mu implementation
 in XFDL, a W3C recomendation for generic business
 forms (not wonly web-based, but
 paper-based ones too).

 If there's interest in a joint effort, I think we
 could set up a repository
 somewhere (sourceforge...) and release it under a
 BSD type license. Reply if
 interested.

 On Mon, 16 Jul 2001 16:39:26 +0100 (BST), java guru
 [EMAIL PROTECTED] wrote:
 --
  I have posted similar requirement sometime back
 but no
  response...Meantime here is what i found
 
  1. XForm from nanoworks
  http://xform.nanoworks.org/
 
  I tried this but didnt feel comfortable to fit in
 with
  cocoon2..
 
  I think the form processing in c2 with
 form-validator
  stuff is slowly moving towards this goal of full
 blown
  form processing and validation..
 
  I was really(and desperately) looking for simple
 and
  effective mechanism to describe forms in xml and
 have
  someother component deal with preparing form and
  handling the validation stuff...Hope that arrives
  soon...
 
 
   --- Thorsten Mauch [EMAIL PROTECTED] wrote: 
 Hi
  All
   Does anyone knows a MVC  framework for from
   processing in cocoon2 ?
   I downloaded the CVS from SchemoX , but the last
   change was in January. So
   it my impression is that SchemoX is dead. Is
 this
   correct ?
   Are there other projetcs related to Form
 processing
   ?
  
   Thanx Thorsten
  
  
  
  
 

-
   Please check that your question has not already
 been
   answered in the
   FAQ before posting.
   http://xml.apache.org/cocoon/faqs.html
  
   To unsubscribe, e-mail:
   [EMAIL PROTECTED]
   For additional commands, e-mail:
   [EMAIL PROTECTED]
  
 
 


  Do You Yahoo!?
  For regular News updates go to
 http://in.news.yahoo.com
 
 

-
  Please check that your question has not already
 been answered in the
  FAQ before posting.
 http://xml.apache.org/cocoon/faqs.html
 
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 



 --
 Sergio Carvalho
 ---
 [EMAIL PROTECTED]

 If at first you don't succeed, skydiving is not for
 you


-
 Please check that your question has not already been
 answered in the
 FAQ before posting.
 http://xml.apache.org/cocoon/faqs.html

 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]



Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: forms in coocon2, is SchemoX dead ?

[Thorsten Mauch]

Our Company is also interessed to help. 
Do you have already a design ? 
BTW whats the relation from between XFDL http://www.w3.org/TR/NOTE-XFDL
and Xforms http://www.w3.org/TR/xforms/?

Is it correct that xforms is only for the web 
while XFDL is a more gernaeral aproach ?

From the SchemoX website i understand XForms
and XFDL only describe the layout of a form while
SchemoX has a wider approach. 

So i share the Opinion from Jakob to review SchemoX.

Regarding XForms i may make sense to study the source
from X-Smiles. http://www.x-smiles.org/

X-Smiles is an XML-browser that can display Xforms.

i will do that now :)


-Ursprüngliche Nachricht-
Von: java guru [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 16. Juli 2001 21:02
An: [EMAIL PROTECTED]
Betreff: Re: forms in coocon2, is SchemoX dead ?


Great.,
   I am positively interested in this...please let me
know the details..


 --- Sergio Carvalho [EMAIL PROTECTED] wrote:
 
 I also need form generation and validation. I am
 basing mu implementation 
 in XFDL, a W3C recomendation for generic business
 forms (not wonly web-based, but 
 paper-based ones too).
 
 If there's interest in a joint effort, I think we
 could set up a repository
 somewhere (sourceforge...) and release it under a
 BSD type license. Reply if 
 interested.
 
 On Mon, 16 Jul 2001 16:39:26 +0100 (BST), java guru
 [EMAIL PROTECTED] wrote:
 --
  I have posted similar requirement sometime back
 but no
  response...Meantime here is what i found
  
  1. XForm from nanoworks
  http://xform.nanoworks.org/
  
  I tried this but didnt feel comfortable to fit in
 with
  cocoon2..
  
  I think the form processing in c2 with
 form-validator
  stuff is slowly moving towards this goal of full
 blown
  form processing and validation..
  
  I was really(and desperately) looking for simple
 and
  effective mechanism to describe forms in xml and
 have
  someother component deal with preparing form and
  handling the validation stuff...Hope that arrives
  soon...
  
  
   --- Thorsten Mauch [EMAIL PROTECTED] wrote: 
 Hi
  All
   Does anyone knows a MVC  framework for from
   processing in cocoon2 ?
   I downloaded the CVS from SchemoX , but the last
   change was in January. So
   it my impression is that SchemoX is dead. Is
 this
   correct ?
   Are there other projetcs related to Form
 processing
   ?
   
   Thanx Thorsten
   
   
   
  
 

-
   Please check that your question has not already
 been
   answered in the
   FAQ before posting.
   http://xml.apache.org/cocoon/faqs.html
   
   To unsubscribe, e-mail:
   [EMAIL PROTECTED]
   For additional commands, e-mail:
   [EMAIL PROTECTED]

  
 


  Do You Yahoo!?
  For regular News updates go to
 http://in.news.yahoo.com
  
 

-
  Please check that your question has not already
 been answered in the
  FAQ before posting.
 http://xml.apache.org/cocoon/faqs.html
  
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
  
 
 
 
 --
 Sergio Carvalho
 ---
 [EMAIL PROTECTED]
 
 If at first you don't succeed, skydiving is not for
 you
 

-
 Please check that your question has not already been
 answered in the
 FAQ before posting.
 http://xml.apache.org/cocoon/faqs.html
 
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
  


Do You Yahoo!?
For regular News updates go to http://in.news.yahoo.com

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faqs.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]