Re: [oXygen-user] [OXYGEN-9493] Load external data into form control?
Hi Scott, If you just configure using the CSS a combo box to edit the values of an attribute, by default those values will be gathered either from the DTDs (if you have defined a choice of values for the attribute in the DTDs) or from our content completion configuration file which can use XSLT to gather values from another location. Maybe this blog post by my colleague Alex will help: https://blog.oxygenxml.com/topics/controlledAttributeValues2.html Regards, Radu Radu Coravu Oxygen XML Editor On 10/19/23 03:06, Scott Prentice wrote: I'm refining some metadata form controls for a custom framework, and it would be ideal if I was able to load the values and labels for a combobox from an external file (XML or preferably, JSON) rather than hard-coding these values into the CSS. It seems that this may be possible with xpath_eval(). Is anyone aware of any examples of this, or am I heading down a rabbit hole? I'll keep poking at this, but thought I'd see if anyone had thoughts on this effort. Thanks! ...scott ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
[oXygen-user] Load external data into form control?
I'm refining some metadata form controls for a custom framework, and it would be ideal if I was able to load the values and labels for a combobox from an external file (XML or preferably, JSON) rather than hard-coding these values into the CSS. It seems that this may be possible with xpath_eval(). Is anyone aware of any examples of this, or am I heading down a rabbit hole? I'll keep poking at this, but thought I'd see if anyone had thoughts on this effort. Thanks! ...scott ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
Re: [oXygen-user] [OXYGEN-9425] Association Rules in frameworks
Thanks, Radu! That's sorta what I was assuming, but wanted to make sue there wasn't some special reason that entry was needed for "all" DITA-based frameworks. Yes, after removing the "DITATopicCustomRuleMatcher" java class entry, the matching seems to work as expected. Nice. Simple is good. :-) And, regarding he gremlin behavior .. so far I'm not seeing anything unexpected. Perhaps I was being careless at the end of the day .. hard to believe, I know. Fingers crossed. All the best, Scott On 10/17/23 11:19 PM, Oxygen XML Editor Support (Radu Coravu) wrote: Hi Scott, The "DITATopicCustomRuleMatcher" java class is where the magic happens :) It's quite hard to identify a DITA topic or map, it could use the base public IDs or it could refer to specialization DTDs, it could have various root element names, but the "DITATopicCustomRuleMatcher" Java class looks at various default attributes specified in the DTD like the "ditaarch:DITAArchVersion" attribute to decide if an opened XML document is actually a DITA topic or map. https://www.oxygenxml.com/InstData/Editor/SDK/javadoc/ro/sync/ecss/extensions/dita/topic/DITATopicCustomRuleMatcher.html#matches(java.lang.String,java.lang.String,java.lang.String,java.lang.String,org.xml.sax.Attributes) So with this extra rule added at the end of all other rules, our base "DITA" and "DITA Map" frameworks will be applied on any kind of specialized DITA XML topic or map, without the end user having to create a special DITA framework extension to match their type of documents. But once people start to create DITA framework extensions (like you do) for special DTD public ID, this extra rule placed at the end would no longer be necessary to you because you know that your topics and maps refer to specific DTDs. So I think it's correct that you are only using some very specific association rules in your DITA framework customization which no longer include our "DITATopicCustomRuleMatcher" class. About this behavior: but I think I'm seeing that after I remove all but the necessary rules from a particular framework, after some time, additional rules are added. When I close and save the framework, sometime later I go back and there are rules that match on Root Local Name .. concept, task, reference, etc. .. I'd swear I didn't add those. Do I have gremlins, or is this a feature? This would be a bug, but we would need some way to consistently reproduce it. Regards, Radu Radu Coravu Oxygen XML Editor On 10/18/23 01:54, Scott Prentice wrote: I've got two different DITA models that are similar, and each may be edited at the same time in Oxygen. Their DTDs are different and use different Public IDs. I'm developing a framework for each which applies slightly different schematron validation and CSS styling. It's my understanding that I should be able to target each model using the Association Rules, and in general this seems to work fine. Since I'm trying to be very specific about which documents are to use each framework, I thought I'd keep the Association Rules to a minimum, basically just the specific Public IDs. It's my understanding that if a document matches any one of these rules, the framework will be applied .. so no need to include extra match rules .. right? One association rule that I see on many DITA frameworks is a Java Class rule of .. ro.sync.ecss.extensions.dita.topic.DITATopicCustomRuleMatcher Can someone tell me what this does and is it needed in all cases? Also .. and I may be mistaken .. but I think I'm seeing that after I remove all but the necessary rules from a particular framework, after some time, additional rules are added. When I close and save the framework, sometime later I go back and there are rules that match on Root Local Name .. concept, task, reference, etc. .. I'd swear I didn't add those. Do I have gremlins, or is this a feature? Thanks! ...scott ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
Re: [oXygen-user] Web Author and git submodules
Hello, The configuration option affects all git-connectors. If you enable it, Gitlab on-premise will be affected as well. Best, Gabriel On 18-Oct-23 15:38, Jirka Kosek wrote: Hi, is it possible to use submodules in WebAuthor with GitLab on-premise? I don't see similar option for enabling them as in configuration for generic Git client. Many thanks in advance. Have a nice day, Jirka ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
[oXygen-user] Web Author and git submodules
Hi, is it possible to use submodules in WebAuthor with GitLab on-premise? I don't see similar option for enabling them as in configuration for generic Git client. Many thanks in advance. Have a nice day, Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing -- Bringing you XML Prague conferencehttp://xmlprague.cz -- OpenPGP_signature Description: OpenPGP digital signature ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
Re: [oXygen-user] [OXYGEN-9425] Association Rules in frameworks
Hi Scott, The "DITATopicCustomRuleMatcher" java class is where the magic happens :) It's quite hard to identify a DITA topic or map, it could use the base public IDs or it could refer to specialization DTDs, it could have various root element names, but the "DITATopicCustomRuleMatcher" Java class looks at various default attributes specified in the DTD like the "ditaarch:DITAArchVersion" attribute to decide if an opened XML document is actually a DITA topic or map. https://www.oxygenxml.com/InstData/Editor/SDK/javadoc/ro/sync/ecss/extensions/dita/topic/DITATopicCustomRuleMatcher.html#matches(java.lang.String,java.lang.String,java.lang.String,java.lang.String,org.xml.sax.Attributes) So with this extra rule added at the end of all other rules, our base "DITA" and "DITA Map" frameworks will be applied on any kind of specialized DITA XML topic or map, without the end user having to create a special DITA framework extension to match their type of documents. But once people start to create DITA framework extensions (like you do) for special DTD public ID, this extra rule placed at the end would no longer be necessary to you because you know that your topics and maps refer to specific DTDs. So I think it's correct that you are only using some very specific association rules in your DITA framework customization which no longer include our "DITATopicCustomRuleMatcher" class. About this behavior: but I think I'm seeing that after I remove all but the necessary rules from a particular framework, after some time, additional rules are added. When I close and save the framework, sometime later I go back and there are rules that match on Root Local Name .. concept, task, reference, etc. .. I'd swear I didn't add those. Do I have gremlins, or is this a feature? This would be a bug, but we would need some way to consistently reproduce it. Regards, Radu Radu Coravu Oxygen XML Editor On 10/18/23 01:54, Scott Prentice wrote: I've got two different DITA models that are similar, and each may be edited at the same time in Oxygen. Their DTDs are different and use different Public IDs. I'm developing a framework for each which applies slightly different schematron validation and CSS styling. It's my understanding that I should be able to target each model using the Association Rules, and in general this seems to work fine. Since I'm trying to be very specific about which documents are to use each framework, I thought I'd keep the Association Rules to a minimum, basically just the specific Public IDs. It's my understanding that if a document matches any one of these rules, the framework will be applied .. so no need to include extra match rules .. right? One association rule that I see on many DITA frameworks is a Java Class rule of .. ro.sync.ecss.extensions.dita.topic.DITATopicCustomRuleMatcher Can someone tell me what this does and is it needed in all cases? Also .. and I may be mistaken .. but I think I'm seeing that after I remove all but the necessary rules from a particular framework, after some time, additional rules are added. When I close and save the framework, sometime later I go back and there are rules that match on Root Local Name .. concept, task, reference, etc. .. I'd swear I didn't add those. Do I have gremlins, or is this a feature? Thanks! ...scott ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user ___ oXygen-user mailing list oXygen-user@oxygenxml.com https://www.oxygenxml.com/mailman/listinfo/oxygen-user
