Dzisiaj kolejne udogodnienie w CSS dostarczane przez LESS. W klasycznym CSS nie ma możliwości dziedziczenia klas. Jeśli chcemy, aby klasa B miała właściwości klasy A oraz kilka rozszerzających wtedy zwykle musimy duplikować kod.
W LESS rozszerzenia definiuje się następująco:

.childClass {
  &:extend(.baseClass);
  background: blue;
}

.baseClass {
  color: red;
}

Na wyjściu mamy:

.childClass {
  background: blue;
}
.baseClass,
.childClass {
  color: red;
}

Inna składnia to:

.childClass {
  background: blue;
}

.baseClass {
  color: red;
}

.childClass:extend(.baseClass){}

Więcej informacji znajduje się w dokumentacji. Na blogu zwykle planuję tylko umieszczać kilka przykładów jako wprowadzenie.

Dzisiaj kolejna przydatna konstrukcja LESS. Często zachodzi potrzeba stworzenia klasy na podstawie kilku innych klas. Załóżmy, że mamy:

.class1
{
  color:red;
}
.class2
{
  font-size:10px;
}
.finalClass
{
  color:red;
  font-size:10px;
  
  border-color:blue;
}

FinalClass składa się zarówno z class1 jak i class2. Ponadto rozszerza możliwości o border-color. Za pomocą mixin możemy kod skrócić do:

.class1
{
  color:red;
}
.class2
{
  font-size:10px;
}
.finalClass
{
  .class1();
  .class2();
  
  border-color:blue;
}

Oczywiście w praktyce przydatne jest to, gdy klasy mają więcej właściwości niż jedna. W przypadku jednej właściwości lepiej skorzystać ze zmiennych.

Powyższy mixin wykona się do wspomnianych wcześniej stylów:

.class1 {
  color: red;
}
.class2 {
  font-size: 10px;
}
.finalClass {
  color: red;
  font-size: 10px;
  border-color: blue;
}

Możliwe jest również zadeklarowanie mixin za pomocą nawiasów ():

.class1()
{
  color:red;
}
.class2()
{
  font-size:10px;
}
.finalClass
{
  .class1();
  .class2();
  
  border-color:blue;
}

Różnica polega na tym, że na wyjściu nie pojawią się .class1\.class2:

.finalClass {
  color: red;
  font-size: 10px;
  border-color: blue;
}

Do mixin można przekazać parametry:

.class1(@color)
{
  color:@color;
}

.finalClass
{
  .class1(blue);
    
  border-color:blue;
}

Analogicznie, parametry mogą przyjmować domyślne wartości:

.class1(@color:green)
{
  color:@color;
}

.finalClass
{
  .class1();
    
  border-color:blue;
}

Należy pamiętać, że jeśli chce się przekazać kilka parametrów należy je oddzielić średnikiem tzn. @color;@color2 itd.

Tak jak w C#, parametry można przekazywać za pomocą nazwy czyli zamiast .class(red) można .class(@color:red). Do dyspozycji mamy również specjalny parametr o nazwie @arguments, który po prostu zawiera listę wszystkich argumentów:

.class1(@width;@style;@color)
{
  border:@arguments;
}

.finalClass
{
  .class1(@width:2px;@style:solid;@color:red);
    
  border-color:blue;
}

Czasami zachodzi potrzeba odpalenia różnych mixin w zależności od kontekstu, np. używanego urządzenia. Spójrzmy na następujący kod:

.class1(mobile)
{
  font-size:1px;
}
.class1(desktop)
{
  font-size:2px;
}


.finalClass
{
  .class1(mobile);
    
  border-color:blue;
}

Zdefiniowaliśmy tutaj różne mixin w zależności od typu urządzenia. Przekazując jako parametr mobile, ustawimy rozmiar czcionki na 1. Na wyjściu pojawi się zatem:

.finalClass {
  font-size: 20px;
  font-size: 1px;
  border-color: blue;
}

Jeśli zadeklarujemy pierwszy parametr jako zmienną wtedy uzyskamy generyczną klasę:

.class1(@device)
{
  border-width:4px;
}

.class1(mobile)
{
  font-size:1px;
}
.class1(desktop)
{
  font-size:2px;
}

.finalClass
{
  .class1(mobile);
    
  border-color:blue;
}

W powyższym przypadku “mobile” zostanie dopasowany do dwóch klas:

.finalClass {
  border-width: 4px;
  font-size: 1px;
  border-color: blue;
}

Jak widzimy, mixins mogą w znaczącym stopniu skrócić arkusze CSS poprzez unikanie duplikacji kodu.

Na blogu rzadko poruszam tematy CSS, ale czasami nawet jak ma się bardzo małą warstwę prezentacji, warto zainwestować trochę czasu w poznanie nowych bibliotek.

Dzisiaj chciałbym przedstawić LessCss.  Biblioteka stanowi pewnego rodzaju pre-processor, który rozszerza możliwości klasycznego CSS. Na wyjściu zatem pojawi się zwykły CSS, który jest obsługiwany przez wszystkie przeglądarki. Sprawą “kompilacji”, zajmiemy się w innym wpisie, ponieważ istnieje wiele sposobów. Jednym z nich jest np. kompilowanie za pomocą  JavaScript po stronie klienta. W tym poście będę korzystał z narzędzia online, które można znaleźć tutaj.

Załóżmy, że mamy kilka klas, które korzystają z tego samego koloru:

.customClass1
{
  color:red;
}

.customClass2
{
  color:red;
}

.customClass3
{
  color:red;
}

Za pomocą LESS możemy zdefiniować zmienną:

