We are working on a custom version of the A-Frame inspector. The default inspector exposes all properties of all components of an entity for editing, but we wish to be able to specify at the component level which properties may be displayed to a user and render certain properties using custom widgets.
What is the best way to specify which properties to hide, rename, or use a custom widget (such as button or large-text-field)?
Here are some ideas we came up with:
Write custom logic in the editor that determines which fields to display depending on the component name. For example if component name is street then display custom widgets via custom logic inside of the modified inspector.
Define at the entity level with an attribute such as data-editor-hide-props="prop1, prop2, prop3"
Define at the component level. There are a few options for this:
A. Create a new method on every component that we want to have custom UI for. This method returns an object that indicates which fields should be displayed, hidden, and if certain field should use a custom widget.
B. Use the property name to indicate which custom widget should be rendered. For example, if a boolean field is named buttonFoo_Bar render a button widget (instead of a checkbox) with the display text "Foo Bar"
C. Add extra values to the schema to indicate rendering preference. Such as below:
AFRAME.registerComponent('street', {
schema: {
JSON: { type: 'string', editorWidget: 'large-text-field' },
type: { default: 'streetmixSegmentsFeet' },
left: { default: '', editorDisplay: false },
right: { default: '', editorDisplay: false },
showGround: { default: true },
showStriping: { default: true },
length: { default: 150 },
actionRefresh: { type: 'boolean', editorWidget: 'button', editorDisplayName: 'Refresh Street' }
},
These extra component schema values seem to be ignored by A-Frame and do not throw an error. Is this a safe assumption?
Suggested answer:
3C seems like the "right" answer in the long-term, but it might be easier to start with 1 and then later migrate to 3C.
What do you think?
Hardcoding any logic in the editor will deny any flexibility (though might be simple for some initial prototyping)
I'm also not sure about option 3, You'd have to modify lots of existing components, sometimes it may add some level of complication to already complex components.
I would try going somewhere in the way of the second option -
adding a new component, inspector__<component name>, where you will define which fields of the component should be displayed and how. It can pass all info to a predefined system, which is easily accessible and manageable.
It will work with existing components, and will be an add-on which is bound to the inspector, but won't affect any components (not only from a 'single responsibility' standpoint, even from the aspect of the components readability, and maintainability).
Related
I'm using react-bootstrap-typeahead for adding items in to a list.
I want to disable remove button of the added items according to a condition.
https://ericgio.github.io/react-bootstrap-typeahead/
Yes, you can use the renderToken prop to customize how the tokens are rendered.
The tokens themselves accept a disabled prop. If true, the token will be read-only and have a disabled appearance.
Alternatively, omitting the onRemove prop on the token will make it read-only without the disabled appearance.
Here's a basic example of how to specify each of the methods described above:
<Typeahead
...
multiple
renderToken={(option, props, idx) => (
<Token
disabled={idx === 0}
onRemove={idx === 1 ? undefined : props.onRemove}>
{option.label}
</Token>
)}
/>
Working sandbox: https://codesandbox.io/s/react-bootstrap-typeahead-token-customization-495-54gtg
Note: In both the disabled and read-only cases, users will not be able to remove the selections once added, so be careful about the user experience. The disabled state is generally best used when the entire typeahead is disabled. In that case, the disabled state is automatically passed down to the token components. Read-only selections are good when you want to pre-select required options, for example.
You can use this to disable it:
<Joyride
styles={
{
buttonClose: {
display: 'none',
},
}
}
I want to add an additional checkbox next to Crop Image but I can't understand what need to write in javascript for rendering it and handling then. I couldn't find documentation with explaining that. I've tried to write code like that but it didn't work:
function addListBlockClassName (settings, name) {
if (name !== 'core/gallery') {
return settings
}
// new checkbox
settings.attributes.enableVoting = {
default: false,
type: 'boolean',
}
return settings
}
wp.hooks.addFilter(
'blocks.registerBlockType',
'my-plugin/class-names/list-block',
addListBlockClassName
)
You can add the additional checkbox on sidebar by using InspectorControls and Checkbox Control
Have a look at gallery block and learn how the are implementing things on sidebar via using InspectorControls. This can be complex so for easier implementation you can look at other core blocks of Gutenberg.
And this link can help you about how to use CheckboxControl.
In your above code you are just adding a hook which is changing the default class name of block gallery and that is not what you are asking. Please note that as per my knowledge you can't edit default core blocks (apart from very few things) unless you copy whole core block and add additional functionality into it.
In my UI5 application, I have an i18n.properties file with keys and values:
#XMSG:
qty=Quantity
And I'm using this property value in a dialog box as title
onUpdateDialog: function() {
var that = this;
var dialog = new Dialog({
title: "{i18n>qty}",
// ...,
});
dialog.open();
},
But when I run my application, the dialog box title is not getting displayed:
When I use text values from i18n property file somewhere else it's getting displayed.
ManagedObjects, that are created by the application code imperatively outside of the framework-managed features (Such creating an instance of sap.m.Dialog in a Controller code without using the API loadFragment), have to be added to the model delegation chain manually in order to make use of the propagated models.
In order to do so, add the created instance to the parent's <dependents> aggregation. E.g.:
this.getView().addDependent(myDialog); // myDialog is now aware of the "i18n" model
From API Reference:
Special aggregation dependents is connected to the lifecycle management and databinding, but not rendered automatically and can be used for popups or other dependent controls or elements. This allows the definition of popup controls in declarative views and enables propagation of model and context information to them.
In order to use texts in the controller you need to fetch the text first, like so:
this.getOwnerComponent().getModel("i18n").getResourceBundle().getText("qty")
this will be the dialog inside the dialog, so declare a that before the dialog and change this to that..
var that = this;
that.getOwnerComponent().getModel("i18n").getResourceBundle().getText("qty")
Hope this solves your issue..
At the point of opening the Dialog, it doesn't know the i18n model. You need to provide the model to the dialog by calling dialog.setModel(this.getModel('i18n'), 'i18n') before opening the dialog.
I have a collection of some items. Using * symbol I set user control (ascx) in presentation details for all of them. Now I have a problem because on of this items has to be display in another control. Is there some trick that allow me to change used control dynamically, for example checking url segment?
I'm guessing you're using wildcard item called * with some presentation details defined on it. And now you want to display different components for one you the urls?
If you want to have completely different presentation, you can add another item as a sibling of the * item and put new presentation detail there. This item will be matched before the wildcard item, if the url segment is equal to this item name.
If you want to change only one or few components, you can use personalization for this component and where the item name compares to ... rule.
Marek's answer is preferable, but for completeness I will provide another potential option.
It depends on how you are handling the wildcards. I don't think it will work if you are using the wildcard item module from the Marketplace and it might not play well with some of your existing code, but here goes...
You could place the required presentation details on the target items themselves. Then when you resolve the wildcard, you would need to change the context item to be selected target item. When the page loads, it will use the presentation of the newly set context item.
One way to achieve this would be to create a custom item resolver
class WildCardItemResolver : ItemResolver
{
public override Process(HttpRequestArgsargs args)
{
base.Process(args);
// if Context.Item is as wildcard
// look up the target item
Context.Item = targetItem
}
}
I have a view I'm using as an "Advanced Search" tool - it simply provides a list of relevant nodes which are limited by a number of exposed filters I have in place. In particular, I have a "keyword" exposed filter that's acting as the main search box, which filters on the node title. Now, I've had a request for the ability to toggle (I assume with a checkbox or similar) this filter to search on both the node title and body at the same time, as an option to provide users with more search results.
I currently have a view set up with two displays: one that filters on just the node title, and one that uses Views Or to limit the results to nodes that have the keywords in either the node title OR the node body. By themselves, both of these displays are working the way I'd like.
My question is how I'd go about toggling between these two displays using a checkbox or something similar. I don't want to use Views Display Tabs because both displays look visually identical (the only difference is how the filters are configured to include more/less results) which would be confusing to the user - plus it uses AJAX which breaks some (mostly small) modifications I've made via jQuery to the behavior of the view.
What I'd like to accomplish, in essence, is a conditional check when the view is submitted - depending on whether a checkbox is selected, the arguments are sent to one display or the other. Any suggestions on how to accomplish this?
One way you might be able to go about this could involve adding a custom validate handler on the exposed filter form that would in theory allow you to check the value and forward the request to a different page display appropriately. Exposed filters are exposed in the URL as $_GET variables, so, forwarding a user to a specific page with filters predefined should be easy enough.
<?php
function mymodule_form_alter(&$form, $form_state, $form_id) {
switch ($form_id) {
case 'views_exposed_form':
// Deterimine the ID so you only do this
// to a specific exposed filter form
// drupal_set_message($form['#id']);
if ($form['#id'] == 'views-exposed-form-api-search-page-1') {
// You might also want to add the checkbox FAPI item in this area
$form['#validate'][] = 'mymodule_api_search_validate'; // custom validate handler function name
}
break;
}
}
function mymodule_api_search_validate($form, &$form_state) {
// Check if the FAPI item has the specified checkbox value
if ($form_state['values']['options'] == 'title') {
// The get variables to pass to the views exposed filters
// You can configure what this $_GET variable should be while editing the filter
$query = array(
'query' => 'the search query',
);
drupal_goto('api/search', $query);
}
}
?>