| RE: [dsdp-mtj-dev] New API proposal for JAD descriptor section IDs |
|
The undocumented item is still
undocumented, but is meant to be used internally. It works like this: Normally, if I want JAD
descriptor fields to show up on my page, I specify “mypage” as the
ID and get the fields all on one page. If I want my fields to show up on
another page, I specify the ID for that page and my fields are appended onto
the end of the existing field. Whether it is desirable or not, I can add my own
fields to the end of any fields on a page I know the ID for, even if it is MTJ
internal. This is the current behavior. The undocumented addition
allows the JAD Optional page to group descriptors in sections. It is
accomplished by specifying “optional.optional” and “optional.ota”
as the “page IDs” to place the old descriptor fields into two
different sections on the Optional page. If there is no dot present in the ID,
the old behavior is maintained. From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On
Behalf Of Craig Setera I definitely agree with the concept. I just
don't know how to allow arbitrary UI additions and still keep the UI
"sane". If someone has thoughts on how to handle that, I think
it would be a really useful feature. I think the idea proposed
is a good one, as I think all vendors do add custom fields. I am a bit
uncomfortable that we currently rely on undocumented behavior (is it still
undocumented? There has been a lot of work on the documentation recently.) On Mon, Sep 14, 2009 at 6:57 AM, Jon Dearden <jdearden@xxxxxxx>
wrote: 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
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. 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 I
added my comments to the bug report. In general, I like the idea but I do
have some concerns about "scaling" the UI. 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 / ---------------------------------------------------------------------
_______________________________________________dsdp-mtj-dev mailing listdsdp-mtj-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
---------------------------------------------------------------------
_______________________________________________dsdp-mtj-dev mailing listdsdp-mtj-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev ---------------------------------------------------------------------
_______________________________________________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. |
