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
jdearden@xxxxxxx
---------------------------------------------------------------------
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
---------------------------------------------------------------------