Because you have to redefine them in controllers. It's really more work especially when there are much. Notably because it's uneasy
for S/R which is a snap for the extends+extends-resource mechanism for lookup.
Why do you find it messy?
Jacques
From: "David E Jones" <[email protected]>
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
