| Re: [dsdp-mtj-dev] New API proposal for JAD descriptor section IDs |
Thanks for the comments, Craig.
This is not a RIM need. It was meant to be a general enhancement. Previously, the code had to be changed to allow the OTA and Optional descriptors to be organized into sections when combined on the same Optional page. This was done through the use of a dot notation in the pageID. So the idea here, is to formalize that as a general API with a separate entry for the sectionID.
Note the Nokia specific and Motorola specific JAD pages in the org.eclipse.mtj.internal.toolkit.nokia and org.eclipse.mtj.examples.toolkits projects. They have custom descriptor fields on their pages, but these fields cannot be grouped into sections without a lot of extra work. The use case here is for a vendor with a lot of additional JAD descriptors who wishes to group them on their single page.
In truth, no one has been knocking the door down for this and it can be accomplished through additional code. I am happy to put it on ice for now.
Regards,
Jon
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Sunday, September 13, 2009 2:48 PM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] New API proposal for JAD descriptor section IDs
I guess I'm still confused about this proposal. If this is purely to allow RIM to add new information to their own pages, then that could be done with your own extension points. RIM could layer a "common RIM UI" plugin on top of the MTJ UI plugin. This RIM UI could provide the extension points for adding the sections to RIM pages.
While I can conceptually understand something generically handled by MTJ, unless we can address how this would affect the overall layout of the UI I'm hesitant to put this into the base.
If I'm missing something, please help me better understand. I don't want to stand in the way of good contributions and it is quite possible I'm just not getting it.
Craig
Jon Dearden wrote:Hi Craig,
I’ll address these questions publicly for the benefit of community discussion and then add them to the bug.
I believe the answer to both questions is that any “request” for fields to appear in a section is subject to the code for that page allowing it. This is how it works at present for page IDs. As an SDK provider, I can add descriptors to a page of my own making by specifying its ID. I can also add descriptors to any other page if I know its ID, and its code will allow it. If I add descriptors to an existing page, the fields get appended to the end of any existing fields. There may be some question as to whether or not that behavior should be permitted.
In bug 96641, there was a UI change allowing fields from three JAD editor pages to be consolidated onto the one Optional page. This change went into nightly build N20090821. The way this was accomplished was by applying the descriptors to a page ID and a section ID with a dot notation (eg “optional.ota”). This is unpublished behavior and only works because the new Optional Page looks for and honors the section ID. This proposed API change simply makes that behavior explicit. No section IDs are honored unless the page code has been designed to do so. So the UI should not be adversely affected.
The intention of this change is to allow an SDK provider to add descriptors fields to different sections on their own page and this is not currently supported.
Regards,
Jon
--- Comment #2 from Craig Setera <craigsfnet@xxxxxxxxxx> 2009-09-06 15:23:04 EDT ---
I like the general concept of the improvement. Two questions:
1) Will the sections be added automatically if not already there?
2) How will layout of the sections be handled? It seems that if we have
content popping into the pages via extension that the layout of those pages may
be in jeopardy.
My guess is that you've already looked at these issues and I'd like to get your
thoughts on how to "scale up" an extension like this without making the JAD
editor pages looks overwhelming or messy? It seems that every vendor may have
any number of properties that are optional and if everyone contributes them to
the same page we are going to have a UI problem.
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Sunday, September 06, 2009 3:27 PM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] New API proposal for JAD descriptor section IDs
I added my comments to the bug report. In general, I like the idea but I do have some concerns about "scaling" the UI.
Jon Dearden wrote:Hi everyone,
I recently submitted a change [Bug 284452] to the JAD editor pages so that the former pages for OTA Properties and Push Registry properties have now been consolidated under the Optional page. Each of the three now occupies a section on the Optional page.
The MTJ API allows an SDK provider to assign JAD descriptor fields to a page ID but not to a section within a page. All fields are lumped together. In order to make the above change, I had to make a few internal alterations, but this ability to apply descriptor fields to sections was not extended to the public API for SDK providers.
This proposal is that we enhance the API so that SDK providers may apply descriptor fields to specific sections on specific pages. The Extension Element Details editor on the Extensions tab of the MTJ plugin.xml editor would include a new “sectionID” field. Entering data in this field is optional. The field specifies the section ID of the page where the descriptors are to be located. The SDK provider’s descriptors are added to the end of any previous descriptors in that section.
I have opened bug 288530 for this discussion. All comments are most appreciated.
Regards,
Jon Dearden
---
Senior Software Developer, Eclipse Tools
Research In Motion
905-629-4746 x15333 / Mobile: 519 500-23167
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________dsdp-mtj-dev mailing listdsdp-mtj-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________dsdp-mtj-dev mailing listdsdp-mtj-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
