Blog

Kdo vyplňuje DPFO 2021 (daňové přiznání k příjmu fyzických osob) za rok 2021, tak již může uplatňovat novou výši slevy na poplatníka, která vzrostla o 3000 Kč na 27840 Kč. Tak na to myslete při vyplňování formulářů pro finančák :-).

Nedávno jsem řešil problém, jak v unit testech rozchodit Autofac webového projektu. Řešení, které mi nakonec fungovalo, spočívalo v nainstalování totožných nuget balíčků do projektu testů, jako byly ve webovém projektu. Též je vhodné, aby i verze nuget balíčků byly shodné.

Co je ale nezbytně nutné, je to, že při registraci služeb do Autofac containeru se místo ".InstancePerRequest()" musí používat ".InstancePerLifetimeScope()". Důvodem je, že projekt testů (podobně jako třeba konzolová aplikace) nezná nic jako http request. Nutno zmínit, že Autofac podporuje ".InstancePerLifetimeScope()" až od určité veze (myslím že od verze 5), takže pokud používáte nějakou hodně starou verzi, tak možná budete muset nejprve updatovat na novější verzi.

Při dodržení výše zmíněných rad již nic nebrání použití Autofacu webu v unit testech. Postupovat se pak může shodně, jako když se použije autofac v konzolové aplikaci.

Prakticky to pak uvnitř test metody (v MSTest projektu) může vypadat třeba takto:

  var container = AutofacConfiguration.ConfigureContainer();
  using (ILifetimeScope scope = container.BeginLifetimeScope())
  {
    var report = AutofacTestsHelper.ResolveAllAndReport(container);
    Assert.AreEqual(0, report.Count(), string.Join("\n\n", report));
  }

Před nějakou dobou jsem na jednom z eshopů řešil problém, že bootstrap 4 nemá připravenou podporu pro "XXL displeje" v podobě vhodného breakpointu (např. od šířky displeje 1600px a více) a příslušných css tříd jako "col-xxl".

Dále jsem řešil, že pro tyto "XXL displeje", jsem chtěl ve výpisech produktů zobrazovat 8 položek na řádek tak, aby vyplňovaly vždy celý řádek. Toho se v bootstrap 4 a jeho dvanácti sloupcích standardně dosáhnout nedá. Položka může zabírat 1, 2, 3, 4, 6, 12 sloupců, což odpovídá 12, 6, 4, 3, 2, 1 položkám na stránku. Pro 8 položek na stránku je potřeba zavést "jeden a půl" sloupec.

K tomuto tématu dají najít užitečné odkazy, jako např.:

• podpora XXL displejů: https://stackoverflow.com/questions/48924751/how-to-create-new-breakpoints-in-bootstrap-4-using-cdn
• podpora "jeden a půl" sloupce: https://stackoverflow.com/questions/30026855/can-i-give-the-col-md-1-5-in-bootstrap/30027585

S trochou času na projití rad v uvedených odkazech a s chutí do ohýbání bootstrapu 4 se dá podpora XXL displejů a "jeden a půl" sloupce vyřešit :-).

Pokud však není čas, nebo chuť, ale při tom by se vám hodila podpora XXL displejů a "jeden a půl" sloupce, tak pak mě můžete kontaktovat ZDE.

Číslo 24 je podle mě zajímavé zejména v kontextu responzivního designu, což je dáno tím, že se dá rozepsat na několik různých násobků dvou celých čísel. Konkrétně se jedná násobky: 2x12, 3x8, 4x6, 6x4, 8x3 a 12x2. 

Možná si říkáte "Co je na tom zajímavého?". Vezměte však v úvahu CSS framework Bootstrap s jeho dvanácti sloupcovým grid systémem a představte si třeba výpis produktů nějakého eshopu, kde jsou tisíce produktů.

Z důvodů:

• optimalizace rychlosti načítání webu, 
• nižší zátěže serveru, 
• menší velikosti DOMu, 
• schopnosti uživatelů rozumně vidět najednou jen nějaké menší množství produktů... a tak podobně, 

