On Tue, 26 Mar 2002, Ivelin Ivanov wrote: > > Torsten, > > I looked at your README and code. > Man we're so much on the same page. > Let's turn it over !!!
good to hear :)) > Did you have a chance to look at my latest stuff? Yes... but only a brief look - looks good though > Is there a way we can get my source in scratch pad so that more people can > play with it. prepare it for the scratchpad... looks like you can commit it soon by yourself ;) (otherwise send me the patch - altough I'd prefer if we could merge things first and don't need two seperate areas in the scratchpad) > Right now only a few of us that follow the thread know that it exists > somewhere on sourceforge. yeah - too bad :( > > > 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? > > Not with XSD. Schematron rules ! See my response to Konstantin. > Relax NG can't do it either, correct ? Not quite sure... but tend to say no :( > > 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. > > > > 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 saw it, it's all right. Options are good for people to choose from. > > However we need to pick one validation language for the wizard. > You know my vote:) What do you guys think, which one should we use? Well, true for the first place... I like add different version later. So people see what is possible > I have a few comments for your samples: > > If you look at my code , you'll notice that I already have implementation > for all your key interfaces: > Instance (JavaBean or DOM node impl), Preceptor (schematron.Validator), > Constraint (Schematron schema). > > I would suggest that we try to hide as much of the complexity from the user > as possible. aggreed > The only thing which I believe is neccessary to expose to the user is a > Validator/Preceptor interface and a ValidationResult interface (with its > elements). by "user" you mean developers, right ;) > It is not necessary for the user to see an Instance. All they need to pass > in to the Binder/Populator is a JavaBean or DOM node, or a mixed version of > the two. Then know the Validator interface, so they can call a factory: > ValidatorFactory.newInstance(SCHEMA_TYPE); > and then call > Validator.validate(instance, properties) I think we aggree on this one. If you look at the PreceptorDemoAction you should see what I mean... all you do with the instance is you create it. > Again, the instance doesn't have to be anything special but a JavaBean or > DOM node. aggreed > Forcing people to implement an Instance interface or a Constraint interface > is just to much hardship. > I don't mind if we use them internally for the framework though. You must have gotten something wrong :) ....noone wants to force anyone to implement the Instance interface. It's just a way to drop in different types of stores. As you might already have noticed I already implemented 2 examples. * a very simple DOM * a Bean store Now if someone wants to store his form data somewhere else... (EJB whatever) he can drop in an implementation. But we usually will only ship with the two common ones... Same for the constraints. You only need to implement constraints when you add another validation schema (Preceptor) that hides the actual implementation from our framework. > On the model.xml: > > Don't you think we can use Konstantin's work on XForms to implement a > standards based solution instead of home grown: Well, this is not standard vs homegrown since I like to see different Preceptor implementation (especially some standard ones) but more a question of separation. If we could create a XFormPreceptor then you could easily use the XForm syntax for describing your forms - viola. See why I want this to be pluggable? > <i:insert/> > > can be replaced with any of the available <xsl:include document> or > castorTransformer insert or DomReaderTransformer > within the instance tag of an XForms markup. No, not really. <xsl:include> is something completely different. Of course also the castorTransformer could be used for the BeanInstance. But that just a different view onto the same data. The InstanceTransformer does handle things more abstract. And actually I think it's easier for people to learn. It's all the same no matter if you use a bean or dom or whatever. (And we need a transformer anyway - so why not expose the toSAX() method?!) > <r:render/> > <f:textbox/> > > have alternative XForms tags as well. (not render :) render is not related... wait until you see my next contribution ;) But it's not a full XForms implementation so why use their syntax? Well, actually I don't really care since the syntax is quite similar... -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
