v2.63

I denna omgång har det handlat om några fixar. PROM-applikationen har justerats så att formuläret inte skickas två gånger vid dubbelklick på Skicka-knappen. Samma knapp har också flyttas upp för att synas bättre. Några kosmetiska justeringar har gjorts vid laddning av initital sida, bland annat hur “spinner” visas.

Just nu är det fokus på uppgradering till ExtJS v5.1 som innebär en del justeringar i framför allt våra widgets, särskilt de som har diagram. Detta hoppas vi få med till nästa vecka. Efter detta kommer ett nytt tema introduceras, som kommer förbättra läsbarhet och ge våra widgets och vår registreringsapplikation ett mer modernt utseende, detta inför den kommande övergången till helt ny webbplatsteknik, där fokus är på responsivitet.

Registercentrum Västra Götaland

Stratum 3 - möte 2

Det finns ett antal saker som vi borde få gjort, eller åtminstone påbörja innan vi dyker allt för djupt ner i Keystone JS:

A. Uppgradering till ExtJS 5.1. Här är det framför allt diagramhanteringen som blir annorlunda då vi nu satsar på den bättre och modernare “Sencha Charts”. Vad gäller själva Stratum (registreringsapplikation plus portal) samt SFRs registreringsapplikation så är det inte så mycket arbete. Vi har redan uppgraderat till ExtJS 5.0 så det mesta arbetet är taget. Däremot så innebär det en hel del för våra widgets eftersom just diagramhanteringen är ganska annorlunda. I ExtJS 5.0 så fungerade vare sig nya “Sencha Charts” eller gamla “ExtJS 4 Legacy Charts” tillräckligt bra för att vi skulle kunna växla, vilket är främsta skälet till att vi ligger kvar på v4.2.2. “Sencha Charts” fungerar under IE8, det har vi testat idag. OBS! byt sidbredd till 960px (nu 920px).

B. Byte av tema till “Crisp” (eller “Crisp Touch” — åldersfördelningen kan tala för den sistnämnda, se nedan). Detta kan låta enkelt men det är rätt mycket CSS-hack som tillkommit genom åren plus att en del vyer inte alls är gjorda för att kunna skalas på ett tillfredsställande sätt. Inte minst kan jag misstänka att det blir en del arbete i SFRs registreringsapplikation, där fler antaganden gjorts om typsnitt och grad.

Åldersfördelning bland registrerande användare i Stratum

C. Direct api:et behöver elimineras och gå upp i övrigt REST api. Hela Stratums registreringsapplikation behöver kapslas in api också. Oavsett lösning på detaljproblem är det viktigt för att lättare kunna identifiera vad som är “special” för SFR att särskilja det i “FractureApplication.js” (som tidigare), “FractureManagement.cs”, där vi lägger allt som är noterat “//SFR Exclusive” i C#-koden, och SFR-specifik CSS “Default.css” till “Fracture.css”.

Bildbank med Cloudinary kan vi titta på tidigt. Strategiskt då det gynnar vår webbredaktör. Kika på att flytta över hennes befintliga attribut på bilder plus själva bilderna. Hur funkar det? Kan vi bygga in den funktionaliteten i vårt CMS någorlunda enkelt?

Registercentrum Västra Götaland

v2.61-v2.62

Inloggning via Mobilt BankID är nu i drift. Användare med SITHS-kort (och RC-certifikat) prioriteras högre, så att inloggning med Mobilt BankID inte påverkar befintliga användare. Om SITHS-kort inte kan detekteras så visas knappen “Logga in” precis som tidigare. Skillnaden är att istället för som tidigare så gavs ett felmeddelande om att tjänstekort inte kunde identifieras, så visas nu en ny inloggningsdialog för Mobilt BankID.

Precis som med SITHS-inloggning så loggas man in automatiskt även via Mobilt BankID, det vill säga om du har loggat in och uppdaterar (till exempel trycker på F5) så behöver man inte logga in igen. En session med Mobilt BankID blir inaktiv efter 30 minuter, ungefär på samma sätt som på en bank.

Aggregat-api:et har fått en genomgång och fler kontroller av rätt variabelnivå och domän görs nu i större utsträckning. Metoden “mean” används nu enbart till medelvärden och “share” används istället då en andel efterfrågas, exempelvis ger

1
2
3
/api/aggregate/lvr/visit/total/share(weight(80))
```
andel av LVRs besöksregistreringar som väger mindre än 80 kg, medans

/api/aggregate/lvr/visit/total/mean(weight)

ger genomsnittlig vikt för samma grupp.

Fler sorters strukturer som returneras från R-servern tas nu hand om korrekt, bland annat "data.frame", "list" och "by". Detta är ett ständigt förbättringsarbete då returvärden kan se ut lite hur som helst ifrån R. Till exempel

/api/statistics/BRIMP/test

returnerar en "by"-struktur som efter serialisering till JSON innehåller
```json
{
  data: {
    Höger: {
      cBMI: 51,
      mBMI: 25.579591836734693
    },
    Vänster: {
      cBMI: 63,
      mBMI: 24.364406779661017
    },
    Båda: {
      cBMI: 2631,
      mBMI: 21.745096494682947
    }
  },
  success: true,
  message: null,
  code: 0
}

