search

OfficeDev / generator-office

Yeoman generator for building Microsoft Office related projects.
https://www.npmjs.com/package/generator-office
MIT License
891 stars 211 forks source link

Support manifest type choice for WXP #836

Open Rick-Kirkham opened 11 months ago

Rick-Kirkham commented 11 months ago

Not a bug. Enhancement request.

IT'S POSSIBLE THIS WILL BE CANCELLED, DEPENDING ON DECISIONS ABOUT HOW MUCH WE WANT TO INVEST IN KEEPING THE GENERATOR UP-TO-DATE WITH THE UNIFIED MANIFEST.

Please enable the manifest type choice if the user picks Excel, Word, or PowerPoint (not Project or OneNote). Same as we currently have for Outlook.

millerds commented 9 months ago

Requires support in WXP for json manifests. Will be added once that support is in public preview.

yinhx3 commented 9 months ago

Requires support in WXP for json manifests. Will be added once that support is in public preview.

Is it possible to have a built-in JSON to XML conversion tool before then? This would be quite good for the development experience, considering that the Excel custom contextual tabs function is already using the JSON format. And after the launch of WXP for JSON manifests, we actually need such a tool to support existing versions for a long time.

millerds commented 9 months ago

Requires support in WXP for json manifests. Will be added once that support is in public preview.

Is it possible to have a built-in JSON to XML conversion tool before then? This would be quite good for the development experience, considering that the Excel custom contextual tabs function is already using the JSON format. And after the launch of WXP for JSON manifests, we actually need such a tool to support existing versions for a long time.

This is about the plug-in for yeoman the generates projects to make add-in (or office extensions as they are referred to in json manifests). It doesn't do any good to provide customers with a tool to generate projects and can't be used because the support isn't there in the hosts. Same is true for a JSON to XML conversion.

yinhx3 commented 9 months ago

This is about the plug-in for yeoman the generates projects to make add-in (or office extensions as they are referred to in json manifests).

I know. This issue should be placed in https://github.com/OfficeDev/Office-Addin-Scripts. I comment here because there is already a related issue.

It doesn't do any good to provide customers with a tool to generate projects and can't be used because the support isn't there in the hosts.

To be honest, manifest.xml itself and its supporting tools are quite bad. Migrating to json can reduce inconsistencies and optimize the development experience. In web development, we use transpilers and polyfills to make the code adapt to old browsers, so that we will not give up new features because old browsers do not support them.

Same is true for a JSON to XML conversion.

What will happen after the launch of WXP for JSON manifests? Will the project need to include two manifest files?

millerds commented 9 months ago

The project will not need to include both manifest types unless that is what you want. If you look at the Outlook case that is already shipped, you'll find you can use just json or just xml. Ther service that shipped along with the changes to the Outlook client manages the json manifests directly and creates backwards compatible xml manifests that can feed the older clients (through exchange). It can also take the xml manifests, register them, and then pass it on to exchange to feed all the clients as well. There is also a mapping mechanism in the json manifests so the existing store xml manifests can be related to json manifest together. The WXP experience should be modeled after that.

yinhx3 commented 9 months ago

Thanks for the explanation, I'm glad that one day I don't need to write manifest.xml anymore. Hopefully that day will come soon.

Rick-Kirkham commented 4 months ago

@millerds Somehow the plan for the UI of version 3.0 got past me. It looks like the following:

Image

Having two entries that are identical except for the "(preview)" after one of them is confusing. Also, it doesn't convey what is in preview.

What I had in mind with the original issue description, is that the user would choose, say, the task pane project, and only after they choose either Excel, PPT, or Word, would they get a prompt to choose a type of manifest.

Alternatively, we could have the choice of manifest come after they've chosen the task pane project but before they've chosen an application. One problem with that design is that if they've chosen the unified manifest, we'd have to suppress the options for "OneNote" and "Project".

BTW, when they choose the application, we can have an additional option: "Combined Excel, PowerPoint, and Word" to support the template that combines all three.

millerds commented 4 months ago

How would you distinguish between the preview vs. not preview status of the unified vs. xml manifests if you don't have different entries? I always thought that having the different manifest options under the single template type will be the update once support for unified manifest in WXP is shipped and the template branches merged (remember they are separate branches to avoid breaking the main branch for existing template).

Restructuring the order of the questions would be a major change for generator office as internal data hierarchy would have to be reworked. You would still have the problem of needing to designate what is preview and what is shipped.

If you pick the preview template there is an option for "All" when you get to the host choice.

I think "preview" is the terminology we use in general to define things that are available to play with but not shipped. This is what we do in the main applications, but I guess there is more documentation on what is in preview even if it's not in WXP directly. The simplest thing is to update the strings to provide clarity on what is being previewed (unified manifest).