> Done. Hm... It seems that you and Ivelin are doing the same thing but in > quite different ways ;) > Isn't it time to come a consensus in interfaces, sitemap structure etc.?
Yes... that's true - I had almost finished my proof-of-concept prototype when Ivelin spoke up... > Btw, I've found my own wizard demo that I created for my collegues a while > ago and it's based on something like a flow engine (it's called > ProcessHelper). So, I have 3 different implementations of almost the same > thing ;) Hey, we have also another one at hand we called it "dflow" (that's what we are currently using - it didn't stand the test of developers needs in the end;) ...so we have 4 ;) > > So might also want to try the examples... > > Yes, sure, but I'd prefer to have them running from Cocoon samples page (see > http://localhost:8080/cocoon/mount/ - there is a link to 'precept', but I > couldn't find the magic url after that to start your sample. What about a > 'default' url in sitemap or a static HTML page with needed links?). Ok.. I'll add another page. But you might already want to try: http://localhost:8080/cocoon/mount/precept/app/example1.html http://localhost:8080/cocoon/mount/precept/app/example2.html > > <snip/> > > > > > If it supports dependecy checks then 'yes'. An example: is > > it possible to > > > implement such a validation rule "validate 'car-model' > > required field only > > > if the user indicated that he owns one (has set 'has-car' > > field to true)"? > > > > That's what I like to see, too. Although I doubt you can express this > > within a XSD, can you? > > No, XSD does not support this kind of data dependency, but XForms' binding > do. See 'relevant' attribute in my sample XForms.xml. You can define any > dependency that is possible to express with XPath (more complicated cases in > XForms are defined using 'functions', IIRC). hm... it's been a while since I last read the spec - I should have a look into the latest spec... > > I know most people don't like "homegrown" standards that's > > why I made the > > validation pluggable in my approach. So anyone can easily come up with > > what he needs but still support the current "standard" validations. > > And that is cool. From the first glance your interfaces are quite enough for > any kind of validation (single field or dependency checks). Yepp.... that's the idea. Let's keep them as simple as possible. I'd like to see at least a XSchema and Relax-NG implementation. > > As a demo validation I came up with the "easyrelax" > > validation... Although > > it's just an example I have to admit I like it more and more :) > > > > I'd like to use some kind of an XForms-based validation (that takes into > account the form field-set, instance schema and the bindings), but haven't > seen any implementation for it. Hmm... I prefer the idea having some kind of schema as valdiation model... So it would be great if we could merge these ideas... > > > > If we're to solve it and bump Cocoon to the level of Struts > > > > and the next > > > > generation Java Server Faces based app servers, we need > > their help. > > > > > > We need to create a small but real-life sample application > > and we will > > > achieve the level of Struts. Haven't look at JSF, but it's > > based on Struts, > > > isn't it? > > > > Can you give a link for the JSF? > > Here it is: http://www.jcp.org/jsr/detail/127.jsp Thanks! ...doesn't seem to go very much into detail though > > > So, let's start work on a web app now! Your work fills me > > with enthusiasm ;) Yeah, seems we are going at least somewhere :) The lack of form handling has been around for sooo long now... > > Ivelin and me thought it would be a good idea to have a > > feedback wizard as > > sample application. So people install cocoon and they are asked a few > > questions (what system, how the installation went etc.) and > > the feedback > > can be registered somewhere. We then could create some statistics with > > SVG on the cocoon website maybe :) > > Great idea! > If it would not require already installed Cocoon then we could create an > installation wizard for Cocoon ;) Well, let's start with the feedback wizard first ;)) > > We compiled some requirements for such an sample application: > > * should at least 3 pages with a summary as last page > > * should be full i18n. the browser locale should be taken as default > > locale for the application. not only the labels but also > > the constraints > > and error messages should be localized > > It seems that you've found the correct person for this one ;) > And I'll have a chance to try usefulness of my i18n transformer in a real > life application. There are plenty of them, dude :) > > * all types of HTML controls should be used > > * you should be able to navigate through the wizard with > > "next" and "prev" > > buttons > > and be able to cancel the process with a 'return' or 'cancel' button ok > > * as little java programming as possible should be necessary > > to create simple > > forms. > > * use the MVC pattern > > Agree with all of this. But first we should decide whose framework we will > be using. Until that I can take on me the presentation and i18n parts. I don't think my "example1" isn't that far from Ivelin work. Only difference of our approaches I see is the use of "phases" over "xpaths". I actually think phases can easily added if we stick with "xpaths" in the interfaces. If you look into the action there are already "sets" = "phases". It should be really easy to read them from a descriptor! Then we have both... -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
