Michael suggests a new XInclude implementation.
Since we're talking about merging CInclude and XInclude, is someone interested to have Michael's code? I guess Michael should submits a patch in Bugzilla with the code, so whoever is interested can pick it up from there. Ivelin Michael Wechner wrote: > > > 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] > > -- -= Ivelin =- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
