http://ofbiz.116.s1.nabble.com/Lookup-target-form-name-tp1579419p1580034.html
Why not just use define requests and views for these lookups from other components? That's the common pattern.
Maybe I'm missing something, but I don't see how that would be any better than request/map pairs for these, plus it seems a bit messy.
> In a 1s time I will use the bad way (easier for now). Then I will create the extends+extends-resource mechanims for lookup, will use it and remove then the unneeded entries in controllers.
> Another better way would be to "fix" the lookup in lookup. But I prefer to do that later...
>
> Jacques
>
> From: "Jacques Le Roux" <
[hidden email]>
>> Hi,
>>
>> While working on the layered lookups
https://issues.apache.org/jira/browse/OFBIZ-3442 (ie replacing all standard/popup lookups by
>> layered ones - for the moment only as much as possible since we have an issue with embedded lookups in lookup
>>
https://issues.apache.org/jira/browse/OFBIZ-3446), I crossed some lookups called from one component to another. And of course some
>> introduce bad dependencies (from order to marketing for instance) or at least not repertoried at
>>
http://cwiki.apache.org/confluence/display/OFBADMIN/Component+and+Component+Set+Dependencies (should workeffort depend on
>> ordermngr?) and are protocol dependent (HTTP, like or target-form-name="/ordermgr/control/LookupRequirement" or
>> target-form-name="/marketing/control/LookupProductStore"). I also found duplicated request/view-map in controllers (for instance for
>> LookupWorkeffort) which is better since it avoid both issues above but is also heavier. So I think we should introduce a syntax like
>> we have for the form extension mechanism: extends+extends-resource. This will not prevent bad depencies issues (which anyway depends of the good will, or rather I guess, awareness of the developer) but will at least make lighter the burden of the second issue.
>>
>> What do you think?
>>
>> Jacques
>>
>>
>
>