Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] How to improve mapping rules in the Aggregator

Thomas Hallgren wrote:
On 2009-12-07 17:15, Filip Hrbek wrote:
Hi Thomas,

I happy that we are both talking about the same thing :-)

However, what is the advantage of overriding the proxy resolution
mechanism? Isn't it really cleaner
to keep the request parameters in attributes and run the resolution on
demand when needed?

Sure, but isn't that exactly what the proxy resolution is there for?



I think that a proxy is expected to be resolved into a uniquely defined object.
Upon a request to one of object's properties, if the object is an unresolved proxy reference,
it is lazily resolved and the properties are initialized upon successful resolution.

If the resolution is not successful, the properties are not initialized. However,
we need them for the presentation layer. Currently we cheat in that case - we parse the
proxy URI using regexp and create fake properties from it. That's something I don't
like at all.

Instead, I would prefer specifying all the request properties in the request instance
(i.e. current MappedUnit). The presentation of the request would not have to analyze whether
the request is resolvable or not until we want to show status or mapping hints to the user.

When the aggregation build is run, the mapping requests can be easily converted into the
"all.contributed.content" feature's required capabilities (possibly with version ranges,
not only concrete versions), without resolving the requests one by one.

I still can't see any advantage of using EMF proxy mechanism here.

Filip


Back to the top