Is it possible to set default options for vue.draggable? - vue.draggable

I was wondering if it is possible to set default options for Vue.draggable? Currently I find I need to keep supply the options for each draggable when some (like the handle and scroll sensitivity) would be better set globally.
%draggable{ 'v-model': 'values', '#change': 'move', ':options': '{handle: ".handle", scrollSensitivity: 80}', 'element': 'tbody' }
Excuse the HAML.

It is not possible, You can use a store to keep the default parameters and reuse them in diferent components.
Note that starting with version 2.19 the syntax is:
v-bind="{handle: '.handle', scrollSensitivity: 80}"
Or
handle=".handle" :scrollSensitivity="80"

Related

Extensive list of Lumo Variables in Vaadin

I would like to do custom theme variations for my Vaadin 20 app. For that I am going to give custom values to Lumo CSS variables available, like --lumo-base-color and --lumo-primary-color. The problem is that I can't find an extensive list of variables that are available.
My questions are:
Where can I find a list of all the variables that are themeable?
Is there a good theme example with a lot of these variables set, that I could use as an example?
This is an excellent question, as it is often a best practice to start customization of the application on high level by redefining values of the Lumo CSS variables.
Take for example elements like ComboBox drop down button, text field clear icon, DatePicker popup button all use variable --lumo-contrast-60pct. It is easy to define its value in shared global css, and the new color will be consistently used by all the components. This is better approach than defining a custom css per component basis. See example below, where original graphite grey color has been changed to blue.
In the design system foundation documentation, each sub-section will list the available variables.
Additionally, if you inspect the <html> element in your browser development tools, you can see them listed there also.
In the Lumo theme editor demo you can change as many styles as you wish. It then lets you download a file that lists all the variables that you changed.
Another option is going to https://start.vaadin.com, where you can also customize some aspects of the theme, and the downloaded application will include those definitions.
In your running application, you could paste something like the following ugly snippet into your DevTools console to output all the Lumo custom variables and their current value:
[...document.styleSheets].forEach((sheet) =>
[...sheet.cssRules]
.filter((rule) => rule.type === 1)
.forEach((rule) =>
[...rule.style]
.filter((style) => style.startsWith("--lumo"))
.forEach((style) => console.log(style + ": " + rule.style.getPropertyValue(style)))
)
);
This will spam your console with something like
--lumo-border-radius-s: 1em
--lumo-base-color: hsl(214, 35%, 21%)
--lumo-tint-5pct: hsla(214, 65%, 85%, 0.06)
--lumo-tint-10pct: hsla(214, 60%, 80%, 0.14)
...
You might want to adjust the snippet to produce something more useful, depending on if you want to just use it as reference, or copy & paste into your theme.

Best practice for switchable Vaadin 12 themes

