Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Mon, 18 Mar 2002 09:08:29 +0100 (CET)
From: Torsten Curdt <tcurdt@dff.st>
To: <cocoon-dev@xml.apache.org>, Ivelin Ivanov <ivelin@sbcglobal.net>
Subject: Re: [RT] Web Wizard Best Practices [was: Cocoon Form Handling]
In-Reply-To: <003301c1cddd$938c5a80$0c91fea9@galina>
Message-ID: <Pine.LNX.4.31.0203180856240.19391-100000@mogh.dff.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> > see it action or event based rather than page based. a hit on a button
> > generates an event or action that populates and (maybe) validates. So you
> > are completely free to populate or not populate, to validate or not
> > validate on this specific event.
>
> Now I understand. It is actually in line with the recent Java Server Faces
> JSR which is mostly based on Struts, which in turn I appreciate.
> http://jcp.org/jsr/detail/127.jsp

:)

> > > > I have already implemented an abstraction for the binding. So binding
> a
> > > > bean is the same a having no a simple DOM as instance store instead.
> > >
> > > Yammy!
> > > How does one choose JavaBean vs DOM binding?
> >
> > Currently you just use a different implementation. But this should go
> > into a factory instead.
> >
> > look a this multiaction example:
> >
> > public class PreceptorDemoAction extends AbstractPreceptorAction {
> >   public Map introspection(Redirector redirector, SourceResolver resolver,
> Map objectModel, String src, Parameters par) throws Exception {
> >     Session session = createSession(objectModel);
> >
> >     Preceptor preceptor =
> preceptorRegistry.lookupPreceptor("cocoon-installation");
> >
> >     // for a DOM
> >     Instance instance = instanceFactory.createDOMInstance();
> >     // for a Bean
> >     MyBean bean = new MyBean();
> >     Instance instance = instanceFactory.createBeanInstance(bean);
>
> A slight modification maybe. If we deal with a multi-page wizard, then the
> instance may already be in the session.
> So createInstane on request would only happen for the first page, but should
> then be reused for subsequent wizard pages.

exactly... look a bit closer though. this action has a special name called
"introspection" and is only called once - at the start of the flow :)

> >     instance.initialize(preceptor);
> >
> >     // if DOM or Bean you can always use
> >     instance.setValue("cocoon-installation/user/name","enter here");
>
>
> Based on experience, an application would be mostly either all DOM or all
> JavaBeans based.
> These few lines above should be probably replaced with some component
> parameter.

Sure. you would not switch or mix - just wanted to point out it will be
still the same interface - so nothing new to learn ;)


> >     session.setAttribute("feedbackform",instance);
> >     return(page(FIRST));
> >   }
> >   public Map doNext(Redirector redirector, SourceResolver resolver, Map
> objectModel, String src, Parameters par) throws Exception {
>
>
> does the reset() checkbox logic go here?

well, kind of... you don't even need a reset logic here because you
explicitly populate. so no need to bother about the reset. if you say

  populate(objectModel, "feedbackform", "cocoon-installation/user/committer");

and it's not in the request the populator will asume "false" for it :)

> >     populate(objectModel, "feedbackform", "cocoon-installation/user/*");
> >
> >     List errors = validate(objectModel, "feedbackform",
> "cocoon-installation/user/*");
> >     if(errors != null) {
> >       getLogger().debug("there are errors on the page");
> >       return (page(FIRST));
> >     }
> >     else {
> >       getLogger().debug("all constraints are ok");
> >       return (page(SECOND));
> >     }
> >   }
> >
> >
> > So a 3 page wizard basically means 3 event hooks aka methods like the
> "doNext".
> >
> >
> > So if we manage to have a preceptor
> >
> >   public interface Preceptor {
> >     public ConstraintList getConstraitsFor( String xpath );
> >     public boolean isValidNode( String xpath );
> >   }
> >
> > ...wrapping the different validation APIs we can drop in
> > each validating schema: XSD,RELAX,DTD and (with the API link you sent)
> > maybe even Schematron...
>
>
> Oh boy, this is good. Let me think a bit on how to Implement the Preceptor
> for Schematron.
> Do you have one for Relax-NG working?

Well, currently it's not conformant yet but - yes, I have...

> Now I'm torn apart.

:)

> Jeremy, do you think both methods can be merged somehow?

Maybe Jeremy is right - they are different approaches and maybe we should
give it some time to see the real benefits of both techniques before
mixing the concepts... don't know...

> If for example the BO bean becomes part of a document on the pipeline (like
> they usually do),
> then another XSD or Schematron that validates the bean as part of the whole
> document may be applied.
> In which case both Action and Pipeline validation are needed.

not necessarily with my concept...

> Good job Torsten !

Thanks :)

> Sorry to repeat myself, but would you mind submitting the feedback wizard
> requirements which you were thinking about.

I did already....

> It maybe easier if we have a point of reference for our discussion.

sure
--
Torsten


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