The page https://developer.sonos.com/build/content-service-add-features/customize-display/create-hero-views/ has conflicting information for ItemThumbnails. One part says the default is "none", and then at the very bottom it says the default for non-album types is "albumArtUri". In practice the rules seem more complicated than either of these but I can't figure out a rule that works for everything?
Related
I'm building a single page application in Elm and was having difficulty deciding how to split my code in files.
I ended up splitting it using 1 module per page and have Main.elm convert the Html and Cmd emitted by each page using Cmd.map and Html.map.
My issue is that the documentation for both Cmd.map and Html.map says that :
This is very rarely useful in well-structured Elm code, so definitely read the section on structure in the guide before reaching for this!
I checked the only 2 large apps I'm aware of :
elm-spa-example uses Cmd.map (https://github.com/rtfeldman/elm-spa-example/blob/cb32acd73c3d346d0064e7923049867d8ce67193/src/Main.elm#L279)
I was not able to figure out how https://github.com/elm/elm-lang.org
deals with the issue.
Also, both answers to this stackoverflow question suggest using Cmd.map without second thoughts.
Is Cmd.map the "right" way to split a single page application in modules ?
I think sometimes you just have to do what's right for you. I used the Cmd.map/Sub.map/Html.map approach for an application I wrote that had 3 "pages" - Initializing, Editing and Reporting.
I wanted to make each of these pages its own module as they were relatively complicated, each had a fair number of messages that are only relevant to each page, and it's easier to reason about each page independently in its own context.
The downside is that the compiler won't prevent you from receiving the wrong message for a given page, leading to a runtime error (e.g., if the application receives an Editing.Save when it is in the Reporting page, what is the correct behavior? For my specific implementation, I just log it to the console and move on - this was good enough for me (and it never happened anyway); Other options I've considered include displaying a nasty error page to indicate that something horrible has happened - a BSOD if you will; Or to simply reset/reinitialize the entire application).
An alternative is to use the effect pattern as described extensively in this discourse post.
The core of this approach is that :
The extended Effect pattern used in this application consists in definining an Effect custom type that can represent all the effects that init and update functions want to produce.
And the main benefits :
All the effects are defined in a single Effect module, which acts as an internal API for the whole application that is guaranteed to list every possible effect.
Effects can be inspected and tested, not like Cmd values. This allows to test all the application effects, including simulated HTTP requests.
Effects can represent a modification of top level model data, like the Session 3 when logging in 3, or the current page when an URL change is wanted by a subpage update function.
All the update functions keep a clean and concise Msg -> Model -> ( Model, Effect Msg ) 2 signature.
Because Effect values carry the minimum information required, some parameters like the Browser.Navigation.key are needed only in the effects perform 3 function, which frees the developer from passing them to functions all over the application.
A single NoOp or Ignored String 25 can be used for the whole application.
I have generated a grammar in ANTLR4. A sample excerpt is shown below:
list : defunExpr # defun
: lambdaExpr # lambda
: condExpr # cond
...
: items # other
;
The rules are listed in order of priority and are called as appropriate when testing the grammar. All higher priority rules of #defun, #lambda, #cond, etc. would also match items (#other) if they did not match higher up (expected behavior of placing higher-priority rules before lower).
I then implemented a simple listener-based application in Java, which simply formats the parsed code and prints it back out the the console. I have overridden the appropriate enter/exit methods for #defun, #lambda, #cond, etc. I would like to implement a generalized catch-all for items which do not match the more specific rule. However, when I implement enter/exit methods for #other, it executes for every matched rule further up the priority as well, effectively outputting formatted code twice for rules such as #defun, #lambda, #cond, etc.
Is there some way to achieve this behavior? I have a handful of specific rules I want to implement, and then have a general case catch the others. The grammar parses properly (test rig shows expected behavior over numerous test cases), but the catch-all method (enterOther) seems to act upon the specific rules as well.
EDIT: Wow, after all this time and posting this question, I now actually believe it is a grammar error. I will leave the question open until I verify, however.
Thanks for the interest, guys. I'm not evaluating anything, just echoing parsed input, so listeners work fine. Grammar was actually fine, non-ambiguous. The catch-all rule (it was catch-all, despite not showing enough of my grammar here) worked fine. My problem (embarrassingly), was that while I wanted to write enter/exit #other methods, I was actually writing enter/exit Expr methods the whole time, which was why all specific rules we triggered as well (since they are Exprs). Embarrassing, but lesson learned. Thanks for the ideas and taking the time. Cheers!
Can image resizer output image paths that don't contain query strings? Could not find this anywhere in documentation or googling it.
This page (http://imageresizing.net/docs/extend/extending) says that custom plugins can "Perform URL rewriting or query string expansion by registering an event handler."
Is there such a plugin, ready to be used? If so, anyone have a link?
FolderResizeSyntax is one such plugin (which simply adds and event handler to Config.Current.Pipeline.Rewrite), but you probably shouldn't use it.
Ask yourself: Why does pingdom say to remove query strings? Does it even make sense? Is there any logic behind the rule?
Query strings are often added to static resources as cache breakers and for development purposes; often they're forgotten and make it into production.
In the case of ImageResizer, they're an essential, meaningful part of the URL. Rewriting consistent name/value pairs (the querystring) into a custom URL syntax might be trendy and hip, but it adds brittleness and complexity for no actual added value.
If you have a real-world, known issues with querystrings, try the CloudFront plugin. It lets you express querystrings as image.jpg;width=100;height=100 instead of image.jpg?width=100&height=100. You still lose compatibility with all kinds of RIAPI-compliant front-end and back-end tooling, so make sure this is a real, not theoretical, issue.
In my xampp it returns the following error, when i call functions without quotes ($_SERVER[SERVER_NAME])
Notice: Use of undefined constant SERVER_NAME - assumed 'SERVER_NAME'
What i must change in php.ini to correct this?
Thanks
UPDATE:
:) Sure i know, that if i add quotes, it will work, but i need to configure server to work without quotes too.
I clearly specify my problem. In my server it returns no warnings and no errors, if i do not use quotes. It is depend on xampp version. Now i install newer version of xampp on my local machine, and it show that notices, so i can't use my last projects, because there are handreds of that notices. (it returns such notice even when i use my defined variables, for example $myVariable[myItem]).
i can use
error_reporting(0)
But that will hide all errors. So i need to just specify new rules for my server, or use older version.
So, Why the downvotes?
Edit your php.ini to disable reporting of notices. find your php.ini by doing phpinfo()
error_reporting = E_ALL ^ E_NOTICE
Or do it in the script
<?php
error_reporting(E_ALL ^ E_NOTICE);
also consider setting display_errors = Off for live websites.
It's not constant, its an associative index. Use quotes:
$_SERVER['SERVER_NAME'];
Edit: If this is on a production environment and you simply need to hide these messages to buy you time to correct the real issue, add this to your page:
// Turn off all error reporting
error_reporting(0);
Don't change the configuration to fix your bad coding habits. This is what you should do:
$_SERVER['SERVER_NAME']
not this
$_SERVER[SERVER_NAME]
You could set the error level to ignore warnings, but you might miss some other important warnings if you do that. Just do it the proper way.
Don't change your php.ini, change your code:
$_SERVER['SERVER_NAME']
Also that is not called calling a function. $_SERVER is an associative array
Update
You must be able to add the quotes, suppressing those warnings is a very bad idea. That warning is basically a message saying "Your code is invalid, but I figured out what you meant soooo... you're lucky!". You won't always be that lucky if you choose not to use quotes.
The answer is that the boys that wrote PHP decided to change it for the sake of consistency in the PHP internals, ignoring the usability consequences to PHP programmers, and now you have to live with it. So you face the tough choice of either turning off all notifications or updating all your PHP defines.
PHP4 allowed the definition of unquoted constants and it was no problem. But I import perfectly good PH4 code to PHP5 and it breaks for no other reason than "you're a bad programmer".
If the authors of PHP wanted to do something truly useful then how about a notice for when a variable that has not been set (i.e. used as an lvalue in an expression) is used. I've had to deal with hundreds of bugs caused by misspelled variable names being allowed without any warnings from PHP.
In Safari & Webkit, using only border-radius seems to work without adding the prefix -webkit- to it. Is it okay to leave -webkit- prefix for border-radius?
You miss the point of validation. You validate to avoid errors! These include: unsafe browser extensions, hacks, ie-hacks, and actual errors. By no means should you validate to make your code less cross-browser functional.
You should be aware there are such things as expected errors, and even valid code works with those. Browser extensions like -moz-, -webkit-, and -o- are expected errors. All browsers are designed to drop unknown rules. This is how CSS allows for backwards compatibility. A CSS2 supporting browser will drop the CSS3 border-radius rule. Being valid or invalid doesn't have anything to do with it, and by no means will any browser just break because of it (fortunately for us the idea of turning CSS into XML was squashed and never saw the light of day). Opera will drop -moz- rules and Firefox will drop -o- rules, this is not a error. This is expected behavior:
An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS 2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.
The w3c even defines how to write these "Vendor-specific extensions". The following are the current extensions well known ones:
-ms-, mso- Microsoft
-moz- Mozilla
-o-, -xv- Opera Software
-webkit- Apple
-khtml- KDE
There are also some you might have never even heard of:
-atsc- Advanced Television Standards Committee
-wap- The WAP Forum
Browsers implement draft-stage or partial implementations (ie. browser supports X, Y but not Z) of CSS rules, as extensions. This way they prevent any change in the spec from breaking previous versions of the browser. There have been cases where browsers have gone gun happy and implemented them as non-extensions, and the usual result has always been said browser has shot themselves in the foot, things like: "browser XXX version YYY has bad implementation of [...]". Most notably IE stands at the no.1 spot on this, but other browsers too have successfully managed to shoot themselves in the foot. When a draft becomes standard and the browser fully (or sufficiently) implements the spec, a rule is created with out the -xxx- prefix.
In recent years, all major browsers have adopted this as a de facto standard.
How and when to use -xxx- browser extensions? As usual the best practice is to design using only standards compliant code in the most advanced browser you have at your disposal then add all the safe extensions. Out of the extensions use the ones based on w3c standards or current working drafts. Don't use dropped standards/drafts or browser wannabe-standards (ie. some of the old Firefox ones). Also avoid any sort of tinkering rules unless it has a stable fallback.
In the case of the border-radius rule you have a stable fallback.
How to keep both form and function? In my opinion most people are not bothered by the "ohmygosh it's not valid" but rather the fact they are forced to write multiple rules for the same line. A simple solution to this is to use a template system. There are quite a few out there for CSS, as the problem of keeping your code DRY is a persistent one.
The are many many many different implementations out there. The basic idea though is to solve the problem using a mixin (ie. function):
=border-radius(!radius)
-moz-border-radius= !radius;
-webkit-border-radius= !radius;
-khtml-border-radius= !radius;
border-radius= !radius;
We can now write this everywhere:
.stuff
+border-radius(15px);
This code is much more flexible then just writing border-radius: 15px and hoping for the best. It's also maintainable (what no element should have more then 10px border radius? no problem).
You may run into css validation errors by doing so. - prefixed properties are regarded as optional extenstions, and thus have a lesser likelihood of causing problems.
I would suggest you keep the -webkit just incase, some browsers (IE) don't play nice when HTML/CSS don't validate. This is known as quirks mode.
border-radius supports safari 5 and later. -webkit-border-radius supports safari 3 and later.
So if you wish to have support for safari 3+ you have to use -webkit-border-radius