Bug 291755

Comment 1 Szymon Brandys 2009-10-19 05:56:50 EDT

Created attachment 149853 [details]
Work in progress 20091019

Comment 2 Szymon Brandys 2009-10-19 06:35:18 EDT

Changes include:
- IResourceFilter#getArguments and all related methods work with Objects instead of Strings
- ModelObjectWriter and ProjectDescriptionReader modified to persist filters in a gentle way

Further issues are:
- the filter ext. point should not use factories. I would use similar pattern to the builder extension, i.e. an abstract class implementing IExecutableExtension
- the filter ext. point contributes matchers (not filters) that are used later by resource filters. This should be perhaps reflected in names. Filters in opposite to matchers carry the action (EXCLUDE, INCLUDE) that should be performed on matching resources.

Serge, what do you think?

Comment 3 Szymon Brandys 2009-10-19 08:36:11 EDT

Created attachment 149866 [details]
Work in progress

Comment 4 Serge Beauchamp 2009-10-19 09:27:14 EDT

(In reply to comment #2)
> Changes include:
> - IResourceFilter#getArguments and all related methods work with Objects
> instead of Strings
> - ModelObjectWriter and ProjectDescriptionReader modified to persist filters in
> a gentle way
> 

I looked at the changes and it look fine.
> Further issues are:
> - the filter ext. point should not use factories. I would use similar pattern
> to the builder extension, i.e. an abstract class implementing
> IExecutableExtension

I'm not sure exactly of what it would look like, but the general idea behind the use of a factory for the filter extension mechanism was to avoid using the extension manager for only creating an instance of a filter to perform the refresh operation.

So as look as it doesn't cause a change in the performance characteristics, I guess it's fine.

> - the filter ext. point contributes matchers (not filters) that are used later
> by resource filters. This should be perhaps reflected in names. Filters in
> opposite to matchers carry the action (EXCLUDE, INCLUDE) that should be
> performed on matching resources.
> 
> Serge, what do you think?

I agree that the current terminology is confusing.  You are right in the sense that the extension point really contributes a matcher, not a filter, so I'm not sure what should they be named, maybe a 'filterMatcher'?  The other fields are quite specific to the resource filters, though (especially the argumentType).

Comment 5 Szymon Brandys 2009-10-20 06:11:57 EDT

Created attachment 149964 [details]
Fix v01

Comment 6 Szymon Brandys 2009-10-28 09:41:24 EDT

(In reply to comment #5)
> Created an attachment (id=149964) [details]
> Fix v01
Fix v01 was released, but I forgot to mention that on the bug.

Comment 7 John Arthorne 2009-12-10 16:20:43 EST

I'm not sure if this bug is done, but just bumping milestone because we are essentially done with M4.

Comment 8 Szymon Brandys 2009-12-11 05:47:21 EST

All blocking bugs are already closed. Further cleanup can be done in M5, so moving it to M5 is fine.

Comment 9 Szymon Brandys 2010-04-21 10:25:24 EDT

Marking FIXED.