Jacques, 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. -David On Mar 5, 2010, at 12:21 PM, Jacques Le Roux wrote: > 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" <[email protected]> >> 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 >> >> > >