Två nya klustermetoder för vårdenheter finns nu också - “carelevel” och “hospitaltype”, som fungerar på liknande sätt som landstingsindelning (“county”). För de register som grupperat sina vårdenheter efter någon av dessa kan man till exempel anropa

/api/aggregate/rc/testform/total/count/carelevel(klinpri)

som ger tillbaka antal registreringar uppdelat på vårdinvå, det vill säga Slutenvård, Specialiserad öppenvård respektive Primärvård.

Metoden “hospitaltype” ger en uppdelning på sjukhustype, det vill säga Universitets- eller regionssjukhus, Länssjukhus, Länsdelsjukhus respektive Privatsjukhus.

###Fixar

För domänen E-post tilläts konsekutiva punkter felaktigt. Detta är nu spärrat.

Hantering av Alert-sträng för att visa globala och lokala systemmedelanden är omgjort. Det visade sig att den globala Alert-varianten påverkade validering av datum-fält på grund av dess implementering. Nu är det istället så att attributet “Alerter” används i globalt widgetskript och “Alert” används i lokalt dito. På så sätt kan dessa inte påverka något som exekveras på serversidan.

Vi fick ett nytt versionsnummer (2.62) då en fix tillkom för ett av våra register. Detta register har ett huvudformulär som under vissa omständigheter inte skall visas. Problem uppstod eftersom det då det inte fanns några formulär att visa i registreringsapplikationen. Detta är nu åtgärdat och ett meddelande visas i händelsepanelen.

Registercentrum Västra Götaland

v2.60

Information om beräkningsskript finns nu också med i beskrivningen av ett register, tillsammans med valideringsskript och eventuella förklaringar.

Fixar

  • Då registreringar hämtas är dessa nu sorterade fallande efter både händelsedatum (EventDate) och insättningsdatum (InsertedAt). Detta för att det skall bli en förvald ordning även mellan de registreringar som har samma händelsedatum.
  • För variabler med domänen “Email” kunde man tidigare ange för många tecken efter den sista punkten, det vill säga toppdomänen. Detta är nu begränsat till två till fem tecken.
  • Matriser utan kolumnnamn serialiseras nu korrekt efter anrop till R-servern. Dessa gav tidigare ett exception.
  • I förprocessandet av R-skript, efter att det hämtats ut från Subversion, fanns en del buggar i hur kommentarer, tomma rader och semikolon hanterades. Detta är nu justerat. Dock är det svårt att göra helt perfekt. Vi får ta problemen allt eftersom de dyker upp.

Registercentrum Västra Götaland

Stratum 3 - möte 1

ExtJS hela vägen?

Fördelar

  • Ett ramverk som innehåller (i princip) allt vi behöver!
  • Vi kan det rätt väl.

Nackdelar

Alternativ utan ExtJS hela vägen?

  • Keystone JS som CMS. Alternativ till Keystone finns också, Apostrophe (+ för WYSIWYG), Ghost. Dessa två är relativt etablerade. Zero, PencilBlue är mer nyetablerade men ser spännande ut. En fördel med Keystone är att det är många som följer och bidrar. Samtliga ovan är Node.js-baserade. Körs lämpligen under iisnode på befintlig IIS-server. Hur bra fungerar det? Förmodligen bra eftersom Microsoft Azure använder det.
  • Registreringsapplikationen får göras om som “widget”, eller åtminstone bli api-driven till 100%.
  • Ramverk på klientsidan? React skulle nog passa fint men vi får ta reda på framöver vad vi behöver.

Annat värt att notera

  • Direct-api:et försvinner och ersätts med REST! Dock får vi inte ta bort stödet för SFRs applikation.
  • Widgets till GitHub! Strategi? Struktur? Arbetsmetoder?
  • ExtJS för Widgets nödvändigt. Det är trots allt det mest heltäckande ramverket för den typen av grafisk återkoppling. Dessutom vore det väldigt mycket arbete att byta ut.

Strategi

  • Viktigt att avgöra om vi bygger för hela RC eller enbart Stratum?
  • Om vi bygger för RC också är det viktigt att vi intervjuar och kartlägger Charlottas arbetssätt. Vad är det som fungerar dåligt idag? Vad fungerar bra? Vad är superviktigt?
  • Bygg i så fall ny webbplats vid sidan av och presentera när det är någorlunda färdigt. Då blir det väsentligt att CMS-funktionerna erbjuder något nytt. Måste också se ut som RCs nuvarande webbplats.
  • Viktigt att våra användare får en möjlighet att se vad som är på gång när det finns något vettigt att visa.
  • Sencha Touch droppas helt. Eftersom vi bygger en responsiv webbplats skall inte sådan teknik behövas. Detta innebär att en ny registreringsapplikation för PROM, eller rättare sagt en “en-fråga-per-sida”-applikation tas fram som en widget. Gamla “missbenämnda” MetaBrowser görs också om och den funktionaliteten (och mer därtill) läggs upp som en widget.

Att också ersätta den här bloggen med en som finns i Keystone känns lämpligt- :-)

Registercentrum Västra Götaland