I am currently in the process of migrating a Vaadin 8 application over to Vaadin 12. The look and feel should be used by the user and changed on Login or via a button press.
In Our Vaadin 8 application we had 2 themes (a dark and a light one), each with their own SASS/CSS and some shared properties. The user was able to switch it using the setTheme() Method. When a click to the switching button happened, the Look and Feel just changed. In Vaadin 12 the Theming follows a different approach and I am struggling to find a good way to implement this feature in Vaadin 12.
Let's say we don't want to create a whole new Theme and just want to use customized LUMO. I can set the Theme/Variant through the #Theme Annotation. The Downside: The Theme will be fixed at Runtime.
Also i could just write some code to apply variants to my application and components. (like in the dynamic styling chapter: https://vaadin.com/docs/flow/element-api/tutorial-dynamic-styling.html )
The Downside: It won't be very practicable to iterate through each element and apply the variant.
My question now:
What is the best way to achieve a switch between to themes at runtime? (customized light- and dark variants of Lumo or any other theme).
Would I just create 2 HTML Files (for compatibility) containing CSS and then somehow override the currently used File through a dynamic import?
I hope my question is clear and someone can point me to the right direction.
If you are only interested in toggling between light and dark, then you can just add/remove dark at a very high place in the DOM. E.g. the element of the UI is usually the body or at least very high up.
E.g.:
new Checkbox("Use Dark Theme").tap{
addValueChangeListener{ cb ->
getUI().ifPresent(){ ui ->
def themeList = ui.getElement().getThemeList()
if (cb.value) {
themeList.add(Lumo.DARK)
} else {
themeList.remove(Lumo.DARK)
}
}
}
}
edit
As asked in the comments of another answer:
To change the colors in a theme, you can override the used colors. This is the example how to change the text color for light and dark Lumo theme:
html {
--lumo-body-text-color: red;
}
[theme~="dark"] {
--lumo-body-text-color: yellow;
}
It's relatively easy to switch between two different variants of the same theme, e.g. the dark and light variants of Lumo. To do this, you only need to toggle the corresponding theme attribute on the <html> element. There's no direct access to that element from the server, but you can do it with a small snippet of JavaScript: ui.getPage().executeJavaScript("document.documentElement.setAttribute($0, $1)", "theme", "dark");
Depending on circumstances, you can or must apply the changes to the <body> element instead. In that case, you can either switch out .documentElement for .body in the JS snippet or directly use ui.getElement().setAttribute("theme", "dark") in Java.
Switching between two different base themes, e.g. Lumo vs Material is a much more complicated affair. For each component, there can only be one base theme loaded in the browser at the same time, and reloading the page is the only way of getting rid of the one that is already loaded. For each component that is used for Flow, the framework takes care of loading the right theme import in addition to the base import that doesn't have any styling. To make things even more complicated, the theme designated using #Theme is automatically included in the application's production bundle. To be able to use multiple base themes, you'd also have to somehow produce multiple different bundles and also somehow configure Flow to use the right bundle depending on circumstances.

Neo4J and timestamps

I need information about node's creation & last modification dates...
Is there a way to automatically handle created and updated properties for a node?
Hibernate offers #Version for updated field. Is there something similar with Node4J.
I found http://neo4j.rubyforge.org/classes/Neo4j/Rails/Timestamps.html but it seems to be only available for Ruby.
You can use annotations form the spring-data-commons library. Use #CreatedDate and #LastModifiedDate on properties of type Long. Make sure you're using the simple mapping mode. For now, advanced mapping mode does not support this, see DATAGRAPH-335.

Am I monkeypatching jQueryUI ProgressBar correctly in this example?

I've got a full bore copy of jQuery UI in the app, so it doesn't matter if I'm loading from the CDN or locally, all I know is it's loaded. (because if we load from the CDN our only option is to monkeypatch the live version, yes?)
I see from: https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.progressbar.js that this.min is unfortunately not a settable option (this.options.max in contrast). I need this.min to be -1 in my case (and yes, application wide, we have discussed this internally on the team and we understand the reason for the jQuery decision, we just need it to be otherwise), so my only options seem to be to monkeypatch the prototype or maintain my own plugin. I also see that they are using the "widget" architecture now, for loading the jQuery UI objects.
In this particular application, my scripts are roughly loaded like so:
/javascripts/lib/jquery.min.js
/javascripts/lib/jquery-ui.min.js
...
/javascripts/company.utils.js
/javascripts/company.helpers.js
...
page level includes of javascript libraries
...
page level javascript
So I'm thinking of going into company.utils.js and define a monkeypatch like so:
$.ui.progressbar.prototype.min = -1;
However, I'm curious if this is the right way to monkeypatch this object. Pretty sure it is, but thought I would ask the wider StackOverflow community, and offer something googlable for future searchers.
Yes, that's correct. Alternatively, if you're using jQuery UI 1.9, you can use the widget factory to define your extension:
$.widget( "ui.progressbar", $.ui.progressbar, {
min: -1
});
Though it is slightly more verbose.

How can I trigger a completion menu in a Sublime Text 2 snippet?

Can I trigger a code completion menu in a Sublime Text 2 snippet? I want a tab stop to display a completion menu with options instead of just highlighting the text.
For example, tabbing once in this snippet will highlight _link. Instead of just highlighting _link, it is possible to display a completion menu with other options like _selector, _content, and make a choice?
<snippet>
<content><![CDATA[it \{ should${1:_not} have${2:_link} \}]]></content>
<tabTrigger>it</tabTrigger>
<scope>source.ruby</scope>
<description>it { should_? have_? }</description>
</snippet>
Well, what you want is not really possible. However, you could set up a macro that would (1)insert a snippet and (2) activate autocomplete, but I don't think that's really what you want since you can't have custom options that way. You could also consider doing what the ZenCoding plugin does. The plugin will have a tabstop that like this: ${1:option1/option2/option3}. This will at least have the options displayed but they won't really allow for easy selecting and can get really busy fast. You're other option is just to have snippets for your common options and setting the scopes accordingly. For example, where it says <scope>...</scope>, you can specify a specify position where the snippet will apply instead of the just the default source.language. For more about scopes, I suggest you consult the docs here. Using this method might be the easiest and best way. That way in your snippet you could just trigger the autocomplete and the options will include your snippets. A few other options to look into could be creating a .sublime-completions file with a custom scope, or making something similar to Packages/HTML/html_completions.py.

Resources