Re: [RT] Web Wizard Best Practices

[Ivelin Ivanov <iv...@iname.com>]

Jeremy,

I've tried your latest piece of work. I think C2 needs more demos like
<slash-edit/> .

As I was looking through the code I realized that earlier I might have been
trying to fit one hat to all sizes.
Oh, didn't you say just that ;->

All right, having that said though, I still believe that both transofmation
validation and action validation can work together.

Consider the following scenario:

Let's say we're doing a cocoon feedback wizard (proposed by Torsten), where
the developer enters feedback information on the first one or two pages and
fills in contact information on the last page.

Welcome -> Fist feedback page -> Second Feedback Page -> Contact
Information -> Done

Now lets assume that the last page has the form:

<contactInfo>
  <name/>
  <email/>
  <telephone/>
  <address/>
</contactInfo>

Of these only name and email are mandatory.

When a new user goes through the wizard he/she will complete each page and
press the Next button on the wizard.
I would think that the validation on each page would be done by the Action
handling the form using Schematron (read: XSD, Relax-NG, Schematron, DTD or
whatever other Standard XML validation schema is preferred) document and
application specific business logic (like: does the db have a record of the
same email already entered by someone else, if so, ask the user to either
login or enter another email).
Of course the result of the action validation will either take the user to
the next page or the same one with highlited errors.

Now consider that an existing user is logged in and decides to fill in a new
feedback form.
The steps for the feedback pages are the same. The interesting part is the
last one which is supposed to ask the user for contact information. Since
the user has already been registered and is logged in the system, the
contact information will be prepopulated, expecting the user to eventually
just edit some of the fields or leave them unchanged.
Now lets assume that between the user's registration and the current
feedback wizard a business rule was changed in the system. Not only the name
and email, but now the telephone is a mandatory field.
Well in this case I think that a Schematron validation in the pipe which
loads the contact info from the db and displays it in the HTML page is more
appropriate. This way the user has a chance to see the new business rule,
Before submitting the form.

Ok, now what was my point.
1) Only one validating schema document was used for both scenarious.

2) It was applied at the appropriate points in the system, depending on the
circumstances. This flexibility allows the Action to apply not only the
Schematron validation but also an additional business logic rule. Such
business rule is specific to the database entry point, but makes no sence
for the data extraction pipe.

3) Applying the validation Before the data enters the database as well as
after it is Extracted, helps maintain a correct implementation of the
read/write business logic. Such validation practices can be particularly
useful during development.
It's almost like taking the good old assert (or Eiffel pre/post) keyword to
the next level.

Since there are plenty of comlex validation scenarious in the real world,
extending the pipeline functionality to allow for validation branching will
blur the line between logic, content and presentation, that the sitemap is
intendet to control in the first place.
(This last sentence is like shooting myself in the foot :>. Although I'm
still not sure that a simplified XPath selector component wouldn't be
useful)


Does this make any sence ?


Cheers,

Ivelin


----- Original Message -----
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Sunday, March 17, 2002 4:02 PM
Subject: Re: [RT] Web Wizard Best Practices [was: Dynamic Schematron
validation works!]


