Page 1 of 1

Framework name and Profiling condition sets

Posted: Fri Oct 13, 2017 6:52 am
by dcramer
I recently renamed my framework extension to a string that no longer starts with "DocBook". Unfortunately, this has broken the ability to use existing condition sets for all my users. Is there a graceful way to fix this, or is changing the name again so it starts with "DocBook" my only real option?

It's a brittle to tie to the user-facing name of the framework functionality for which the configuration is stored in the user's preferences. Frameworks should have an id of some sort that you don't get to change or are given a stern warning about if you do. I could also see the argument for tying the condition set stuff to the base framework name--looks like that's stored as the "extendedPersistentObjectKey" in the framework.

Regards,
David

Re: Framework name and Profiling condition sets

Posted: Fri Oct 13, 2017 9:26 am
by Radu
Hi David,

If you look in the Oxygen Preferences->"Editor / Edit Modes / Author / Profiling/Conditional Text" page, each table there has a "Document Type" column where you can set a pattern which matches one or more document type names.
So if the patterns used in those tables are something like "*DocBook*" you can name your framework extension something like "My Docbook Framework" and it still be matches.
About having an ID manually set by the end user (or automatically set by the application) for each framework, once you extend a framework you would need to have a different ID anyway so it would be the same problem as matching on the framework name.

We've had requests in the past to allow for an entire profiling configuration (profiling attribute definitions, defined profiling condition sets) to be saved inside a framework configuration. So once you extend the "Docbook" framework you could set up profiling attribute names and condition sets and save those settings directly at framework level, allowing you to impose those profiling settings to all those using that particular framework. We have not yet implemented this but it would probably also help in your case.

Regards,
Radu

Re: Framework name and Profiling condition sets

Posted: Fri Oct 13, 2017 5:15 pm
by dcramer
Yes, I understand how the mechanism works. In our case, the framework originally had a name like "DocBook - Extension Whatever", so the default profile sets were in play when our extension was used. Users apparently built on those, keeping the existing pattern of "DocBook*". When I changed the framework name, all of the existing profile sets became unavailable because the pattern no longer matched. Because the pattern is stored in the users preferences inside ~/Library/Preferences/com.oxygenxml/oxyOptions*.xml, I have no way to change them short of creating an add-on that manipulates their preferences and has them install it.

Having profile sets that exist as part of the framework as well as project-level makes sense--that's true for validation and transformation scenarios, but you still have the problem of binding user-defined profile sets to a given framework and framework extensions.

For now I'll do a hotfix to rename my framework to something that matches the pattern. Perhaps Oxygen could warn you about the connection between profile set names and the framework name when you attempt to rename a framework. For me the problem is that the Framework name does not feel like an important identifier. It feels/looks like a user-friendly label that I can rename at will. The UI and documentation don't make it clear that the name, once chosen, should never be changed.

Regards,
David

Re: Framework name and Profiling condition sets

Posted: Fri Oct 13, 2017 6:24 pm
by dcramer
Oh, the other place this shows up is in the variable ${frameworkDir(framework_name)}}. If anybody had made a transformation scenario as part of an xpr or whatever and used that variable, then changing the name breaks them.

Re: Framework name and Profiling condition sets

Posted: Mon Oct 16, 2017 10:43 am
by Radu
Hi David,
Having profile sets that exist as part of the framework as well as project-level makes sense--that's true for validation and transformation scenarios, but you still have the problem of binding user-defined profile sets to a given framework and framework extensions.
Right, if you would want to fully restrict writers to use only the profiling attribute names and sets that you want to impose, defining them in the framework would be a nice addition though.
For now I'll do a hotfix to rename my framework to something that matches the pattern. Perhaps Oxygen could warn you about the connection between profile set names and the framework name when you attempt to rename a framework. For me the problem is that the Framework name does not feel like an important identifier. It feels/looks like a user-friendly label that I can rename at will. The UI and documentation don't make it clear that the name, once chosen, should never be changed.
I will add an internal issue with your observations. So somehow when you change the name of a document type, and then click "OK" we could warn you that the name is used in various profiling mappings + maybe used with frameworkDir(name) and you could decide to continue or cancel the operation...
Oh, the other place this shows up is in the variable ${frameworkDir(framework_name)}}. If anybody had made a transformation scenario as part of an xpr or whatever and used that variable, then changing the name breaks them.
Right. I also an internal issue about considering setting an ID for a framework configuration. The ID would not be required though as we would need to have some backward compatibility.

Regards,
Radu