On Jan 2, 2008, at 1:36 PM, Mike Schrag wrote:
>> xmlns:m = "http://paceap.com/soap/";
>>
>> or
>>
>> transactions..ountTunnel =
>> "AdminTransactionSummary;encryptedPrimaryKey;assetID";
> These are both sort of tricky situations, but there definitely
> should be a way to do it. I'll give it some thought.
Well, if // VALID just worked for both sides, that would be ok by me.
A checkbox on the rules (apply to key) would also work, but separate
rules for values vs. keys would be better presentation. I actually
thought the validation rules were broken for the longest time until I
realized it was only looking at the _values_, not the _keys_; 99% of
my values validates, its the strange key formats that bitch. But I'm
stuck with the strange key formats, because we have keys that are
based on the results of previous key paths. That is,
"transactions..ountTunnel" comes about because we pass in
"transactions..ount" to another binding. Plus the occasional legal
binding like "SOAP-INC".
While I suppose you could make the rules much more complex, and have:
Component Key Value
In practice, you'd need to have a "NULL" match to indicate regular
validation. That is:
.*SOAP.* xmlns:m <blank>
Would say "the key is valid, but dunno about the value", while
.*SOAP.* xmlns:m .*
Would mean it wouldn't even look at the value.
But that seems like it would make the rules unnecessarily complex.
Better to either have two lists, one for keys and one for values
with //VALID being a global override.
For that matter, I only have one of these, but I have a component:
foo: PageWrapper
{
}
The problem is that PageWrapper is defined in a different,
downstream project. Which is perfectly legal, because the lookup for
the PageWrapper component is done at runtime, but the validator
assumes that component lookup only functions upstream. So //VALID
should work on the component name level as well...
Pierce
This archive was generated by hypermail 2.0.0 : Wed Jan 02 2008 - 16:02:36 EST