I want to add some rendering options to Views2 field handler (similar to 'Output this field as link' or 'Rewrite the output of this field') for a greater control over rendering of HTML markup (I need to add some extra attributes to tags). I want this additional options to be available for all (or at least most of the fields). Is it possible to replace default Views2 field handler (i.e. views_handler_field class) with my own field handler? There is a hook for submitting own handlers (hook_views_handlers) and there is a hook to tell other modules what handler should be used for given field (hook_views_data_alter). I also don't see a way to override default inheritance pattern for view_handler_field and its descendants. And extending every single field handler provided by other modules with my own classes seems to be pointless. Am I right saying that this cannot be the right way to solve this problem?
If I am right, what is another way to (1) extend field options form with some inputs and (2) alter rendering of this field based on inputs. I guess (1) could be achieved by altering form by default Drupal hook, but render method belongs to given field handler and I don't see a way to intercept its call and output altered markup.
In theory you could use a non-existant hook_views_handlers_alter to change the path of a class which is somewhere
Related
Given:
#property({type: Boolean, attribute: 'some-attr'}) someAttr = false;
I was expecting to see updated being fired once 'some-attr' value gets updated in the DOM.
However, updated doesn't get fired at all.
Is my expectation wrong, or should I set things up differently?
Looking at Elm's discussion of properties vs attributes, the documentation of the Html.Attributes module's attribute function, and the Elm documentation on custom elements, I am pretty sure, that this is caused by simply binding an elm expression to attribute some-attr of the LitElement based custom element. I.e. the DOM attribute will always be present and hence the corresponding property always be true.
The default converter for Boolean (activated by providing type:Boolean to the decorator) mimicks the behaviour of HTML attributes used as flags (e.g. disabled on an <input> element): If the attribute is present (no matter the value), the flag is set (true). The implementation is really straight forward, if you want to look at it in the sources: https://github.com/Polymer/lit-element/blob/master/src/lib/updating-element.ts#L163
I see these options for your problem:
Implement some extra logic in Elm to add / remove the presence of the attribute.
Create your own attribute converter for the LitElement based custom element.
Use another default converter (e.g. for String, the "default" default converter) and implement the custom logic inside the LitElement (e.g. using a derived value).
Of these 3 options, I would generally recommend the first one, as your custom element then still behaves naturally, i.e. if some-attr should be a flag (boolean attribute), then following which HTML semantics, it should be defined by its presence, not its value. This allows you to re-use it in other projects without surprising other developers.
That being said, there may of course be project-specific requirements, that are more important. E.g. if you only use this custom element in this one project with Elm, your road to success may be faster going for options 2 or 3.
I have multiple buttons and form inputs in one page. All these buttons and form inputs need to be disabled or enabled depending on a condition.
I know that it is possible to use the disabled keyword inside a tag to disable a specific input or button. Also, I can just add the code
:disabled="true"
to disable the inputs depending of the boolean value of a variable.
However, this solution is not acceptable for me, since I will have to add this line of code to every inputs on my page (I may create new pages in the future, containing as many inputs).
I would like to know if there's a way that allows me to simply disable the parent container of all the inputs so that the children item (the inputs) are disabled.
If you inspect the Vue instance itself of the VM when running your code you can have something like this when you console.log(this),
It will give you output similar to this if you use the correct scope:
{
$attrs
$options
.......
$el
}
Inside $el there's object properties for accessing firsElementChild, previousElementChild, previousElementSibling, etc. There's a lot of HTML related properties, however, accessing HTML element this way can get messy pretty fast. I think that your best solution is the one you already mentioned or changing the CSS class dynamically.
If you use v-if to conditional render on a parent you can achieve pretty similar functionality too.
See: Conditional rendering
Using angular-formly, I'm trying to build a form, where if the label is removed in fields json, there is no padding or spacing given to the that label in the rendered html.
Here is an example of the actual form and my 'desired' form:
JS Bin
The best solution would require a pull request to the template library's label wrapper template which would use an ng-if to hide the label if one is not provided.
If you don't want to deal with that, then you can choose from one of these options:
Set wrapper to null for the field. But you lose the other wrappers as well (like the one that adds has-error)
Create your own type that allows you to specify your own wrappers.
Both of these are demonstrated here:
https://jsbin.com/quceqi/edit?html,js,output
I'm currently building a custom control to be used as an application's view navigator (classic OneUI style). First of all: this is a 8.5.3 based project, and unfortunately there's no way to use Extlib stuff or other extensions / plug-ins. So we have to build all the tricky stuff ourselves using only what came "out-of-the-box" with 8.5.3.
I'd llike to build my navigator using a repeat control containing <xp:link> controls. Datasource could be an array of javascript objects where each single object would look like this:
var navEntry = {"entryLabel" : "label-of-link",
"entryTarget" : "target-url-of-link",
"entryStyle" : "style-to-emphasize-selected-link"}
Each array element then would describe a single navigator entry.
Since the navigator will be used in all possible "DominoView" Xpages it yould make sense to build the array of JS objects at the Xpage level and then pass that info into the custom control.
I'm aware that there are multiple ways to do this, and one could be "Custom Control Properties". If there was a way to pass my JS object array.
(Hope I could make clear what I'm trying to do here...)
That object looks like a HashMap to me really. You should be able to pass that in to a custom control via custom property if you use the type java.util.HashMap I'd think. You'll need to type it in I'm sure. I've passed custom objects in by using java.lang.Object.
The custom control will get loaded during the Page Load event, and usually properties have to be available at that point. If they're loaded during the Render Response phase, that's too late. So your SSJS object will need to be Compute on Page Load.
To use contents of a repeat control, you would need to set repeatControls=true, otherwise the repeat is only built during render response. Until then it's just a single set of controls with no data in them. However, Im pretty sure repeatControls="true" means you only get the number of rows you define. You can't change it via a pager.
You can manually define the type of the custom property. For a standard SSJS Object you use "com.ibm.jscript.std.ObjectObject", for a SSJS Array you use "com.ibm.jscript.std.ArrayObject" etc. As editor for the custom property, I set the string editor ("String value").
I have a radio button group that gets it's values using an #Dblookup. In addition to the name to appear in the radio button group, the document also has a field to determine if another field on the xPage should be displayed or not.
If the field is displayed then it should be required.
I can do the conditional validation just fine in SSJS using an #DbLookup to lookup the document selected in the radio button group.
But I would like to be able to do it CS so it is faster and so it looks like my other validations. Is there anyway to do this?
If a field is not rendered then the node will not exist in the DOM. Your CS javascript would need to examine the DOM and look for the node, normally by looking for a specific ID. As Xpages changes the ID's sent to the browser your validation function would either need to be computed so it would know what ID to look for or you would need to look for it in some other unique way ( like add a css class name to just that field and then do a DOM search for nodes with that class name )
Once you can determine if the field has been rendered then you can run your usual CS validation routine against the other field.
If you're using client-side validation throughout your app, setting the required property on the field should achieve what you need.
If not, it may be worth looking at the Extension Library Dojo Validation Text Box. All the Extension Library Dojo control run client-side validation, even if validation is set as server-side at application level. Bear in mind that for the Dojo Validation Text Box, just setting the required property is not enough. You need to add more specific validation.
After that, the key is to ensure the partial refresh event on your radio group is set to skip validation. I haven't tried, but I believe that should achieve what you need.