@customColor: red;

.customClass1
{
  color:@customColor;
}

.customClass2
{
  color:@customColor;
}

.customClass3
{
  color:@customColor;
}

Po w klejeniu wspomniany wcześniej edytor online, zobaczymy, że na wyjściu @customColor zostanie zastąpiona wartością Red. Wszelkie zmienne w Less definiujemy za pomocą @. Zmiana wartości odbywa się za pomocą znaku ‘:’ (dwukropek).

Wszelkie stałe zatem można w łatwy sposób umieścić tylko w jednym miejscu. Zmienne nie ograniczają się jedynie do wartości. Możliwe jest również umieszczenie selektorów CSS w nich, tzn.:

@customSelector: .customClass;

@{customSelector}
{
  color:red;
}

Po kompilacji:

.customClass {
  color: red;
}

Zmienna ładowane są w sposób “lazy-loading. W praktyce oznacza to, że nie muszą być deklarowane przed ich użyciem. Poniższy kod również wygeneruje taką samą odpowiedź:

@{customSelector}
{
  color:red;
}

@customSelector: .customClass;

Osobiście uważam, że może z tego wyniknąć wiele problemów.

W dokumentacji znalazłem również informacje, że możliwe jest korzystanie ze zmiennej jako nazwy dla kolejnej zmiennej. Spójrzmy na następujący kod:

@varName: 'test';
@test: 'red';

.customClass
{
  color:@@varName
}

Po kompilacji:

.customClass {
  color: 'red';
}

Moim zdaniem bardzo niebezpieczna konstrukcja. Podwójny operator @ wyciągnie najpierw wartość ze zmiennej varName, a potem użyje jej jako docelowej zmiennej.

W następnych wpisach skupie się na pozostałych możliwościach LESS oraz na kompilacji LESS do normalnego CSS.

ASP.NET Core ułatwia w znaczący sposób IoC. Przede wszystkim wbudowano w framework dosyć prostą implementację IoC. Oznacza to, że w wielu przypadkach nie trzeba już instalować zewnętrznych framework’ow takich jak AutoFac.  W pliku Startup znajdziemy metodę ConfigureServices:

        public void ConfigureServices(IServiceCollection services)
        {
            // Add framework services.
            services.AddApplicationInsightsTelemetry(Configuration);

            services.AddMvc();
        }

Jeśli chcemy zarejestrować instancję jako singleton wtedy wystarczy:

services.AddSingleton<ITest, ConcreteTest>();

Nic więcej nie trzeba konfigurować. Instancja automatycznie zostanie wstrzyknięta do kontrolerów jak i widoków. Sprawa w przypadku kontrolerów wygląda prosto i wystarczy po prostu stworzyć konstruktor:

        public HomeController(ITest test)
        {
            _test = test;
        }

W przypadku widoków, również możemy korzystać z wstrzykniętych instancji:

@using Microsoft.Extensions.Configuration
@inject ITest test

@{
    ViewData["Title"] = "About";
}

<h2>@ViewData["Title"].</h2>


<h3>@ViewData["Message"]</h3>




@test.GetText()

AddSingleton tworzy oczywiście pojedynczą instancję. Istnieje również metoda AddTriansient:

services.AddTransient<ITest, ConcreteTest>();

Tworzy ona nową instancję za każdym razem, gdy dochodzi do wstrzyknięcia.

Inny sposób to AddScoped:

services.AddScoped<ITest, ConcreteTest>();

AddScoped będzie współdzielić instancję w ramach tego samego zapytania. Przydatne, kiedy mamy wiele klas do których wstrzykujemy ten sam typ. W wielu przypadkach nie ma potrzeby tworzenia osobnych instancji.

Często tworzymy pewien “wrapper” dla wartości pochodzących z Web.Config, np.:

class Config
{
    public int MaxResults{get;set;}
}

Następnie np. w IoC inicjalizujemy obiekt wartościami pochodzącymi z Web.Config:

Config config = new Config();
config.MaxResults = ConfigutationManager.AppSettings["MaxResults].Value;

W ASP.NET Core istnieje łatwy sposób mapowania wartości bezpośrednio na klasę w C#. Oczywiście coś podobnego było i tak możliwe w starych wersjach ASP.NET, ale nie było to tak wygodne.

Załóżmy, że mamy następujący plik konfiguracyjny w ASP.NET Core (plik settings.json):

{
"ApplicationInsights": {
"InstrumentationKey": ""
},
"Config": {
"MaxResults": 15
},

"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
}
}

Przede wszystkim musimy zainstalować pakiet “Microsoft.Extensions.Options.ConfigurationExtensions”, np. poprzez dodanie odpowiedniego wpisu w project.json:

"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0-rc2-final"

W Start.ConfigureService dodajemy następujący kod:

            services.AddOptions();
            services.Configure<Config>(Configuration.GetSection("Config"));

Pierwsza linia umożliwi m.in. wstrzyknięcie Config do kontrolera. Druga z kolei, naturalnie czyta wartości z pliku JSON. Samo wstrzyknięcie sprowadza się do zdefiniowania odpowiedniego konstruktora:

        private readonly IOptions<Config> _configValue;

        public HomeController(IOptions<Config> _configValue )
        {
            this._configValue = _configValue;
        }

         public IActionResult About()
        {
            ViewData["Message"] = _configValue.Value.MaxResults.ToString();

            return View();
        }

Dosyć zwięzłe rozwiązanie. Nie trzeba samemu wstrzykiwać do kontenera IoC czy nawet odczytywać konkretnych wartości z pliku konfiguracyjnego.