> From: Torsten Curdt [mailto:[EMAIL PROTECTED]] > > <snip/> > > > > As long as your stylesheet takes an instance (inserted in > the XForms > > > document from a JavaBean or DOM node through > > > CastorTransformer or a flat XML > > > file) and renders HTML Form with element names which > > > correspond to the XPath > > > locations of the instance elements, then I think it can be a > > > perfect match > > > to the CocoonForm toolkit I built in the last few > > > weeks. It will be probably a good fit for Torsten's framework > > > which we'll > > > eventually integrate with. > > > Appears that your current work is very close to achieving that. > > > > I'll further my work on that (although, I can be back to my > paid work at any > > time and I don't want to leave unfinished stuff). > > > > If Torsten's work in CVS then I'll take a look at it. > > Sure... please take a look :)
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.? 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 ;) > > 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?). > > <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). > > 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). > > 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. > > > 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 > > > So, let's start work on a web app now! Your work fills me > with enthusiasm ;) > > 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 ;) > > 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. > * 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 > * 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. Konstantin > > Hope I haven't forgotten anything... > -- > Torsten > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
