Torsten,
> > 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 Sure. Options are good. I'll provide the schematron schema for the demo wizard, with your input of course. > > 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 ;) Now you know I'm dealing with user requirements too much lately ... ;) > > 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 I'll look more carefully at your code and will propose some way to intergrate. If you have something on your mind in this direction, let me know. > > 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 My mouth is faster then my mind. I'll reexamine the examples. Sorry. > > 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... Yes. JBeans and DOM should be enough for a first release. > 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. That sounds really good. Now I need to understand how to plug in my impl. > > 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. Ok. I guess I'll perephrase my request then :) We should provide an implementation that is closest to popular standards and we shuold make that part of our best practices demo. And the other 5% of developers can still plug in their own impls. Although I'd much rather focus on the 95% in the first release. > 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 may be off a bit on the concepts, so I hope you can clarify some more for me. I thought XForms is going to be used outside of the binding and validation code. Konstantin can polish his XSLT to be able to integrate with instance models and validation results when rendering as well as preserving XPath names for the HTML elements, so that they can go to the right targets on the POST. > > > <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. Sorry, I meant the document function. http://www.w3.org/TR/xslt#function-document I missed XInclude as an option too. > 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?!) Hm. Interesting. I understand your point. Konstantin what do you think? Is the abstraction necessary. > > > <r:render/> > > <f:textbox/> > > > > have alternative XForms tags as well. > > (not render :) render is not related... wait until you see my next > contribution ;) That's a teaser 8-)> > 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... Good point. We won't target full XForms compliance. We will just leverage the standard markup, so that it's easier for people to learn and embrace. It'll also give them a transition path to clients supporting XForms, although that's not a strong plus, because this won't happen in the next 2 years probably. Cheers, Ivelin > -- > Torsten > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
