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.
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
--------------------------------------------------------------------- 