Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Wed, 27 Mar 2002 08:56:19 +0100 (CET)
From: Torsten Curdt <tcurdt@dff.st>
To: <cocoon-dev@xml.apache.org>, Ivelin Ivanov <ivelin@sbcglobal.net>
Subject: Re: Cocoon Form binding and validation [was: RE: SchemoX forms]
In-Reply-To: <03c401c1d550$5c140380$15ca8842@galina>
Message-ID: <Pine.LNX.4.31.0203270829110.20883-100000@mogh.dff.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


<snip/>
> Sure. Options are good. I'll provide the schematron schema for the demo
> wizard, with your input of course.

great!


<snip/>
> > by "user" you mean developers, right ;)
>
> Now you know I'm dealing with user requirements too much lately ... ;)

;)

<snip/>
> 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.

Well, AFAICS the only problem merging the two approaches are the phases.
We need to work out something here...

Problem 1:
  other validation don't have such phases. using phases in the interface
  might be a problem. while xpath is the lowest common denominator. the
  phases then could come from an action configuration.

Problem 2:
  as I stated before: I don't like phases to be inside the preceptor.
  please try to convince me... :)

<snip/>
> 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.

ok

> > 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.

have a look into the xconf snippet. that should help

> > > 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.

aggreed

<snip/>
> I thought XForms is going to be used outside of the binding and validation
> code.

Sorry, was too late last night... You are right:)

> 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 really don't like to propose XForms as "best practises demo" currently
because we have to rely on extension functions in XSLT then. I only see
XForms take off when we have a new XSLT spec and implementations.
Currently it is not possible to transform a XForm into HTML without
extension functions - which IMHO sucks... and is not best practise.

Please have a look into the current example2 and the corresponding
i2html.xsl.

> > 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-)>

...as soon as we have merged our stuff. I'd like to focus on this first :)

> > 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.

yes... anyway most of the tags are from the XForms 1.0 spec anyway
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org