je lepší ten výpis udělat stránkovaný. Nabízí se otázka, kolik zobrazovat produktů na jedné stránce výpisu? A co třeba právě těch 24? Znovu se podívejte na zmíněné násobky a možná už vám bude jasné kam mířím. Výše zmíněné násobky se skvěle hodí na rozdělení výpisu produktů do dvanácti sloupcového layoutu Bootstrapu. Díky tomu, že se jedná o celočíselné násobky, tak produkty i na posledním řádku vyplní vždy celý řádek (pochopitelně pokud se nejedná o poslední stránku, kde může být méně produktů).

Takže až vás někdy napadne otázka "Proč se v daném eshopu zobrazuje 24 produktů na stránku a ne třeba 25?", tak vězte že to má co dělat s responzivním designem.

Nedávno jsem na tomto webu, vytvářeném v asp.net core Blazor, chtěl udělat jednu optimalizaci v souvislosti s loadováním CSS. Šlo o to, že pro pro většinu stránek na mém webu (včetně homepage) nejsou potřeba všechny CSS. Zejména se jednalo o jeden velký CSS soubor, který je potřeba pouze na těch stránkách, kde používám jeden wysiwyg editor. To znamená pouze někde v administraci, ale nikoliv na stránkách, které vidí návštěvníci mého webu. Problém byl, že tento jeden CSS soubor znatelně zpomaloval načítání úplně všech stránek webu včetně homepage. 

První co mě napadlo bylo, že využiji něco, co znám z MVC - "@section styles {...}". Bohužel jsem ale zjistil, že Blazor nic takového nenabízí. Trochu jsem kolem toho hledal, ale nic moc rozumného jsem nenašel a tak jsem tento problém prozatím obešel tak, že jsem z "hlavního layoutového souboru" odstranil link na daný CSS soubor a naopak ho přidal do příslušných Blazor komponent, kde používám wysiwyg editor. Bylo to sice rychlé a zdá se, že i fungující řešení, ale je to tak trochu "na pankáče".

Časem se chci k tomuto problému vrátit a vyřešit to nějak čistěji. Až něco rozumného najdu nebo vymyslím, tak zde o tom poreferuji.

Pokud stejně jako já vytváříte web, který v sobě má blog a v něm chcete implementovat vyhledávání přes všechny příspěvky na blogu, tak pravděpodobně brzy narazíte na stejné otázky jako já...

Jak udělat ignorování diakritiky (háčků a čárek) a HTML tagů?

Nejprve trochu k tomu, proč to vůbec řešit?

Hlavním důvodem je pochopitelně to, aby vyhledávání našlo to, co má a naopak aby nenašlo to, co nemá. Takto bych to popsal ve zkratce :-D. Nyní ale dost legrace a trochu podrobněji...

Proč ignorování diakritiky a jak toho docílit?

Je mnoho lidí, kteří používají EN klávesnici a tím pádem vůbec nepíšou háčky a čárky. Stejně tak je určitě i mnoho lidí, kteří od vyhledávání zkrátka očekávají, že když do vyhledávání na blogu napíšou "Vyhledavani", tak to najde i příspěvky, kde se vyskytuje slovo "vyhledávání".

Ze způsobu, jak docílit ignorování diakritiky ve vyhledávání, jsem jako nejefektivnější řešení shledal nastavení vhodné "collation" na DB, nebo přímo na konkrétních databázových sloupcích, kterých se vyhledávání týká. Pokud stejně jako já používáte Entity Framework Core, tak od verze EF Core 5.0 je možné nastavovat collation na DB, nebo databázových sloupcích pomocí metod z tohoto šikovného frameworku. V mém případě, kdy kvůli hostingu mohu používat maximálně .net Core 3.1, jsem toto pěkné řešení z EF Core 5.0 nevyužil. Naštěstí nastavení collation přes čisté SQL není nijak složité a dá se udělat to, že se vygeneruje prázdná migrace a v ní se zapíše něco takového:

