The plist format specifies a class name to instantiate, though the
selector does just appear to be a string. So as long as you're an
EOKeyValueQualifier (or another built-in) it probably would work.
The problem would be if you have a custom qualifier class entirely
(say you don't have a key and a value, but some other fields), I'm
not sure what happens. I suspect I'm going to have to write our own
string parser ... Custom selectors appears to be incompatible with
Cayenne's model (which has an AST like ASTEquals, ASTNotIn, etc
classes and I don't think I can register new ones for the string
parser to pickup). Soooo... This dredges up the WO classes vs no-WO
classes debate some. Anjo is looking into the executing-code-in-the-
project-classpath thing, but how much do we want to use this once it
works? Personally, I'm OK using it for doing things like SQL Gen
where our API is more string and file based, but I don't know how I
feel about actually trying to use WO classes for like Qualifiers
where we have to wrap UI around them, etc.
On Jul 26, 2006, at 4:23 PM, Anjo Krank wrote:
> AFAIK, a qualifier in a string is nothing more than a selector
> name. There is no real class behind it. For example, I have strings
> with "isInArray:" or even "*~~:" (postgres regex)
>
> These are just given over to the access layer and end up in the
> plugin unless there is some earlier level that translates them to
> sth different.
>
> Cheers, Anjo
>
>
> Am 26.07.2006 um 22:15 schrieb Sébastien Sahuc:
>
>> I hit F4 on EOQualifier. Here is what I got ( I hid internal ones):
>>
>>
>> On Jul 26, 2006, at 12:25 PM, Mike Schrag wrote:
>>
>>> Ugh ... how many of these damn qualifier types ARE there ...
>>>
>>> On Jul 26, 2006, at 3:15 PM, Dov Rosenberg wrote:
>>>
>>>> EOKeyComparisonQualifier
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Wed Jul 26 2006 - 16:32:42 EDT