Torsten Curdt wrote: > On Mon, 15 Apr 2002, Daniel Fagerstrom wrote: <snip/> > > I find Ivelins and Torstens work on form handling very promising, but I > > share Berins (and some other commenter), concern that they are > maybe trying > > to find answers to some unnecessarily complicated problems. > > 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.
<snip/> > > * 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. 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. 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. 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. > 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. > And you are still not save with the checkbox problem if you > don't use direct population... See above > > * 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 ;) <snip/> > > 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. > The instance is (normaly) only used for pre-buffering before submission. > > > > I&T also discuss the indirect vs. direct population problem and > proposes to > > use direct population of instances (cf. the link above for details). The > > example above uses the indirect approach, but could easily be > made direct by > > giving a template instance as a "src" parameter. > > Did you mix direct vs. indirect above? Yes, I did. <snip/> > > I think the result of our recent "pipe-awareness" discussion is that the > > success or failure of a validation transformer should be put in > some "meta" > > parameter, probably in a request attribute. > > ...I still don't like it ;-) I can understand that, if you prefer to write actions before doing the work in the pipeline you will not have any use for it. > > > [------------instance-----------] > > >HTML: [-----view1-----][-----view2----] > > >WML: [--view1--][--view2--][--view3--] > > > > and also that validation could be done at still other > substructures that not > > necessarily are connected to the views (cf their paragraph > about views and > > phases). > > > > IMO one can simplify the problem considerably by deciding that the view > > always are non-overlapping sub trees of the instance, and that > we have one > > scheme for each view. I know that this is not a completely > generic solution, > > 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 ... > 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 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. > > but after all we probably did some modeling when we designed > our instance. > > The sub trees probably describes conceptually different areas, > so hopefully > > we can reuse this thinking by couple the views to these different areas. > > unfortunately this will only work if you have enough space to display > it... have you ever build a wap site? No, I have succeeded in staying away from it this far ;) I'll wait till the platforms become a little bit more mature, if I can. > (or what else is comming soon for > the mobiles? You are lucky when you can display a whole address in one > view ;-) One field is no problem, it is a complete sub tree. What I mean is that if you want to use views that take nodes from several possibly overlapping sub trees, it becomes much more complicated to manage e.g. validation and I wonder if it is worthwhile, remember to stay away from FS ;) > > If > > on the other hand the instance is based on a lousy model, why > don't build a > > new one for our wizard, then we can always use xslt to > transform our view > > model to the instance model. > > too much work... So, the guy who is writing XSD, without knowing Java and XSLT complicates your life that much ;) > didn't you aggree on keeping it simple? I like to have as > little files as possible for having a clean (SoC) sollution. I want to keep thing simple. We might have different ideas about what is simple. <snip/> > Daniel, I hope you don't resent it but I'm thinking we should stear in a > different direction if we want to be as elegant as Struts... I think we should strive for something much more elegant than struts ;) /Daniel Fagerstrom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
