Community
Participate
Working Groups
currently, the jad editor extension points can filter the pages that are supposed to be shown. this feature might generate some confusion in the following scenario: - there are more than one implementation of the EP installed - each page is shown in only different conditions the user might see one page in one condition and then the page might not be shown in another. the user can be confused with that. the idea is to remove the filter class and always show all registered pages.
If the EP is defined without setting "vendorSpec" attribute true, like this: <extension point="org.eclipse.mtj.ui.jadEditorPages"> <jadEditorPage class="org.eclipse.mtj.ui.internal.editor.jad.form.JADRequiredPropertiesEditorPage" priority="10"/> </extension> the page will always be shown. another way to always show the page is: set the vendorSpec attribute true, and define a filter like: public class NokiaSpecTester implements IVendorSpecTester { public boolean isVendorSpec(IDevice device) { return true; } } so in this design, we give the authority to the vendor who defines the extension, if we don't want this flexibity, and make the vendor have no chance to "confuse" the user, I'm ok to remove the filter class, but my worry is that there may be too many pages in the editor in the future, and this may also confuse user. I'm not sure where the confusion comes from, different pages for different devices? or some configured attributes disappear: user configured some Moto-specific attributes on Moto-specific page, but he can't find the page where he configured the attributes after he switch the project device to a Nokia device, he just can find those attributes on User Defined page? If we just confuse about the second, how about Deigo's suggestion in the mail list : "if a vendor specific attribute is in the Application Descriptor, we add the vendor page that can handle that attribute. If the attribute is unknown to any vendor, it can be displayed in the User Defined page"
I think my confusion comes from the use of IDevice in the filtering method. What is the thinking of using the device? Is it because we don't really have a higher level "SDK" kind of an object to work from?
as far as i remember from the code, the sdk is just a String that represents the group of devices and there is no object that represent it. as gang said, i also don't see why the user can be confused. if he has two manufacturer specific jad extensions installed on his mtj and if both extensions filter the page by the current sdk (a lot of ifs :)), he can still find and edit the properties on the user defined page and also on the source page that was recently added to the editor. so, nothing is hidden from the user in a way that he can only find the a way to edit the properties switching back to a another sdk (again assuming the the pages are filtered by that). but as i mention, i don't have a strong position about that... if there is an agreement to remove it, i'm ok with that (can't see a reason, but i'm ok). about diego's suggestion, i don't like it too much, since the vendor jad field is not actually the same as the device manufacturer. so i'm not sure if it is a good option to filter the page based on that. :) gep (In reply to comment #2) > I think my confusion comes from the use of IDevice in the filtering method. > What is the thinking of using the device? Is it because we don't really have a > higher level "SDK" kind of an object to work from? >
The reason why I use IDevice in the filtering method: As Gustavo said, the sdk is just a String, and you can get that from the current project device, I used to define the method as : public boolean isVendorSpec(String SDKName), but I'm afraid that maybe the vendor needs some other information to do filtering(such as device name? I'm not sure). (In reply to comment #2) > I think my confusion comes from the use of IDevice in the filtering method. > What is the thinking of using the device? Is it because we don't really have a > higher level "SDK" kind of an object to work from? >
About diego's suggestion, why I think it maybe work, because there is a method for each page: public boolean isManagingProperty(String property), so I can test all the current existed JAD attributes, if there are some attributes can be managed by the page, the page will be shown. So, maybe there is nothing about the relationship between the vendor and device manufacture, it is just about the page. But there is another problem about diego's suggestion, think this scenario: 1. user use the Motorola SDK, and configure some Moto-specific attributes on Moto-specific page. 2. user switch to Nokia SDK, because there are some attributes Moto-specific page can manage, so the Moto-specific page will still show in the editor. 3. user delete all the Moto-specific attributes, close the editor. 4. user reopen the editor, he will find that the Moto-specific page disappear, because there is no attribute the page can manage, and the page don't match the project device. so this may bring another bigger confusion to the user if we do like that. finally, I think I'm also ok to remove the filtering class, if we really don't need that. (In reply to comment #3) > as far as i remember from the code, the sdk is just a String that represents > the group of devices and there is no object that represent it. > > as gang said, i also don't see why the user can be confused. if he has two > manufacturer specific jad extensions installed on his mtj and if both > extensions filter the page by the current sdk (a lot of ifs :)), he can still > find and edit the properties on the user defined page and also on the source > page that was recently added to the editor. so, nothing is hidden from the > user in a way that he can only find the a way to edit the properties switching > back to a another sdk (again assuming the the pages are filtered by that). > > but as i mention, i don't have a strong position about that... if there is an > agreement to remove it, i'm ok with that (can't see a reason, but i'm ok). > > about diego's suggestion, i don't like it too much, since the vendor jad field > is not actually the same as the device manufacturer. so i'm not sure if it is a > good option to filter the page based on that. > > :) > gep
My personal preference at this point would be to remove the filtering. We can always readdress this at a later time to determine the best way to go forward.
does any one has any more comment or we can go ahead and remove it? :) gep (In reply to comment #6) > My personal preference at this point would be to remove the filtering. We can > always readdress this at a later time to determine the best way to go forward. >
+1 to remove
I just removed the filter class on my local machine, but encountered another problem: should we let the vendor know the current project device(SDK)? because one vendor can provide different SDKs, but specific JAD attributes each SDK can provide maybe different, for example, nokia has "series 40 SDK" and "series 60 SDK", and the two support different specific JAD attributes. so we have two options to redesign the interface: 1. don't let the vendor know the current project device. in this case, vendor may have two choices: (1)vendor provides different page for each SDK, such as nokia can provide "S40 specific page" and "S60 specific page". But I'm not sure that whether even different devices in one SDK have different specific attributes, if so, there may be too many pages in the editor. (2)vendor provides one page that contains all specific attributes. 2. remain the original design,let the vendor know the current project device. in this case, vendor may filter the attributes by the device, this maynot acceptable, because different attributes show on the specific page while using different device, this is why this bug is opened :) so, if we always show all pages to the user, maybe we should not let the vendor know the current project device, any suggestions?
My opinion is that we can go with option #1. don't let the vendor know the current project device. The reason is because I assume some developers develop targeting more than one device at the same time, even devices from different platforms/vendors. So they may need to handle various specific attributes at once. I also think that is up to the vendor to decide to contribute one or more pages and group its specific attributes in the way it wants.
I agree with Hugo
ok for me too (In reply to comment #11) > I agree with Hugo >
Created attachment 109625 [details] patch for this bug In this patch, I remove the vendor specific filter from the extension point.
This patch was applied and will be available in the next nightly build.
all bugs we integrated and release on MTj 0.9
