Ivelin Ivanov wrote:
> Although on the other hand, it will be nice to use XInclude instead of
> entities,
> provided that there is a good implementation in Cocoon.
Concerning a Cocoon XInlcude implementation:
I have migrated my own XInclude-Processor onto Cocoon,
because the existing one missed some features I needed, e.g.:
-Loop detection
-Exception handling: FileNotFound, Timeout, NotWellformed, ...
-Caching
-Resolving arbitrary depth
and I didn't have time to modify the existing one, which is shipped
with Cocoon.
The problem is that I wrote it about two years ago and it would
need some refactoring (it's DOM based, which means I extended the
AbstractDOMTransformer). On the other hand it's very stable and
real-world proven. I am currently using it for Wyona and it works
very fine so far.
In case you are interested I can send you the code or just download
the newest version of Wyona (http://www.wyona.org).
All the best
Michael
>
>
>
>
> ----- Original Message -----
> From: "Ivelin Ivanov" <[EMAIL PROTECTED]>
> To: "Ivelin Ivanov" <[EMAIL PROTECTED]>; "Ovidiu Predescu"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Saturday, June 08, 2002 8:08 PM
> Subject: Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating
> Transformer)
>
>
>
>>Ovidiu,
>>
>>I think I have answered my question about step composition.
>>Since Anteater is an Ant extenstion, the method used by WebTest (and
>>
> Latka)
>
>>is applicable here.
>>
>>We can just use external XML Entities to reference test steps.
>>Although not the most elegant mechanism, it is simple and works.
>>
>>See here for example:
>>http://webtest.canoo.com/webtest/samples/ffo/NatPerSingle/MostSimple.xml
>>
>>
>>I am still waiting for response on the validation syntax and JUnit report
>>feed.
>>
>>
>>
>>Ivelin
>>
>>
>>----- Original Message -----
>>From: "Ivelin Ivanov" <[EMAIL PROTECTED]>
>>To: "Ovidiu Predescu" <[EMAIL PROTECTED]>;
>><[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>>Sent: Friday, June 07, 2002 11:48 PM
>>Subject: Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating
>>Transformer)
>>
>>
>>
>>>I will be interested to contribute some code.
>>>The validator package is totally independent of Avalon.
>>>It only needs commons-jxpath.jar
>>>
>>>The package is org.apache.cocoon.components.validation
>>>
>>>I guess I can just zip up the files in the package for anteater.
>>>
>>>I would like us to work out the exact syntax before starting, though.
>>>
>>>How do we plan to generate junit reports.
>>>Right now I don't see a nice way to interrupt a test, if there was a
>>>validation error, and jump straight to the junit reporting.
>>>
>>>I have also asked a question about reusing steps among test cases.
>>>How do you suggest this can be done?
>>>
>>>Once we work out the architectural problems, I'll move to coding.
>>>
>>>My sf.net login is "ivelin"
>>>
>>>
>>>
>>>
>>>Ivelin
>>>
>>>
>>>
>>>----- Original Message -----
>>>From: "Ovidiu Predescu" <[EMAIL PROTECTED]>
>>>To: "Ivelin Ivanov" <[EMAIL PROTECTED]>;
>>>
>><[EMAIL PROTECTED]>;
>>
>>><[EMAIL PROTECTED]>
>>>Sent: Friday, June 07, 2002 10:18 PM
>>>Subject: Re: [VOTE] Schematron validator in Anteater (and
>>>
> Cocoonvalidating
>
>>>Transformer)
>>>
>>>
>>>
>>>>Ivelin,
>>>>
>>>>This sounds very interesting, are you interested in adding this
>>>>
> feature
>
>>to
>>
>>>>Anteater and writing some documentation for it? If you're interested,
>>>>
> I
>
>>>can
>>>
>>>>make you a committer to the project, so you can develop more easily.
>>>>
>>Just
>>
>>>>let me know your SourceForge account.
>>>>
>>>>The way I'd see this added is through an additional package in CVS. As
>>>>
>>I'm
>>
>>>>not familiar with the internals of the validator, I can't comment much
>>>>
>>on
>>
>>>>how this can be integrated. Is the validator implemented as a
>>>>
> component
>
>>>>using Avalon? If so you'd need to change it to match the Ant style of
>>>>writing extensions. If exactly the same code from Cocoon can be reused
>>>>unmodified in Anteater, then perhaps the best option is to build a jar
>>>>
>>>file
>>>
>>>>in Cocoon, and just drop it in Anteater's lib/ directory.
>>>>
>>>>Cheers,
>>>>Ovidiu
>>>>
>>>>On 6/7/02 4:51 PM, "Ivelin Ivanov" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>>
>>>>>=================================
>>>>>|| VERY LONG !!! ||
>>>>>=================================
>>>>>|| AND INTERESTING. ||
>>>>>=================================
>>>>>
>>>>>
>>>>>I am surprised that there is not much interest in the Cocoon
>>>>>
> community
>
>>>for
>>>
>>>>>Anteater. What do people use for web apps functional test suites?
>>>>>There are a few other open source test tools, but I think Anteater
>>>>>
> has
>
>>>great
>>>
>>>>>potential. Especially for Cocoon apps.
>>>>>
>>>>>So, let's begin:
>>>>>
>>>>>
>>>>>
>>>>> - 1 -
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>While Anteater is still not solidified and has a relatively small
>>>>>
> user
>
>>>base,
>>>
>>>>>I would like to suggest an architectural change, which is compatible
>>>>>
>>>with
>>>
>>>>>Anteater's values, but will hopefully
>>>>>improve it in the following areas:
>>>>>
>>>>>1) standartization
>>>>>2) learning curve
>>>>>3) cross project code reuse
>>>>>4) maintainance
>>>>>
>>>>>The ideas is to use references to schema documents of standard XML
>>>>>
>>>languages
>>>
>>>>>(like Schematron, DTD, XML Schema, Relax NG) for response
>>>>>
> validation,
>
>>>>>instead of supporting a proprietary grammar.
>>>>>I suggest that we use the org.apache.cocoon.components.validation
>>>>>
>>>package
>>>
>>>>>which is an independent component in Cocoon's main tree and is used
>>>>>
> by
>
>>>>>XMLForm.
>>>>>The Schematron implementation is already available and I think it is
>>>>>
>>>quite
>>>
>>>>>suitable for Anteater, because Schematron is a superset of
>>>>>
> Anteater's
>
>>>match
>>>
>>>>>element.
>>>>>To be precise it is a superset of the validating use, i.e the cases
>>>>>
>>when
>>
>>>>>match is used to assign value to a "result" property. Asigning
>>>>>
> values
>
>>>within
>>>
>>>>><match/> to other properties which are used for subsequent requests
>>>>>
> is
>
>>a
>>
>>>>>separate concern.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - 2 -
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Schematron was specificly designed for partial, multi-phase
>>>>>
> validation
>
>>>and
>>>
>>>>>user friendly error reporting.
>>>>>
>>>>>I'll explain how points 1-4 above are addressed by this proposal:
>>>>>
>>>>>1) Schematron is relatively popular. There are a number of articles
>>>>>
> in
>
>>>>>popular magazines which promote Schematron over other validating
>>>>>
>>>schemas.
>>>
>>>>>2) Schematron is very easy to learn. Specification and tutorials are
>>>>>availbel. There is also supporing discussion groups with decent
>>>>>
>>response
>>
>>>>>time.
>>>>>3) Schematron is used for a number of projects. For example there is
>>>>>
> a
>
>>>>>complete RSS 1.0 validating schema available on the RSS site.
>>>>>http://home.freeuk.com/leigh.dodds/rss_validator/
>>>>>XMLForm is using schematron extensively as well. Slash-edit is
>>>>>
> another
>
>>>>>example.
>>>>>4) Maintainance of Schematron documents is easy. Minor local changes
>>>>>
>>are
>>
>>>>>made as the underlying (validated) model changes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - 3 -
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>5) Bonus ;)
>>>>>
>>>>>Here is one additional reason why I posted this proposal.
>>>>>Validating Schematron documents can be referenced in a transparent
>>>>>transformer prior to a page serialization.
>>>>>This can be useful in development and QA, to catch and report bugs
>>>>>
> in
>
>>>>>content (HTML, WAP, XML, etc.) during navigation.
>>>>>
>>>>>Searching for problems in a broken HTML page (or other xml markup)
>>>>>
> can
>
>>>be
>>>
>>>>>painful.
>>>>>Instead of searching for the missing tags or label or icon, the
>>>>>
> tester
>
>>>(or
>>>
>>>>>developer) will see a meaningful error report in place of the actual
>>>>>
>>>page.
>>>
>>>>>After testing certain pages time and again, the eye tends to ignore
>>>>>
>>>elements
>>>
>>>>>peripheral to the currently tested feature.
>>>>>If there is an underlying validating document which is applied
>>>>>
> before
>
>>>>>display, then things may be easier. The developer (tester) has to
>>>>>
> only
>
>>>make
>>>
>>>>>changes to it when the page structure changes.
>>>>>The rest of the time this document will be a safeguard of unexpected
>>>>>problems caused as side efects by the development of other features
>>>>>
> or
>
>>>bug
>>>
>>>>>fixes or another one of the infinite other possible reasons.
>>>>>The transformer applying the validating document can be, of course,
>>>>>
>>>turned
>>>
>>>>>off in production.
>>>>>
>>>>>Now the next interesting part. The forementioned validating
>>>>>
> documents
>
>>>can be
>>>
>>>>>referenced just as well by Anteater regression suites as they can by
>>>>>
> a
>
>>>>>pipeline embedded validating transformer.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - 4 -
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>As a quick thought, this is how an Anteater script may look:
>>>>>
>>>>><?xml version="1.0" encoding="utf-8"?>
>>>>>
>>>>><project name="calc-test" default="calc">
>>>>>
>>>>><!-- Simulate the behavior of a user that opens a browser, starts
>>>>>the calculator example, and goes back in the processing several
>>>>>times. -->
>>>>><target name="calc">
>>>>> <property name="calc"
>>>>>
>>value="${cocoon}/samples/flow/examples/calc/"/>
>>
>>>>> <property name="schema-doc-ns"
>>>>>value="http://www.ascc.net/xml/schematron"/>
>>>>> <property name="schema-doc-url"
>>>>>value="${cocoon}/samples/flow/examples/calc/sch-report.xml"/>
>>>>> <http description="Test the 'calc' JavaScript implementation">
>>>>> <httpRequest href="${calc}/">
>>>>> <match>
>>>>> <xpath select="html/body//form/@action" assign="cont1"/>
>>>>> <validate phase="page1" assign="violations">
>>>>> </match>
>>>>> </httpRequest>
>>>>>
>>>>> <echo>result = ${violations}</echo>
>>>>> </http>
>>>>>
>>>>>....
>>>>>
>>>>>Then the Schematron document would be something like:
>>>>>
>>>>><schema xmlns="http://www.ascc.net/xml/schematron";>
>>>>>
>>>>> <title>Schema for the Calc example</title>
>>>>>
>>>>> <phase id="page1">
>>>>> <p>first page check.</p>
>>>>> <active pattern="form-present"/>
>>>>> </phase>
>>>>> ... other phases ...
>>>>> <pattern name="Test for HTML form element" id="form-present">
>>>>><rule context="/">
>>>>><assert test="//form">
>>>>> Form element expected on this page.
>>>>> </assert>
>>>>><assert test="//form/@action">
>>>>>Form element must have action attribute.
>>>>> </assert>
>>>>></rule>
>>>>>... other rules ...
>>>>></pattern>
>>>>> ... other patterns...
>>>>>
>>>>> </schema>
>>>>>...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Where the validate element will use the validation package to apply
>>>>>
>>the
>>
>>>>>schema against the document.
>>>>>The violations can be then nicely integrated in the JUnit reporting
>>>>>
>>>package.
>>>
>>>>>
>>>>>
>>>>>If there are enough votes I'll contribute some of the work myself.
>>>>>Help would be certainly appreciated.
>>>>>
>>>>>
>>>>>Thanks for reading this far.
>>>>>
>>>>>
>>>>>Thoughts?
>>>>>
>>>>>
>>>>>-= Ivelin =-
>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
