On Mon, 15 Apr 2002, Daniel Fagerstrom wrote: > Berin Loritsch wrote: > > Ivelin Ivanov wrote: > <snip/> > > > Would you scetch an example of a non-trivial app which does not use > > > JavaBeans? > <snip/> > > I know I am side-stepping your question, however I have not run into > > a situation where I needed beans at all. So your assumption that every > > non-trivial application needs beans is not valid. > <snip/> > > What you invariably run into in the Cocoon world if you use beans is > > a double mapping: DB to bean, and bean to schema. That approach does > > not scale well at all. Not to meantion there are unnecessary > > conversions that can be the source of problems. KISS (Keep It > > Simple Stupid).
...exactly that's the idea KIASASAP (Keep It As Simple And Stupid As Possible ;-) But not only for the implementation... even more important for the user point of view! > > Keep your memory lean. Beans don't let that happen--or they force > > you to be too smart for your own good. > > 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) <snip/> > ...He stays closer to the XForms standard, which contains the instance as > a part of the xforms document, IMHO the XForms standard mixes concerns by > doing so. Exactly! > Input handling > -------------- > > Even if we would prefer xml data in the post, it will probably take some > time before that is the usual case. By using xpaths as field names we have :) unfortunately > > <map:match pattern="userPost.html"> > <map:generate type="xrequest"/> > <map:transform type="schematron" src="user.sch"/> > <map:match type="pipe-state" test="fail"> > <map:transform src="cocoon:/userForm.xsl?continue=userPost.html"/> > <map:serialize/> > </map:match> > <map:transform type="write" method="overwrite" src="dbxml:/user"/> > <map:transform type="read" src="success.html"/> > <map:serialize/> > </map:match> > > * 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?? what about the checkboxes here? And you have no impact on the document... currently the views in our examples have only those "mapping" in there but that's not for always! And you are still not save with the checkbox problem if you don't use direct population... > * 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... > * The "pipe-state" matcher is pipe state aware (cf. the recent discussions > about pipe aware selectors), i.e. it depends on the state of the > "pipe-state" request parameter as it is _after_ the execution of the > validator. > * If the validation failed the input is piped to the form stylesheet and > sent back to the user. The form stylesheet also have rules for rendering the > error report. > * If the validation succeeds the data is sent to a store of some kind. > * A success report is generated. > > <design-issues> > 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 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? > We have used designs like > the one above for nearly a year in the company I work for and have never had > any problems with indirect population, IMHO this is a concern for the > storage model. SoC! this a problem of the controller... > 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 ;-) > > [------------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 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... Checking against this XSD will make sure all data that will be stored are valid in content and structure. (Note: we wouldn't use XSD because it doesn't satisfy our needs... but there are others and others to come - if not I will push the easyrelax stuff to become more mature...) > 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? (or what else is comming soon for the mobiles? You are lucky when you can display a whole address in one view ;-) > 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... didn't you aggree on keeping it simple? I like to have as little files as possible for having a clean (SoC) sollution. <snip/> Hm... this could make sense... we could build the initial instance from a pipeline... pipeline -> instance <- controller Ivelin, what do you think? This could solve the "build from preceptor" problem... <snip/> > After all the recent discussion about what you not are supposed to do in the > sitemap I can not help to feel like provoking a little ;) > > Principle: "Everything can and should be done in the sitemap" ;) My hackles are raising ;) ...I really hope you are only provoking... <snip/> > Here is our example again: > > <map:match pattern="cocoonSurvey/**"> > <map:parameter name="wizard" value="cocoonSurvey"/> > > <fm:sequence uri-prefix="cocoonSurvey"> > > <fm:label name="start.html"/> > <map:act type="write"> > <map:parameter name="from" src="dbxml:/cocoonSurvey[@id='default']"/> > <map:parameter name="to" src="session:/cocoonSurvey"/> > </map:act> > > <map:call name="form-handling"> > <map:parameter name="query" value="personal"/> > </map:call> > > <map:call name="form-handling"> > <map:parameter name="query" value="system"/> > </map:call> > > <fm:select type="xpath"> > <fm:when test="/system/platform[.='linux']"> > <map:call name="form-handling"> > <map:parameter name="query" value="linuxDetails"/> > </map:call> > </fm:when> > <fm:when test="/system/platform[.='windows']"> > <map:call name="filled-form"> > <map:parameter name="query" value="windowsDetails"/> > </map:call> > </fm:when> > <!-- ... --> > </fm:select> > > <!-- ... --> > > <map:act type="write"> > <map:parameter name="from" src="session:/cocoonSurvey"/> > <map:parameter name="to" src="dbxml:/cocoonSurvey[@id='1234']"/> > </map:act> > > <map:transform type="read" src="success.html"/> > <map:serialize/> > > </fm:sequence> > </map:match> ahhh... seems you are not only provoking ?! =8-|| IMHO this is flow stuff that needs to be separated... > The great unsolved problems > --------------------------- > > There are probably tons of unsolved problems, but two particularly tricky > are: > * Order restrictions: E.g. A user cannot go back after having committed a > certain page. no problem... this depends on the controller... <snip/> > That's more than enough ;) Quite some stuff to read ;) > What do you think? 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... cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