> At 11:40 am -0600 17/3/02, Ivelin Ivanov wrote:
> >Jeremy,
> >> Not wanting to be negative or anything ... but we have quite different
> >> approaches driven by different needs, we may or may not be able to
> >> reconcile them.
> >
> >That's perfectly fine with me.
> >Don't you think we should be able to agree on a problem that satisfies a
> >common subset of our real world scenarious which may be quite different
for
> >everyone.
> >We can still end up with to 2 different possible solutions and offer
these
> >as two alternative patterns.
> >My issue with the current stage with C2 is that there are no best
practices
> >documents.
> >Most recently successful technologies have these documents which improve
> >their popularity and recognition by helping developers be more
productive.
>
> I agree, I ought to be able to do that ..... it's just I am turning the
> project on it's head at least once a day ..... still experimenting too
much
>
> >> It does not really matter right now, we will _all_ learn from both
> >attempts
> >
> >That's one certain thing !
>
> That's how cocoon has grow
>
> >> What I mean more specifically:
> >>
> >> As I understand it .... you re trying to make a generic system
(partially
> >> influenced by previous work done attempting to implement the XForms
> >> standard) for building complex business objects.
> >>
> >> Furthermore you are trying to make your _sitemap_ adapt itself to the
> >> progress of the transaction.
> >
> >Actually Torsten has a stronger view on this approach.
> >I mostly agree with his ideas, though there are a few things we'll need
to
> >iron out in the coming days.
> >
> >I definitely want to understand your technique though. Don't want to rush
> >into a dead end street.
>
> You don't have a dead end street, the direction Torsten is going in could
> lead to new ways of using Cocoon, just as much as mine might ;)
>
> >I'm mostly driven by the fast developments in the web services area.
> >Having faced an actual problem of converting a complex Web UI portal into
> >one that offers almost all of its UI functionality through web services,
I
> >know that this turned out to be very hard while it could have been real
> >easy.
> >
> >My humble vision is that in the near future successful web-app servers
will
> >be
> >able to seamlessly integrate with web services. Web services already know
> >how to handle xml <-> object binding.
>
> Well that's cool stuff
>
> >Cocoon is a mature and sophisticated container and its future will be
even
> >brighter if it allows for existing Web UI portals to offer their
> >functionality through web services with minimal investment.
>
> Cocoon is much more mature as a publishing engine than a webapp engine.
>
> >> I on the other hand am trying to make generic patterns for assembling
> >> sitemap and XSLT components, as an example of how to add the ability to
> >> edit your own existing assets, to an existing publishing project.
> >
> >I find this exciting and would certainly like to follow the development.
> >While working on these patterns I assume you will try to keep the lines
> >between presentation, content and logic bright and sharp.
> >
> >>
> >> What's more, I am implementing my logic differently; by having
> >transformers
> >> modify the _content_ of the pipeline to adapt to the progress of the
> >> transaction.
> >>
> >> Both techniques are very interesting in their own right!
> >
> >Have you checked this in? Where should I look?
>
> it's in cvs now
>
> >> If I had access to the stuff you are doing now, 12 months ago, I'd be
> >> dancing in the streets! It was JUST what I wanted for the Crudlet
project
> >I
> >> was working on, where we had large and complex JavaBeans to fill in and
> >> manipulate, requiring multiple forms to do the job.
> >
> >I came across Crudlets recently and found it interesting, but it seemed
like
> >there was no activity for quite a while.
> >What is the current status?
>
> May she RIP
>
> >> If you were to follow my pattern (which I am not suggesting, this is
just
> >> an illustration) you would:
> >>
> >> 1. Generate an Instance
> >> using XSP or RequestGenerator + XSLT etc.
> >>
> >> 2. Validate the Instance.
> >> using the delightful Schematron (thanks!)
> >
> >so far so good.
> >
> >>
> >> 3. Adapt the Instance (depending on validation result) into tags for a
> >> CastorTransformer, which makes/modifies/prods your bean.
> >
> >The CastorTransformer marshalls a JavaBean into XML document. Currently
it
> >only "prods" but does not "make/modify".
>
> Sorry, that should have been makes/modifies/prods/reads :)
>
> >How would you bind the XML data from 2. into JavaBeans in the business
> >domain?
>
> By un-marshalling the xml (you have just generated and validated) in (a
> new) CastorTransformer, specifying a mapping if required.
>
> The CastorTransformer would act either as a producer or a consumer of XML,
> depending on what tags were in it's stream.
>
> Writing XML un-marshals to a a Bean, Reading XML marshals from the Bean.
> Something else invokes methods on the Bean.
>
> You ought to be able to make/do/destroy any number of objects all on the
> same pass of the Transformer if you need to .... by having multiple castor
> tags in the stream.
>
> Even (Sylvain, you listening? ;) implement Castor access as a
> WriteableSource instead of a Transformer, you make up a psuedo protocol to
> read, write, prod.
>
> >> 4. Adapt the Instance (depending on Castor result) into whatever your
next
> >> stage needs to be
> >
> >I assume you mean adapt through XSLT ?
>
> Yes
>
> >> I do not think we are duplicating effort.
> >> I think both of these efforts will (at the very least) prove to be
useful
> >> examples for other developers, regardless of the final outcome.
> >>
> >> As long as we keep sharing our ideas publicly (as has happened to great
> >> effect so far!) we have a win-win situation.
> >>
> >> I am not convinced that one pattern can solve every problem in this
realm
> >> .... there is still a lot to explore ....
> >
> >Definitely.
> >Let's keep it moving and close the subject this time.
> >It would be sad to see this discussion dead end like the other ones which
> >tried to tackle the same problem in the last 2 years.
>
>
> +1
>
> regards Jeremy
> --
>    ___________________________________________________________________
>
>    Jeremy Quinn                                           Karma Divers
>                                                        webSpace Design
>                                             HyperMedia Research Centre
>
>    <ma...@mac.com>     <http://www.media.demon.co.uk>
>    <phone:+44.[0].20.7737.6831>             <pa...@vizzavi.net>
>
> ---------------------------------------------------------------------
> 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

[Sam Robertson <xm...@yahoo.com>]

So Ivelin, if I understand you correctly,
are you suggesting that we would have two points of
validation?

1) when the user submits a form via 'action'.
2) when the information stored in the db (or wherever)
is displayed to the user using transformation
validation.

Well for (2), I'm not clear on why validation is
needed. 
The user hasn't even had a chance to do anything with
the information presented to him/her.  If the
information was maintained in the database, it would
need to be valid (I hope).  If some business logic
changed later on, then at the time that the user
submits the form, the validation would take place,
wouldn't it?  Why would we need another validation
before the submission?

I'm having a lot of difficulty understanding where to
place validation when dealing with XML databases like
Xindice.  I would think that it should only be in one
place.  So in your example, whether or not an email
address EXISTS in the xml database OR whether the 
email address entered is VALID -- should happen in one
place.  AFAIU, currently no such unique constraint
validation is offered by these databases.  If anyone
knows otherwise, please let me know.  So in this case,
I would have to get all email addresses in the xml 
documents into a hash or use some DOM API during the
'action', then make sure that the new one that is 
being inserted doesn't already exist.  Then perform
the insert using the XMLDBTransformer. 
Well wouldn't it be really cool (and faster!) if I
could do both the unique key validation and the insert
in one place?

Sorry if this email leans more towards xml databases. 
I need some help clearing these concepts and
especially why something like this doesn't already
exist so please go easy on me.

Ivelin, I have tried your new xmlform example and it
rocks!  Waiting to see Torsten's examples now.

Regards,
Sam

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

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