I was wondering if anyone is familiar with putting polymer dart and graphs together. I'm looking into using Google graph APIs, however I wanted to put some feelers out there if anyone was handling them different.
I think SVG + Polymer makes for a great foundation for charting libraries!
I experimented with SVG and data-binding a while back and was very happy with the results. My repository of experiments is here: https://github.com/justinfagnani/svg-binding
Custom elements would be a really nice way to allow for chart configuration. You could offer a default bar chart with a tag like <chrt-bar-chart data="{{ myData }}">, but allow incremental customization by supplying more attributes or child elements:
<chrt-chart>
<chrt-x-axis start="10" end="100"></chrt-x-axis>
<chrt-grid spacing="100"></chrt-grid>
<chrt-bars>
<chrt-series name="Series One" data="{{ myData }}"></chrt-series>
<chrt-series name="Series Two" data="{{ myOtherData }}"></chrt-series>
</chrt-bars>
</chrt-chart>
For a rough example.
Of course, you probably don't want to write your own configurable charting library, so if you check the bar chart example in my repo you can see how much work it is to roll you own chart from scratch. Being able to write SVG with data-bindings made it simple enough that you might consider doing it without a library.
Related
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.
In the Dart Web UI package, it is possible to create bindings using the {{}} or bind-value syntax. Is this also possible, when DOM elements are created in code?
Something like
new Element.html('<div>Value: {{str}}</div>');
and
new Element.html('<input type="text" bind-value="str">');
binding an event to str, without manually piecing the strings together?
Note: this question was asked earlier today, but was deleted before it was answered, but I wanted to know the answer, so I'm reposting it.
Quick answer, no.
The bindings need to be processed by the dwc transformer, which converts Web Components and MDV code into "vanilla" Dart and HTML (suitable for compilation to "vanilla" JavaScript).
Generally, you should use <template> tags to instantiate new elements.
An alternative is to wrap these bits of text inside a custom element, which you can transform with dwc and instantiate manually.
Intro:
I'm trying out LESS in an asp.net mvc environment.
I use dotless for server side processing (and I wouldn't want to use client side processing especially afer publishing the complete project).
I have to apply a design where there are different color schemes depending on different things (e.g. time of the day).
Less felt very powerful in this case as designing a parameterized css and only changing like 10 variables at the beginning of the file for every theme was really uplifting.
Problem:
But I would need to somehow change the color themes from an outside parameter.
Ideas:
First I thought that an URL parameter like style.less?theme=fuschia would be good, but I found no way to parse something like this.
Then I thought that making a very short blue.less, green.less, orange.less consisting only declared color variables, and including the main.less in every one of them would be a solid solution.
I had no chance to try out the second solution, but I thought this would be a good time to ask for advice on the most robust way of doing this.
The problem again is: I want to control some things in my less file from the outside.
Yes you can (because I implemented that feature for exactly that reason).
Dotless supports parameters from the outside via the querystring parameter.
<link rel="stylesheet" href="style.less?foo=bar" />
Will let you use the following less:
#foo = bar;
The parameter injection code is very simple. it just prepends the variable declarations to your normal less file, so anything that comes as a querystring parameter will follow the above syntax.
The code in question is very simple: https://github.com/dotless/dotless/blob/master/src/dotless.Core/Engine/ParameterDecorator.cs
AFAIK, you cannot pass parameters for dotnetless to use to do the compile.
As a suggestion, why not just call different less files? This would be fairly easy to do by using a Viewbag property.
To make the different less ones, You first create a less file with each set of colors in them. Then you import your base css file. dotnetless will merge the color definations in the parent file with the usages in the base file. So you have something like -
#baseGray: #ddd;
#baseGrayDark: darken(#baseGray, 15%);
#baseGrayLight: lighten(#baseGray, 10%);
#import "baseCss.less";
I just tested this on and MVC3 project and it works.
I'm working on my first very complex JQuery based application.
A single web page can contain hundreds of JQuery related code for example to JQueryUI dialogs.
Now I want to organize code in separated files.
For example I'm moving all initialization dialogs code $("#dialog-xxx").dialog({...}) in separated files and due to reuse I wrap them on single function call like
dialogs.js
function initDialog_1() {
$("#dialog-1").dialog({});
}
function initDialog_2() {
$("#dialog-2").dialog({});
}
This simplifies function code and make caller page clear
$(function() {
// do some init stuff
initDialog_1();
initTooltip_2();
});
Is this the correct pattern?
Are you using more efficient techniques?
I know that splitting code in many js files introduces an ugly band-bandwidth usage so.
Does exist some good practice or tool to 'join' files for production environments?
I imagine some tool that does more work than simply minimize and/or compress JS code.
Some suggestions I might add:
keep all your variables in a globally available, multi-structured object, something like: MyVars = { dialogs: {}, tooltips: {} } and then use that across all your scripts
use call or apply methods for dynamically calling custom function names,if you perhaps want to keep the above object lightweight
For tidying things up, you could read this: http://betterexplained.com/articles/speed-up-your-javascript-load-time
This sounds fairly okay too me. Just two notes:
Use descriptive method names. "initDialog_1" doesn't tell you anything about the dialog it initializes.
While keeping JS code split into several files eases development it harms the felt performance of your interface. You could merge all files into one during build/deployment/runtime of your app. How to do it best heavily depends on your environment though.
I'm working on something fairly complex in JS right now, and have been wondering the same thing. I looked at various "module" implementations but while they look "cool" they don't seem to offer much value.
My plan at this point is to continue referencing lots of script files from my .html page (the plan is to only have one .html page, or very few).
Then when I'm building the release version, I'll write a very simple tool to fit into my build process, which will discover all the scripts I reference from the .html pages and concatenate them into one file, and replace the multiple <script> elements with a single one, so that only one request is necessary in the "release" version.
This will allow the compression to work across all the script text instead of on each separate file (like doing tar followed by gzip) and should make a difference to the script download time (though I should stress I haven't actually implemented it yet).
You usually want to keep all of your javascript inside one file. Less HTTP requests is usually better. If you take a look at the jQuery source, you'll notice that every function and property is right there in the jQuery global object:
jQuery.fn = jQuery.prototype = {
init: function(){ ... },
animate: function() { ... },
each: function() { ... },
// etc
}
However, the pattern you seem to be interested seems similar to the "module" pattern. The YUI framework uses this pattern, and allows developers to "require" different components of the library from the core module via HTTP request. You can read more about YUI here:
http://developer.yahoo.com/yui/3/yui/
I need a way to add text comments in "Word style" to a Latex document. I don't mean to comment the source code of the document. What I want is a way to add corrections, suggestions, etc. to the document, so that they don't interrupt the text flow, but that would still make it easy for everyone to know, which part of the sentence they are related to. They should also "disappear" when compiling the document for printing.
At first, I thought about writing a new command, that would just forward the input to \marginpar{}, and when compiling for printing would just make the definition empty. The problem is you have no guarantee where the comments will appear and you will not be able to distinguish them from the other marginpars.
Any idea?
todonotes is another package that makes nice looking callouts. You can see a number of examples in the documentation.
Since LaTeX is a text format, if you want to show someone the differences in a way that they can use them (and cherry pick from them) use the standard diff tool (e.g., diff -u orig.tex new.tex > docdiffs). This is the best way to annotate something like LaTeX documents, and can be easily used by anyone involved in the production of a document from LaTeX sources. You can then use standard LaTeX comments in your patch to explain the changes, and they can be very easily integrated. If the document lives in a version control system of some sort, just use the VCS to generate a patch file that can be reviewed.
I have used changes.sty, which gives basic change colouring:
\added{new text}
\deleted{old text}
\replaced{new text}{old text}
All of these take an optional parameter with the initials of the author who did this change. This results in different colours used, and these initials are displayed superscripted after the changed text.
\replaced[MI]{new text}{old text}
You can hide the change marks by giving the option final to the changes package.
This is very basic, and comments are not supported, but it might help.
My little home-rolled "fixme" tool uses \marginpar where possible and goes inline in places (like captions) where that is hard to arrange. This works out because I don't often use margin paragraphs for other things. This does mean you can't finalize the layout until everything is fixed, but I don't feel much pain from that...
Other than that I heartily agree with Michael about using standard tools and version control.
See also:
Tips for collaboratively editing a LaTeX document (which addresses you main question...)
https://stackoverflow.com/questions/193298/best-practices-in-latex
and a self-plug:
How do I get Emacs to fill sentences, but not paragraphs?
You could also try the trackchanges package.
You can use the changebar package to highlight areas of text that have been affected.
If you don't want to do the markup manually (which can be tedious and interrupt the flow of editing) the neat latexdiff utility will take a diff of your document and produce a version of it with markup added to visually display the changes between the two versions in the typeset output.
This would be my preferred solution, although I haven't tested it out on large, multi-file documents.
The best package I know is Easy Review that provides the commenting functionality into LaTeX environment. For example, you can use the following simple commands such as \add{NEW TEXT}, \remove{OLD TEXT}, \replace{OLD TEXT}{NEW TEXT}, \comment{TEXT}{COMMENT}, \highlight{TEXT}, and \alert{TEXT}.
Some examples can be found here.
The todonotes package looks great, but if that proves too cumbersome to use, a simple solution is just to use footnotes (e.g. in red to separate them from regular footnotes).
Package trackchanges.sty works exactly the way changes.sty. See #Svante's reply.
It has easy to remember commands and you can change how edits will appear after compiling the document. You can also hide the edits for printing.