Inside a BashOperator, I added a markdown snippet of documentation for the "Task Instance Details" of my Airflow nodes.
Now I can see my markdown, defined by the attribute "doc_md", but also
Attribute: bash_command
Attribute: doc
Attribute: doc_json
Attribute: doc_rst
Attribute: doc_yaml
I don't want to show any other attributes more than "doc_md", is it possible?
You can hide some attribute from the table which is just below by adding them to HIDE_ATTRS_FROM_UI, but currently you cannot hide the attributes you have mentioned in your question.
Airflow defines them in this method then it checks if the operators contains the attribute, and if yes, it adds it to the UI, and the attributes you want to hide are defined in the BaseOperator which is the parent of all the other operators.
A solution is creating a new operator by copy the code of BaseOperator without the fields you want to hide (here), then duplicating the code for the operators you are using and extending the new operator instead of BaseOperator, but I'm not sure if it's worth it.
Feel free to create an issue or open a pull request on Airflow to add a new option to hide these attributes.
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 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.
I am trying to create a Custom Field Type in SharePoint.
This control has it's value set based on another field in the same list.
Because of this requirement, this field should be displayed only in the Display Mode, and not in the Edit or Create mode.
How do I ensure this?
If I just code the ASCX control to not render a field, the field will show up like this in the Edit and Create mode.
alt text http://www.mannsoftware.com/blog/Lists/Photos/121308_0204_CrossSiteLo6.png
Generally you set the SPField.ReadOnlyField property to True to achieve the desired behaviour for any field. (Don't forget to SPField.Update accordingly!) There is an equivalent CAML attribute for list definitions, I believe.
That said, in your control class deriving from BaseFieldControl, you might just override the RenderFieldForInput() method and not call the base implementation to ensure nothing is rendered during Create or Edit. However, this would still render the field's table row in the form, which is probably not what you want. So to enforce the desired behaviour, use ReadOnlyField and override Update() in your SPField (not field control) class to always have it set to True.
It might be easier to just change this on a list-by-list basis by going to the Advanced section of the List Settings, setting Allow management of content types? to Yes, and then editing your content type to change the value of your field to 'hidden'.
Take a look at this blog post. I think it will give you some ideas. The concept uses different rendering templates based on the mode.
http://sharepoint.nailhead.net/2008/04/creating-rendering-template-that.html
Did you try and set the field as hidden?
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfield.hidden.aspx
Custom FORMS pages for new item and edit item (NewForm.aspx and EditForm.aspx) would be another way to achieve this.
Setting the ShowInEditForm and ShowInNewForm properties solved this for me.