I tried to save data-attribute inside a span tag. After saving it`s removed.
I tried the following configurations in my custom yaml file.
processing.allowAttributes:
-'span[data]'
processing.allowTags:
-span
editor.config.extraAllowedContent: "*(*)[data-*]"
Nothing helped.
Where is the problem?
To allow saving data attributes to db from RTE fields, you need to ensure that:
1) RTE (CKEditor) will not strip the attributes. This is configurable using extraAllowedContent. Below is an example how to allow id attributes additionally to the default rule which allows data attributes and classes.
editor:
config:
extraAllowedContent:
- "*(*)[data-*]"
- "*[id]"
If you only need to add data attributes, you don't need the configuration above and can relay on default configuration (from rte_ckeditor/Configuration/RTE/Editor/Base.yaml), as data attributes are allowed by default there.
2) then you need to configure PHP side of things - data transformation which happens before data is saved to db. See manual chapter: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Rte/Transformations/Process.html#transformations-process
Below is an example (taken from RTE yaml preset) of allowing data-abc attribute in transformation (in addition to attributes which are allowed by default).
processing:
allowAttributes: [class, id, title, dir, lang, xml:lang, itemscope, itemtype, itemprop, data-abc]
So in your case you were missing proper allowAttributes configuration.
Related
Is it possible to pass data into UI extensions assignments (meaning UI Extension X assigned to Field Y), in order to alter their functionality slightly for different situations, without having to reimplement the entire extension?
For example, CodeMirror is a really neat embedded editor, but it has a bunch of "modes," depending on what language you're working with. If we could even pass in a string to represent the desired mode when the extension is assigned to a field, that would remove the need to do a different extension just to use different syntax highlighting.
With this, there could now be a generic "CodeMirror Editor" UI extension which is then just configured a runtime.
On the other end of the extreme, we could specify entire JSON objects when the extension is assigned to a field, to further specify configuration options.
This would make UI extensions so much more...useful. Does this functionality exist now, or is there some way to reasonably make it work? Is there some place on the field specification where I can "park" a JSON string, then access it from inside the extension?
Contentful has launched something called "Configuration parameters" for UI extensions that could be used to solve this issue.
They have two types of parameters, installation and instance parameters. Installation parameters are set when installing the UI extension, and instance parameters are set when configuring a field on a content type to use the extension. The latter would be perfect for your use case.
To use this feature you need to:
Create a parameter definition for the UI extension in the extension.json file. E.g. a new instance parameter called "codeMirrorSettings" of type Symbol with name "CodeMirror Settings".
Within the extension, fetch the current parameters using extensionsApi.parameters.instance.codeMirrorSettings.
Documentation for configuration parameters can be found in Contentful's docs:
https://www.contentful.com/developers/docs/references/content-management-api/#/reference/ui-extensions/configuration-parameters
https://github.com/contentful/ui-extensions-sdk/blob/master/docs/ui-extensions-sdk-frontend.md#extensionparameters
What you could do is just read this setting from another field, be that a string or a json object.
For example the slug generator automatically generates its value from the title field.
You could perhaps do something like this:
const cfExt = window.contentfulExtension || window.contentfulWidget
cfExt.init(api => {
var langField = api.entry.fields.mirrorLang || 'default'
//Rest of implementation
})
Well, I wrote something for this, specific to my situation, but generalizable to others. This is an example if a UI extension that retrieves settings from another entry in the space, and uses it to dynamically configure itself.
https://github.com/deanebarker/contentful-code-editor
I wish to use cq:inplaceEditing to modify a property on my JCR whenever it is used by the AEM authors. Unfortunately, I do not know how to modify the name of the property that it actually modifies in the JCR. It appears that it only modifies the value of the property "text" by default.
For my purposes, I want to use its rich-text-editing for properties that have names I define, not just the default name "text."
The image at this link shows the tree which contains the cq:inplaceEditing (courtesy of CRXDE):
These are the attributes of cq:editConfig:
These are the attributes of cq:inplaceEditing:
...and this is what a content node of my JCR looks like when I use the inplaceEditor. I've blotted out the names of some properties for potential security reasons. Note that the "text" property below was changed when I used the inplaceEditor. Also note that I want to be able to define the property name that the inplaceEditor changes, rather than just the "text" property:
Is there a way to use a different property name instead of "text"?
-----------EDIT----------
After changing the property "textPropertyName" to the property that I am searching for, it still doesn't appear to actually modify the behavior of the inplaceEditor. It still only modifies the "text" property of my JCR nodes instead of the one that I put in the "textPropertyName" attribute.
This picture contains the attributes of my cq:InplaceEditingConfig:
The picture below contains the attributes of the JCR node at the path specified in the "configPath" variable in the picture above. Note that I set the textPropertyName attribute in this node and the text component still modifies the default attribute "text" instead of the one specified:
Finally, the picture below shows the contents of my JCR tree inside of the text component.
-----------ANOTHER EDIT----------
I discovered that the inline text editor was persisting the correct property after I had switched to the classic UI. For some reason, it doesn't work correctly with the touch UI.
How to find it
The inplace editing capability is defined by subclasses of CQ.ipe.InplaceEditing function. You can find it easily by just searching for editorType through the CRXDE tool.
Searching for the CQ.ipe.InplaceEditing returns multiple results such as CQ.ipe.TextEditor that at the very end of the script registers desired editorType i.e.: CQ.ipe.InplaceEditing.register("text", CQ.ipe.TextEditor);
The answer
Reading through the editor code you can find the first configurable property called textPropertyName which according to it's documentation is just what you are looking for. Combining it with the inplace configuration node (see Adobe's documentation) it is the solution for your case.
An example
You can try it by yourself on an instance of Geometrixx component.
First go to CRXDE and find Geometrixx Text component: /apps/geometrixx-gov/components/text.
Notice /apps/geometrixx-gov/components/text/cq:editConfig/cq:inplaceEditing#configPath property value.
Find /apps/geometrixx-gov/components/text/dialog/items/tab1/items/text resource and add new property: textPropertyName=myPropertyName.
Then just open the Geometrixx Gov page add Geometrixx Text component, edit it inplace and look into the Network console. You'll notice POST request with the altered parameter name
edit after TouchUI clarification
TouchUI case
If you want to achieve the same for TouchUI interface it doesn't go so easy, unfortunately. The text inplace editor for TouchUI is defined by /libs/cq/gui/components/authoring/clientlibs/editor/js/editors/InlineTextEditor.js.
Searching for "text" gives you an overview how hardcoded is this property. For AEM 6.1 (on which I'm testing it) you can find it's occurence in the ns.persistence.readParagraphContent function where the initialContent is extracted from the resource JSON map. Another occurence can be found in finishInlineEdit and addHistoryStep methods. Changing all three occurences of "text" to your value brings expected outcome.
This is obviously non-acceptable - it's a platform-wide change and will affect other (incl. ootb) components where it might no be expected. The simplest would be to just copy-paste whole editor into your clientlib and register the editor into a new name - see last couple of lines: ns.editor.register. If you feel comfortable in JS, it might be worth to extend this editor and alter just three methods that are affected.
As of AEM 6.3, the textPropertyName works correctly with the out-of-the-box PlainTextEditor.js
The property needs to be set on a config node under the cq:InplaceEditingConfig
Note – the source of the editor can now be found at:
/libs/cq/gui/components/authoring/editors/clientlibs/core/inlineediting/js/PlainTextEditor.js
I am facing an issue with extended attributes on a document (trying to extend a document table). I created the original table’s PK (FDOC_NBR) in the extended table and linked the two via a foreignKey of the customized original table’s ojb entry (as an “extension” reference-descriptor). I created the bo and dd for the extension and customized the original document’s dd to add the new attributes. On the extended BO itself I also added members (with setters and getters) for the 2 new columns + for the PK column of documentNumber. I also added the new attributes to the documet’s jsp. The pertinent module definition was already extended to include custom dd, ojb, etc. files.
Indeed, when opening the document the new fields are shown- however, when trying to submit the document (regardless of doing anything with the new fields) I get an error-
Error Details: OJB operation; SQL []; ORA-01400: cannot insert NULL
into ("KFSTEM"."TEM_TRVL_ARRANGER_DOC_EXT_T"."FDOC_NBR") ; nested
exception is java.sql.SQLIntegrityConstraintViolationException:
ORA-01400: cannot insert NULL into
("KFSTEM"."TEM_TRVL_ARRANGER_DOC_EXT_T"."FDOC_NBR")
Seems like somehow the system tries to insert a value of NULL into the extension’s PK field, instead of the actual document number. Trying to debug this, in the action’s route method and all the way down to DocumentDaoOjb.save (which is as far down as I can go) I see the document with the real doc number is passed on, so the problem seems to be purely with ojb trying to set this number to the extension table.
Does anyone have any experience with extended attributes on documents that could help shed some light on this?
KFS is using the KNS, and in the Kuali Nervous System, the primary key on the extended attributes object must be set through manual intervention.
In this case, it looks as if you're adding an extended attribute to a transactional document, the Travel Arranger document (TAA), which simplifies things. Basically, you'll need to extend org.kuali.kfs.module.tem.document.TravelArrangerDocument and override prepareForSave to set the document number there (it may be set already since prepareForSave should be called several times during the routing process, but there's no real harm from overwriting that information as the base document's number will remain the same).
Hope this helps!
I do not know that the question is right? Please do not take it your mind if it is crazy. Actually I am working on xpages application. There I need to do two things, that I want to add the picklist functionality and binding the dynamic data like field_1,field_2,field_3, ... upto n depands on customer choice.I am using the composite data for both custom controls. I can remove the picklist control's composite data and also I can do it by passing the scope variables. But that takes more time than the composite data.
I did not get any error. But the binded documents is not saving.
Is it possible to import the CCs that are having composite Data?
Code for first CC:-
<xc:viewpicklist datasrc="view1" dialogID="dialog1" dialogWidth="700px" dialogTitle="Pick this field value!!!">
<xc:this.viewColumn>
<xp:value>0</xp:value>
<xp:value>1</xp:value>
<xp:value>2</xp:value>
</xc:this.viewColumn>
</xc:viewpicklist>
Code for Second CC:-
<xc:BOM_Partinfo BOM_Partinfo="#{document1}"
TNUM="field#{index+1}" Desc="Desc#{index+1}" quan="Ea#{index+1}"
exp="exp#{index+1}" cap="cap#{index+1}" total="price#{index+1}"
RD="RD#{index+1}" m="manufact#{index+1}"
m_n="manufactnum#{index+1}">
</xc:BOM_Partinfo>
You can read information that is set in the properties of a custom control if it was static in the calling page:
var x = getComponent("yourcomponentid");
x.getPropertyMap().get("parametername");
but you want to propagate a data source from the outer control to the inner control...
You need to plan carefully. If you hand over the data source, then your custom control is dependent on a fixed set of fields in the data source (that would be a parameter of type com.ibm.xsp.model.DocumentDataSource). This would violate the encapsulation principles. So I would recommend you actually hand over data bindings - the advantage: you are very flexible what to bind to (not only data sources, but also beans and scope variables would work then). The trick is you provide the binding name as you would statically type it in (e.g. "document1.subject" or "requestScope.bla" ). In your control you then do
${"#{compositeData.field1}"}
${"#{compositeData.field2}"}
You need one for each field.
You cannot send a document data source to a custom control using composite data parameters.
You can try and use this script instead
http://openntf.org/XSnippets.nsf/snippet.xsp?id=access-datasources-of-custom-controls
Define data source in XP/CC where you want those CCs. Define parameter "dataSourceName" for both CCs. Inside each of them use EL "requestScope[compositeData.dataSourceName].fieldName" everywhere you want to bind to datasource.
When beginning to develop against SharePoint I did not fully understand all the ins and outs initially. I created a list definition (for a document library) and associated various custom actions to it. Unfortunately, I used the following for the list definition itself:
<ListTemplate...
...
Type="101"
...
And to register the CustomActions against the list:
<CustomAction...
...
RegistrationType="List"
RegistrationId="101"
...
Of course, this means that the custom actions are visible for all document libraries where the feature is activated which is undesirable behaviour. Also, there are lots of these document libraries that have been created from the above list definition in production.
What is the best way to fix this problem? My assumption is that I somehow need to change the "Type" attribute of the already existing lists, but I do not know how to do that. Can it be done via some direct SQL manipulation perhaps? Or is there a better way?
Note: I can see that the AllLists table has a column tp_ServerTemplate, is that the right thing to change?
Modifying the SharePoint database is completely unsupported by Microsoft. Please do not do this on production!
Another option is to create a content type and associate the custom action with that. You may need to write a simple console application to iterate through your existing document libraries and add the content type so it is available for use. The existing documents that you'd like the custom action to apply to would need their content types changed as well.
From some quick initial testing it does look like changing the AllLists table does the trick.
So steps to resolve:
1) Change List Definition Type attribute to be a unique value (for example 11000)
2) Change the CustomAction RegistrationId attributes to be the same (11000)
3) Update the tp_servertemplate column in the AllLists table to be the new template Type (11000) for all the relevant lists.