<snip/>
> > Sorry, I tent not to agree here... the problems are there... Of couse if > > depends on what you are heading. Your proposal here is exactly what we at > > dff *don't* want... we want a clean and simple interface to the form > > handling and validation facitlities that should be (later) really a part > > of cocoon. What you are proposing here is to build cocoon form handling > > and validation *with* cocoon and not *for* it. Let me state explicitly: > > > > There should be not necessarily more than a single pipeline and not more > > than one transformer involved (except the last stylesheet for the > > serializer) > Ok, we seem to have fairly different goals, I often use several transformers > and pipelines and find that much more productive than having to write > actions in Java. I don't want to write java for simple forms either... I want to model my forms completely by creating a) a XML validity description (XSD... whatever) b) some XML views and for simple forms - that's it... and this information is handed to the controller (an action) to do whatever he needs... all I say is: this should not be part of the sitemap! > > > * The "xrequest" generator builds an input xml document from the (xpath) > > > request-parameters. > > > > Are you saying you want to build a view from the request?? > I'm not just saying that I want to do it, my colleagues and I are building > all our webapps that way, since quite a while, and find it much more > productive than the more traditional ways of form handling. Sorry, but this would definitly would not work for us here... Where do you get your <titles/> etc from? Do you have it in your XSLs? > If you want to do prepopulation it could easily be achieved by giving the > generator an xml-document as input, through the src-argument. > > > what about the checkboxes here? > That was a surprising part of your "HEADS UP" post, I have used plenty of > checkboxes and never experienced the "check box problem". I asked a > colleague about it, and he couldn't recall having any check box problems. > Maybe I have misunderstood something or maybe we use checkboxes in different > ways. ...again: a checkbox will not provide an request parameter value when it's not checked - so you don't know about whether there is a checkbox or not.. Please try it... > I think you are going to run into problems in the long run anyway if you > choose to use indirect population: Check the repeat construction in XForms > http://www.w3.org/TR/2002/WD-xforms-20020118/slice9.html#ui-repeat if you > use that together with checkboxes it will be problematic to prepopulate the > document. you might want to look into exFormular... it's already solved there... > I'll take another example: we have developed a interview > management system that among many other things are used for very large scale > medical research, the questionnaire contains a number of thousand questions, > which questions that are asked are dependent on earlier answers and > typically just a few percent of all the questions are asked under a > particular interview session. Would it be a good idea to prepopulate the > instance in this case? Ok, this example is of course very large scale, but I > think it illustrates that in many cases it is unrealistic to explicitly > enumerate everything that is _not_ said. are you talking about the building of the instance? > > And you have no impact on the document... > That is part of the point, I want to validate the input and possibly > transform it into another format before putting it in the document. > > > currently the > > views in our examples have only those "mapping" in there but that's not > > for always! > Didn't get that. ok... you lost me I lost in the above... ;) <root> <title>The Form</title> <info> Please enter all bla here </info> <f:group> <f:input ref="form/bla"> <f:caption>Please enter bla</f:caption> </f:input> </f:group> </root> ....so where does the text an the caption come from when you create this from a request?? > > > * The "schematron" transformer validates the input data, set some > > > "pipe-state" request attribute to "success" or "fail" and give > > some kind of > > > report about the errors. > > > > Let me make this clear: I don't like a transformer to validate my forms > > because this should happen inside the Controler which IMHO is supposed to > > be an action... I'd like to be able to easily write an action that > > can validate my form and then act on the result... > Let me make this clear: I don't want to have to write actions, for handling > ordinary form input ;) that's not an argument to put this stuff in the sitemap! SoC!! I would like to configure the controller and don't want it in the sitemap! > > > In the above example collection of the data and storing of the data > > > (population of the instance) are separated while I&T combine > > them. There are > > > so many possible storages for instance data e.g.: beans and dom > > in session > > > and request attributes, files, relational db:s, xml db:s, > > business objects > > > and so on, that it seem overwhelming to create a common > > "instance" interface > > > for them all, better just put the data in the pipe and let the > > storage of > > > it, be someone others concern. > > > > I don't aggree here... in real world cases (guess 90%) the following 3 > > stores should be fine... > > > > * DOMInstance > > * BeanInstance > > * EJBInstance > > > There seem to be several real worlds ;) I would have said, that in 90% of > the "real world cases", one have a one page form where the content is put > directly in an SQL DB. well, I can't remeber when I had to write a one-page form last time... but I aggree: also 90% of our "real world cases" are mapped to a SQL DB... but IMHO that's not the point... you present the form (maybe in multiple pages) the form data gets collected in an instance and on the end the form is saved into the DB. Please understand that the instances are usually only pre-buffers before stuff gets into the backend. If you deal only with one-page forms you don't really need that... but even then there are a couple of reasons for that. And we needs this if we want to come up with a general form handling that also supports muli-page forms... > > The instance is (normaly) only used for pre-buffering before submission. see... <snip/> > > That's way too uncomfortable... What if you move one textbox from one view > > over into another one? > I prefer to have a framework that makes it really easy to write the 90% most > common cases, and make the more complicated cases doable, than having one > that makes simple things complicated ... same here... > > I know some people don't share my vision yet but I see it this way: > > > > * one guy writes a e.g. XSD with XMLspy defining the structure of the > > business object (the form) ...he has no clue about java or XSLT. > > > > * someone else get's this XSD an defines the views onto this documents. He > > "only" needs to understand the XSD and needs to know a bit how to > > use cocoon. > > > > * another one builds the XSLT. All he gets is XML as usual... > I share your vision, and IMO we will reach it first when more people are > starting to realize that data should be described in terms of XML and that > the natural place for XML is in the pipeline ;) not in any actions. Even if you mean the sitemap... not everything should go into the sitemap... please guys - SoC. > I share your vision I wouldn't like to force people using XSD, I don't think > it is worthwhile in simple cases. In many simple cases it is a better idea > to try to design your forms so that you don't have to validate anything or > maybe just a few fields, and in that case Schematron might be a simpler > solution than XSD. Did you ever read what I wrote? I want to support XSD, RelaxNG, Schematron and whatever people like to implement... *sigh* -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
