> On Oct 10, 2016, at 12:20 PM, Fabian Peters <lists.fab...@e-lumo.com> wrote:
>
> Hi Tim,
>
>> One other comment. The only downside to this is that it restricts the search
>> string the user can type to a specific attribute instead of the broader
>> concatenated representation which provided a “fuzzier” search. And
>> obviously, requires communication with the user about what they can expect
>> to return matching results.
>
> You can specify multiple attributes, which will then be ORed, e.g.:
>
> 100 : smartRelationship.destinationEntity.name = ‘Product' => searchKey =
> ("productNumber", "title", "comment", "product.supplier.name")"
> [com.webobjects.directtoweb.Assignment]
>
> The advantage being that this allows you to qualify via SQL, not in-memory.
This is great.
keyWhenRelationship is still needed to designate what the user sees in the
search result list.
I appreciate the info - I was having a hard time this week finding the time to
research the changes. Good stuff.
Tim
>
> Also, there's a "log.warn()" statement that should inform you if the
> attribute couldn't be resolved via the model. I've just checked that it's
> getting called, but it doesn't log anything. Maybe that's due to the changes
> to the logging system. I'll have a look at it.
>
> Fabian
>
>> Tim
>>
>>> On Oct 7, 2016, at 11:54 AM, T Worman <li...@thetimmy.com> wrote:
>>>
>>> Fabian:
>>>
>>> Nice! That rule did the trick. Thanks for responding - kept me from having
>>> to dig more. So, I have two rules now that look like:
>>>
>>> 100 : smartRelationship.destinationEntity.name = ‘Product' =>
>>> keyWhenRelationship = "d2wProductDisplayWhenRelationship"
>>> [com.webobjects.directtoweb.Assignment]
>>> 100 : smartRelationship.destinationEntity.name = ‘Product' => searchKey =
>>> “productNumber" [com.webobjects.directtoweb.Assignment]
>>>
>>> Where ‘d2wProductDisplayWhenRelationship’ is a method that returns a nice
>>> user-readable string for the objects in the search results.
>>>
>>> Thanks for the assist!
>>>
>>> Tim
>>> UCLA GSE&IS
>>>
>>>> On Oct 6, 2016, at 11:03 PM, Fabian Peters <lists.fab...@e-lumo.com> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>> ERMD2WEditToOneTypeAhead got a few changes from me, including one to use
>>>> the ERMD2WAttributeQueryDelegate. The change aimed to preserve the
>>>> original behaviour, but looking at the code it may be that it doesn't when
>>>> the data source being used is an EODatabaseDataSource.
>>>>
>>>> Using a rule like this should sort it out at any rate:
>>>>
>>>> 100 : smartRelationship.destinationEntity.name = 'Product' => searchKey =
>>>> "productNumber" [com.webobjects.directtoweb.Assignment]
>>>>
>>>> If it does, I'd still like to have another look at why the default
>>>> behaviour is not being preserved…
>>>>
>>>> Fabian
>>>>
>>>>> Am 06.10.2016 um 23:56 schrieb T Worman <li...@thetimmy.com>:
>>>>>
>>>>> Hello All:
>>>>>
>>>>> I have a relationship sth like:
>>>>>
>>>>> Product(productId) <-> LineItem(productId)
>>>>>
>>>>> I am using ERMD2WEditToOneTypeAhead on the attribute
>>>>> Product.productNumber on a CreateLineItem page. But I’ve also got a rule
>>>>> for keyWhenRelationship like:
>>>>>
>>>>> 100 : smartRelationship.destinationEntity.name = ‘Product' =>
>>>>> keyWhenRelationship = "d2wProductDisplayWhenRelationship"
>>>>> [com.webobjects.directtoweb.Assignment]
>>>>>
>>>>> where Product.d2wProductDisplayWhenRelationship returns a concatenated
>>>>> string that gives a more complete description of the product. Previously,
>>>>> this worked to only display items where Product.productNumber matched the
>>>>> string inserted by the user. Now it only works correctly if
>>>>> keyWhenRelationship=productNumber. The problem with this is that it
>>>>> doesn’t give the user enough feedback about the search results.
>>>>>
>>>>> Also, the behavior I’m seeing is that a whole list of Product objects are
>>>>> returned that do not match Product.productNumber. Which is confusing.
>>>>>
>>>>> I haven’t had a chance to look through recent commits yet but plan to do
>>>>> that later today. Just wanted to check and see - does anybody have any
>>>>> insight about this?
>>>>>
>>>>> Tim
>>>>> UCLA GSE&IS
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> https://lists.apple.com/mailman/options/webobjects-dev/lists.fabian%40e-lumo.com
>>>>>
>>>>> This email sent to lists.fab...@e-lumo.com
>>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com
>>>
>>> This email sent to li...@thetimmy.com
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/lists.fabian%40e-lumo.com
>>
>> <https://lists.apple.com/mailman/options/webobjects-dev/lists.fabian%40e-lumo.com>
>>
>> This email sent to lists.fab...@e-lumo.com <mailto:lists.fab...@e-lumo.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
