> > 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
