You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ivelin Ivanov <iv...@iname.com> on 2002/03/17 19:00:08 UTC
Re: [RT] Web Wizard Best Practices [was: Cocoon Form Handling]
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>; "Ivelin Ivanov" <iv...@sbcglobal.net>
Sent: Sunday, March 17, 2002 10:50 AM
Subject: Re: Cocoon Form Handling
> On Sun, 17 Mar 2002, Ivelin Ivanov wrote:
> <snip/>
>
> > > ok - then we are on the same track... but please consider the
population
> > > syntax I proposed. I think resetting something is misleading and it
works
> > > fine without.
> >
> > I certainly would. You put a lot more thought into your code than I have
for
> > the snippet above.
> > Can you please paste your code <here/> so that I can match exactly your
> > syntax to the one above?
>
> 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.
>
> 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.
>
> 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?
> 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?
Now I'm torn apart.
Jeremy, do you think both methods can be merged somehow?
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.
Good job Torsten !
Sorry to repeat myself, but would you mind submitting the feedback wizard
requirements which you were thinking about.
It maybe easier if we have a point of reference for our discussion.
Ivelin
>
>
> Later I'd like to see this configurable with a XML descriptor.
> --
> Torsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Web Wizard Best Practices
Posted by Ivelin Ivanov <iv...@iname.com>.
<snip-things-I-understand/>
> >
> > > > > populate(objectModel, "feedbackform",
> > "cocoon-installation/user/*");
> > > > >
> > > > > List errors = validate(objectModel, "feedbackform",
> > > > "cocoon-installation/user/*");
> >
> > Can you explain a bit more why the 2rd argument is XPath.
> > Wouldn't it be more natural to make a call like:
> >
> > Validator v = new SchematronValidator( "mysche-report.xml");
> > ValidationResult vr = v.validate(myJavaBean); // or
v.validate(myDomNode);
>
> But how would you specify exactly *what* from the instance you want to
> validate... (mind the checkboxes)
In the case of the Schematron validator, you would use the "phases" concept.
(SchematronValidator)v.setPhase("no checkbox validation, only name and
email");
v.validate(myJavaBean)
However I see your point and validating parameters should probably be
different for different Validator implementations.
To generalize the Validator interface:
interface Validator
{
public ValidationResult validate( Object );
}
then each specific validator can provide additional setters for preparing
the validate() call.
> > > > Sorry to repeat myself, but would you mind submitting the feedback
> > wizard
> > > > requirements which you were thinking about.
> > >
> > > I did already....
> >
> > I think I haven't received it yet.
>
> I'll have a look into my postponed folder;)
please...
Ivelin
>
> cheers
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Web Wizard Best Practices
Posted by Torsten Curdt <tc...@dff.st>.
On Mon, 18 Mar 2002, Ivelin Ivanov wrote:
> >
> > 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 :)
>
> Not that it's all that important at this stage, but
> shlould we try to use more popular words for naming the classes and the
> functions.
Well, it's not even in the scratchpad ...I have no problem refactoring
the stuff later :)
> Names that sound familiar and can be associated with corresponding names in
> other popular technologies or design patterns.
> This usually flattens the learning curve and lowers the acceptance barrier.
> So names like bind/populate over introspection, and Validator vs Preceptor.
>
> <snip-things-I-like/>
>
> > > > populate(objectModel, "feedbackform",
> "cocoon-installation/user/*");
> > > >
> > > > List errors = validate(objectModel, "feedbackform",
> > > "cocoon-installation/user/*");
>
> Can you explain a bit more why the 2rd argument is XPath.
> Wouldn't it be more natural to make a call like:
>
> Validator v = new SchematronValidator( "mysche-report.xml");
> ValidationResult vr = v.validate(myJavaBean); // or v.validate(myDomNode);
But how would you specify exactly *what* from the instance you want to
validate... (mind the checkboxes)
> if(vr.errors != null) { ...
> > > > getLogger().debug("there are errors on the page");
> > > > return (page(FIRST));
> > > > }
> > > > else {
> > > > getLogger().debug("all constraints are ok");
> > > > return (page(SECOND));
>
> I like the return idea simliar to Struts (again, I know). An action should
> be a pure controller, no View logic in it.
:)
> > > 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...
>
> Maybe if I look at the code, I can come up with one for Schematron.
>
> > > 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...
>
> Some time is fine. But lets not allow it to take another 12 months before
> someone resurrects the vampire 8>
:)
> > > 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...
>
> Your concept handles the input, its the Controller (I assume we all agree
> that MVC is good), where as the BO becomes part of a bigger document during
> the View process, which is outside of the Controller scope. See my example
> with the feedback wizard in the other email. Makes sence?
>
> > > Sorry to repeat myself, but would you mind submitting the feedback
> wizard
> > > requirements which you were thinking about.
> >
> > I did already....
>
> I think I haven't received it yet.
I'll have a look into my postponed folder;)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Web Wizard Best Practices
Posted by Ivelin Ivanov <iv...@iname.com>.
>
> 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 :)
Not that it's all that important at this stage, but
shlould we try to use more popular words for naming the classes and the
functions.
Names that sound familiar and can be associated with corresponding names in
other popular technologies or design patterns.
This usually flattens the learning curve and lowers the acceptance barrier.
So names like bind/populate over introspection, and Validator vs Preceptor.
<snip-things-I-like/>
> > > populate(objectModel, "feedbackform",
"cocoon-installation/user/*");
> > >
> > > List errors = validate(objectModel, "feedbackform",
> > "cocoon-installation/user/*");
Can you explain a bit more why the 2rd argument is XPath.
Wouldn't it be more natural to make a call like:
Validator v = new SchematronValidator( "mysche-report.xml");
ValidationResult vr = v.validate(myJavaBean); // or v.validate(myDomNode);
if(vr.errors != null) { ...
> > > getLogger().debug("there are errors on the page");
> > > return (page(FIRST));
> > > }
> > > else {
> > > getLogger().debug("all constraints are ok");
> > > return (page(SECOND));
I like the return idea simliar to Struts (again, I know). An action should
be a pure controller, no View logic in it.
> > 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...
Maybe if I look at the code, I can come up with one for Schematron.
> > 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...
Some time is fine. But lets not allow it to take another 12 months before
someone resurrects the vampire 8>
> > 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...
Your concept handles the input, its the Controller (I assume we all agree
that MVC is good), where as the BO becomes part of a bigger document during
the View process, which is outside of the Controller scope. See my example
with the feedback wizard in the other email. Makes sence?
> > Sorry to repeat myself, but would you mind submitting the feedback
wizard
> > requirements which you were thinking about.
>
> I did already....
I think I haven't received it yet.
Cheers,
Ivelin
>
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Web Wizard Best Practices [was: Cocoon Form Handling]
Posted by Torsten Curdt <tc...@dff.st>.
> > 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