On 3/21/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote:
Peter Hunsberger napisał(a): > On 3/21/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote:
<snip/>
To be sure that I understand your use case I'm going to ask additional questions: 1. What kind of data is stored in these beans? One pulled from config failes, or maybe pulled from database?
Mostly from the database, sometimes from interfaces to external systems. Often massaged by procedural logic so it's not just a normal database call.
2. Are these beans (I guess classes you walk through are beans) generated every request or generated once on startup?
We have a variety of creation patterns, depends on the caching and usage requirements. Some are pretty static, generated at system start up, some refresh on daily cycles and others are very dynamic. We have our own interface that these classes have to conform to in order to avoid using introspection, but they are essentially just POJOs. <snip/>
Yes, I need to ask additional questions. I would like to know why wouldn't you just grab XML (in whatever representation DOM/stream of SAX events) from validation pipeline and return as result of the function _validate if validation failed. If it was successful you could return just null value as indicator. Now logic calling _validate function can pass the XML with validation report to the pipeline that is going to show the report. This way you avoid using "magical black box" in form of request attributes.
With Schematron you've got to dynamically create the actual XSLT that's going to be used to validate the form at the time of validation; you need an entire pipeline just to do the validation. As such, there's no way to get the resultant XML back into the original pipeline without this pattern. Note that you're running the Schematron in the middle of a flow action, you haven't actually started to generate anything to send back to the user yet; you're not even sure what page you're going to be sending back to the user until _after_ the validation completes. If I understand the SOAP case it's sort of similar; you're in the middle of parsing a chunk of XML that's been sent to you and now you've got to determine what you are going to send back to the user. It might be an error or some other type of response, but you won't know until after you've run the other pipeline. The parser is triggering an action that is going to be used by the parser to determine how to continue.
Now, I wonder about validationErrorLevel attribute... Wouldn't it be enough to just set appropriate HTTP status code in validating pipeline and gather it in flowscript? I think that your validation pipeline is sort of service and I think that we already agreed that service pipeline should be as HTTP-compliant as possible. Using HTTP status code is a way to achieve this.
You could pass the simple status around that way. However, with the input/output module you're not actually doing any HTTP so you avoid a couple of layers of extra overhead, you can essentially have a null serializer. More importantly, is how you get the Schematron error report (or the results of the call to the encapsulated system in a SOAP request) back into the original calling pipeline?
To be clear: I do not try to say that your solution is in any way worse than mine. All I want to say that there is different way of solving this problem that does not demands existence of any output module and would like to hear opinion on it.
There might be going forward (that's what I want to ensure), I don't think there is a way to avoid it in the 2.1 code base... -- Peter Hunsberger