public partial class CollationChanges : Migration
    {
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.Sql(@"
                ALTER TABLE dbo.Blog ALTER COLUMN Title VARCHAR(256) COLLATE Latin1_General_CI_AI
                ALTER TABLE dbo.Blog ALTER COLUMN Content VARCHAR(max) COLLATE Latin1_General_CI_AI");
        }
 
        protected override void Down(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.Sql(@"
                ALTER TABLE dbo.Blog ALTER COLUMN Title VARCHAR(256) COLLATE Latin1_General_CI_AS
                ALTER TABLE dbo.Blog ALTER COLUMN Content VARCHAR(max) COLLATE Latin1_General_CI_AS");
        }
    }

Jak lze vidět z příkladu, tak v migraci jsem použil collation "Latin1_General_CI_AI", kde sufix "_CI_AI" je zkratka pro "Case Insensitive" a "Accent Insensitive", což znamená "ignoruj velikosti písmen" a "Ignoruj akcent", kde tím akcentem je myšlena diakritika.

Takže takto se dá celkem jednoduše udělat ignorování diakritiky ve vyhledávání.

Proč ignorování HTML tagů a jak toho docílit?

Pokud na svém blogu využíváte k editaci jeho obsahu nějaký "Rich text editor", nebo "wysiwyg editor", tak se do databáze do příslušného sloupce (např. dbo.Blog.Content) kromě "textového obsahu" uloží též HTML tagy. Problém pak nastává, pokud v takovém sloupci chcete hledat výskyt nějakého textu, který se může shodovat s něčím, co není tím "textovým obsahem". Např. můžu chtít vyhledat články, které obsahují slovo "color". Pokud bude obsah článku obsahovat HTML jako: "<span style="color:#4ec9b0;">CollationChanges</span>", tak pak by se tento článek zobrazil ve výsledcích vyhledávání i přes to, že jeho text nikde neobsahuje slovo "color".

Ze způsobu, jak docílit ignorování HTML tagů ve vyhledávání, jsem jako nejefektivnější řešení shledal vytvoření dalšího databázového sloupce nazvaného např. "PlainContent", kam se pak ukládá to samé, jako do sloupce Content, avšak před uložením se provede "očištění od HTML tagů". Pak stačí při vyhledávání nefiltrovat přes sloupec "Content", ale místo filtrovat přes sloupec "PlainContent".

Závěr

K výše popsanému postupu jsem dospěl na základě svých zkušeností, názorů na to, jak by se co mělo dělat atd., takže je možné, že někdo dospěl k nějakému jinému a hezčímu řešení. Nicméně toto řešení je vyzkoušené (zde na tomto blogu) a jak je vidět, tak funguje :-).

Měl by někdo zájem podílet se na vývoji velkého eshopu (zaměřeného nejen na kancelářské potřeby) v C# asp.net MVC?

• Ideálně by to měl být někdo, kdo umí dobře MVC a má povědomí i o HTML, CSS, JS.
• Neztratily by se ani znalosti SQL a zkušenosti s MSSQL.
• Mělo by jít o někoho, kdo bude chtít projekt udržovat a posouvat dál a umí psát čitelný a udržitelný kód.

Mnohokrát jsem se dostal k úpravám v kódu, který nebyl napsaný zrovna čitelně a kde některé z jeho částí ani nemohly být nikdy spuštěny (třeba metody které se nikdy nezavolaly, objekty které se nikde nepoužívaly, nebo třeba if podmínky vycházející za všech okolností jako false). A v takovém kódu jsem měl udělat nějakou dílčí úpravu.

Nabízí se filozofická otázka - má smysl před samotnou chtěnou úpravou kód nejprve vyčistit od nepoužívaných částí a "zrefaktorovat" ho?

Samozřejmě závisí na konkrétní situaci, hlavně na tom jak moc se na danou úravu spěchá, ale obecně bych řekl, že smysl to rozhodně má.

Zejména to má smysl v případech, kdy je pravděpodobné, že se ke kódu v budoucnu bude někdo vracet a opět do něj zasahovat.

Kdo má stejný názor a nebo zcela opačný, tak mi může napsat :-)

Též jste někdy narazili na problém "System.InvalidOperationException: A second operation started on this context before a previous operation completed"?

Potřebujete řešení? Neváhejte mě kontaktovat a najdeme řešení :-).

Já jsem musel řešit tuhle situaci už při tvorbě tohoto webu, neboť je dělaný právě v Blazor Server a jako ORM je zde použit Entity Framework Core.