Full Javascript Oplossing

[Essie689]

Ik ben de laatste tijd enorm fan geworden van Aurelia in combinatie met een php backend (rest api).
Werkt super, maar ik irriteer me alleen enorm aan het feit dat ik alle validatie dubbel aan het programmeren ben (zowel in javascript als in php).

Ik zou dan ook graag over willen naar een javascript only oplossing, waarbij ik mijn objecten zowel server als clientside kan gebruiken. Helaas heeft Aurelia alleen nog geen backend oplossing. Dus ik vroeg me af of er al goede frameworks zijn waarmee dit dus mogelijk is?

Ik heb er al dagen naar zitten googlen maar ik heb tot nu toe nog eigenlijk niks fatsoenlijks kunnen vinden.

Ik zou dus graag objecten willen creëren, die ik zowel front-end als back-end in kan zetten, zodat ik op beide plekken met dezelfde objecten zit te werken en ik dus niet langer 2 implementaties voor hetzelfde object hoef te maken. Dit kan natuurlijk met plain javascript, maar zou liever een modern framework hiervoor hebben.

[TheNephilim]

Ik snap niet helemaal wat je bedoeld. Aurelia lijkt net zoiets als Vue of React, dus als je die php-backend dan als REST API gaat gebruiken kom je een heel eind. Dan ben je er al!

Je zult overigens wel je modellen moeten blijven defineren in zowel PHP als Javascript. In die laatste waarschijnlijk in een store of iets dergelijks.

De enige manier om volledig met Javascript te kunnen werken is door Nodejs te gaan gebruiken. Dan kun je JS ook server-side renderen.

[Essie689]

Maar ik wil dus graag die PHP backend idd vervangen door NodeJS.

En nu hoopte ik dus eigenlijk dat er goed framework met data validatie was, waarmee ik de data op beide kanten kan controleren.

Dus zowel frontend in Aurelia (of en een ander framework) als backend in een framework op NodeJS. Dan hoef ik de validatie objecten nog maar 1x te schrijven ipv in PHP en in javascript.

En ik ben dus opzoek naar een framework (of een soort van best practice guide) waarin dit dus kan.

[ Voor 19% gewijzigd door Essie689 op 10-07-2017 10:09 ]

[CH4OS]

Je kan het het ook omdraaien; user input nooit vertrouwen, dus waarom de input ook valideren in Javascript, terwijl je weet dat een slimme gebruiker die code kan aanpassen en de code van jouw back-end (die het ook uiteindelijk toch al moet opslaan) ook moet valideren voordat die opslaat?

Dan zou ik het valideren enkel in de back-end opnemen.

[Essie689]

CH40S schreef op maandag 10 juli 2017 @ 10:12:
Je kan het het ook omdraaien; user input nooit vertrouwen, dus waarom de input ook valideren in Javascript, terwijl je weet dat een slimme gebruiker die code kan aanpassen en de code van jouw back-end (die het ook uiteindelijk toch al moet opslaan) ook moet valideren voordat die opslaat?

Dan zou ik het valideren enkel in de back-end opnemen.

Vanuit het oogpunt van gebruikersvriendelijkheid? Niet voor elke stap terug moeten naar de server voor validatie?

Ik vertrouw de user input idd niet (vandaar altijd serverside validatie), ik vind het echter wel veel netter als de client logica de gebruiker ook kan sturen en ik daarvoor niet steeds calls naar de server hoef te maken .

[simon]

Je kan het valideren enkel op de backend doen, op basis van request valideren, foutmelding terug sturen. Vraag is vooral hoe gebruikersvriendelijk dat is, als je het mooi kan verbergen en het niet elke keer lijkt op een 'submit' actie, kun je het al een heel eind brengen. Maarrr, je zal merken dat gebruikers het fijn vinden om op tijd gewaarschuwd te worden. Anders spendeer je een bak tijd met invullen, krijg je daarna de melding, kan je terug naar waar je was. Je kan ze ook iets meer gidsen.

Via NodeJS je JS generen lijkt me een aparte oplossing. Dat lijkt me allemaal rare risico's/complexiteit in je applicatie leggen. Je JS hoeft niet hardcoded de juiste situatie te valideren, je kan ook vanuit je backend validatie bericht die weer terug koppelen aan de JS.

Ik zou dan meer kijken naar hoe je bijv je validatie wel op de server kan laten landen en die dan gebruikersvriendelijk verwerken. Maar je ontkomt er niet aan om in je frontend iets met validatie te doen.

[Hydra]

Je overschat denk ik de overlap. Validatie op de back-end is wat anders dan wat je op de front-end doet. Op de front-end is het doel je gebruiker te helpen. Op de back-end is het vooral om te zorgen dat je data correct blijft.

[CH4OS]

Essie689 schreef op maandag 10 juli 2017 @ 10:14:
[...]

Vanuit het oogpunt van gebruikersvriendelijkheid? Niet voor elke stap terug moeten naar de server voor validatie?

Ik vertrouw de user input idd niet (vandaar altijd serverside validatie), ik vind het echter wel veel netter als de client logica de gebruiker ook kan sturen en ik daarvoor niet steeds calls naar de server hoef te maken .

Tja, elke slimmerik kan de behaviour van Javascript aanpassen en wat is de clientside validatie dan nog waard?

[Hydra]

CH40S schreef op maandag 10 juli 2017 @ 10:22:
Tja, elke slimmerik kan de behaviour van Javascript aanpassen en wat is de clientside validatie dan nog waard?

Dat is ook het doel niet van client-side validatie. De term is ook niet correct; het is gewoon sturen in je user-interface eigenlijk en niet zozeer validatie.

[Essie689]

CH40S schreef op maandag 10 juli 2017 @ 10:22:
[...]
Tja, elke slimmerik kan de behaviour van Javascript aanpassen en wat is de clientside validatie dan nog waard?

Omdat dat niet het doel is. Het doel is dat je tijdens de invoer de gebruiker al kan waarschuwen dat zijn input niet correct is, zonder dat het eerst naar de server gepost wordt.

Hydra schreef op maandag 10 juli 2017 @ 10:22:
Je overschat denk ik de overlap. Validatie op de back-end is wat anders dan wat je op de front-end doet. Op de front-end is het doel je gebruiker te helpen. Op de back-end is het vooral om te zorgen dat je data correct blijft.

Maar ik merk dat ik toch wel steeds meer dingen dubbel aan het uitvoeren ben. Vandaar dat ik dus aan het kijken ben of ik niet geheel naar JS code overkan. Ik ben de laatste tijd ook enorm fan van het gebruik van value objects, waarin je de validatie integreert. Het zou mooi zijn als je client en serverside de objecten zou kunnen hergebruiken.

[ Voor 45% gewijzigd door Essie689 op 10-07-2017 10:29 ]

[Hydra]

Essie689 schreef op maandag 10 juli 2017 @ 10:25:
Maar ik merk dat ik toch wel steeds meer dingen dubbel aan het uitvoeren ben. Vandaar dat ik dus aan het kijken ben of ik niet geheel naar JS code overkan. Ik ben de laatste tijd ook enorm fan van het gebruik van value objects, waarin je de validatie integreert.

Dan heb je value objects niet helemaal begrepen

Je moet het verder zelf weten. Ik vind Node.js ongeveer 't slechtste idee van de laatste 10 jaar. Maar als jij het plezierig vindt werken en je validatie als een soort library in zowel je FE als je BE wil hangen; go your gang. Het is zeker mogelijk; alleen je gaat te tijd die je nu verlies met het omzetten van PHP naar Node.js nooit terugwinnen.

[Essie689]

Hydra schreef op maandag 10 juli 2017 @ 10:33:
[...]


Dan heb je value objects niet helemaal begrepen

Je moet het verder zelf weten. Ik vind Node.js ongeveer 't slechtste idee van de laatste 10 jaar. Maar als jij het plezierig vindt werken en je validatie als een soort library in zowel je FE als je BE wil hangen; go your gang. Het is zeker mogelijk; alleen je gaat te tijd die je nu verlies met het omzetten van PHP naar Node.js nooit terugwinnen.

Ik denk eerder dat ik het misschien verkeerd uitleg .

Anyhow, ik heb helemaal geen ervaring met NodeJS. Ik merk echter gewoon dat ik naar mijn idee momenteel niet optimaal bezig ben en in verhouding echt veel tijd kwijt ben in het schrijven van validatie. Vandaar dat ik naar betere oplossingen aan het zoeken ben. Zeker omdat de validatie regels nog regelmatig aangepast moeten worden en ik dan dus steeds terug moet naar zowel JS als PHP...

[simon]

Je validatieprobleem zou ik in ieder geval niet oplossen voor van PHP naar NodeJS te switchen, maar kijken hoe anderen validatie uitvoeren, en je backend validatie goed opvangen in je frontend, en in je frontend het meer als 'assistance' zien

[Hydra]

Essie689 schreef op maandag 10 juli 2017 @ 10:49:
Ik denk eerder dat ik het misschien verkeerd uitleg .

Value objects horen nul logica te bevatten. Validatie zit over het algemeen gewoon in je view layer.

Anyhow, ik heb helemaal geen ervaring met NodeJS. Ik merk echter gewoon dat ik naar mijn idee momenteel niet optimaal bezig ben en in verhouding echt veel tijd kwijt ben in het schrijven van validatie. Vandaar dat ik naar betere oplossingen aan het zoeken ben. Zeker omdat de validatie regels nog regelmatig aangepast moeten worden en ik dan dus steeds terug moet naar zowel JS als PHP...

Ik denk dat je probleem dan vooral is dat validatie vaak aangepast wordt; want dat is niet erg logisch. Het lijkt er vooral op dat er slecht gedesigned wordt. Je hele zooi omschrijven naar Node is geen oplossing daarvoor.

[Essie689]

Hydra schreef op maandag 10 juli 2017 @ 11:36:
Value objects horen nul logica te bevatten. Validatie zit over het algemeen gewoon in je view layer.

Dat is echt de eerste keer dat ik dat hoor. Zodra je ook maar wat zoekt op value objects, zie je bijna overal dat men in de constructer gewoon valideert of de data aan bepaalde voorwaarde voldoet. Ik zou ook niet weten waarom je dat niet daar zou willen checken? Je wilt juist altijd dat alle data correct is, vanaf het moment dat je het object creërd.

Sterker nog als je die logica daarbuiten plaatst dan moet je dus steeds de data buiten het object om blijven controleren. Zodra je die logica binnen het object plaatst, weet je gewoon dat je altijd een correct object hebt.

[ Voor 25% gewijzigd door Essie689 op 10-07-2017 11:50 ]

[Hydra]

Value objects zijn een DDD term. Ik weet niet waar jij precies ziet dat DDD oplegt dat je validatie in zo'n value object zelf doet? Het is gangbaar om waar je objecten binnenkrijg deze te valideren; dus bijvoorbeeld in een controller. Een value object is dom; die kan door een controller gemaakt worden maar ook bijvoorbeeld een repository of een service. Waarom zou 'ie in zo'n known state weer diezelfde validatie doen? Validatie doe je normaal op de boundaries van je context.

[hellfighter87]

Het is vrij normaal om zowel op de backend als frontend je validatie voor een deel te hebben. echter doe je dit op de backend veel uitgebreider dan op de frontend.
Voorbeeld:

Stel je hebt een contact formulier: email adres en een tekst

Backend:
- controleer of het email adres valide is, bijv staat er een @ (hier bestaad een filter voor in php)
- controleer of het email adres al niet 85 vragen in het afgelopen uur gemailed heeft
- controleer of de vraag aan je verwachtingen voldoet (niet te lang bijv)
etc.

Frontend:
- controleer of het email veld en het text veld niet leeg zijn, stuur daarop.


Bovenstaande is maar een voorbeeld maar om te voorkomen zou ik minimale validatie doen op je frontend en uitgebreide validatie doen op je backend.

Als je het echt op 1 plek wil kan je ook ajax calls doen voor elk veld zodra het blur event afgevuurd wordt.
Ik zou het in ieder geval nooit op de frontend doen omdat je het uit kan zetten. je wil dat jij daar controle over hebt niet de gebruiker

[Verwijderd]

Wellicht is Meteor wat je bedoelt?
https://www.meteor.com/

[diabolofan]

Ik herken het probleem maar al te goed. Wij hebben er ook nog een native Android/iOS app bij, waardoor het helemaal irritant wordt omdat je op 3 plaatsen wilt valideren.

Wij hebben inderdaad besloten om echt alleen backend validatie te doen. Dit kan in onze use cases vaak zonder problemen, maar is inderdaad niet erg gebruikersvriendelijk. Zelfs een verplicht veld weet je pas nadat je gesubmit hebt. Als je dit niet wilt dan moet je dus inderdaad als bijvoorbeeld een verplicht veld opeens een niet-verplicht veld wordt, dit op (in mijn geval) 3 plaatsen (backend, frontend, app) gaan aanpassen om het weer sluitend te krijgen.

Een betere/handigere oplossing weet ik momenteel ook nog niet en is in ieder geval niet zo voor handen.

[Essie689]

Hydra schreef op maandag 10 juli 2017 @ 15:05:
Value objects zijn een DDD term. Ik weet niet waar jij precies ziet dat DDD oplegt dat je validatie in zo'n value object zelf doet? Het is gangbaar om waar je objecten binnenkrijg deze te valideren; dus bijvoorbeeld in een controller. Een value object is dom; die kan door een controller gemaakt worden maar ook bijvoorbeeld een repository of een service. Waarom zou 'ie in zo'n known state weer diezelfde validatie doen? Validatie doe je normaal op de boundaries van je context.

Ik denk dat dit wel het meeste gebruiker voorbeeld is:

code:

class EmailAddress  
{
    private $address;

    public function __construct($address)
    {
        if (!filter_var($address, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException(sprintf('"%s" is not a valid email', $address));
        }

        $this->address = $address;
    }

    public function __toString()
    {
        return $this->address;
    }
}

Dit betekend dat zodra je een object van het type EmailAddress dat je zeker weet dat deze geldig is.
En dit principe voer ik zo'n beetje op al mijn value objects door. Ik vind dat persoonlijk echt enorm prettig werken.

hellfighter87 schreef op maandag 10 juli 2017 @ 15:21:
Als je het echt op 1 plek wil kan je ook ajax calls doen voor elk veld zodra het blur event afgevuurd wordt.
Ik zou het in ieder geval nooit op de frontend doen omdat je het uit kan zetten. je wil dat jij daar controle over hebt niet de gebruiker

Ik wil het niet op 1 plek uitvoeren. Ik wil het op 2 plekken uitvoeren, ik wil echter de logica maar 1x implementeren.

Verwijderd schreef op maandag 10 juli 2017 @ 15:39:
Wellicht is Meteor wat je bedoelt?
https://www.meteor.com/

Die had ik idd gezien, maar ik kon helaas nog niet echt vinden dat hun deden wat ik zocht.

diabolofan schreef op maandag 10 juli 2017 @ 15:41:
Wij hebben inderdaad besloten om echt alleen backend validatie te doen. Dit kan in onze use cases vaak zonder problemen, maar is inderdaad niet erg gebruikersvriendelijk. Zelfs een verplicht veld weet je pas nadat je gesubmit hebt. Als je dit niet wilt dan moet je dus inderdaad als bijvoorbeeld een verplicht veld opeens een niet-verplicht veld wordt, dit op (in mijn geval) 3 plaatsen (backend, frontend, app) gaan aanpassen om het weer sluitend te krijgen.

Dat is dus idd ook mijn gehele issue. En momenteel ook ons gehele discussie punt, want dat betekend dus dat je gebruikersvriendelijkheid in gaat leveren om makkelijker te kunnen programmeren.. Vertel dat maar is aan de UI expert .

[hellfighter87]

Essie689 schreef op maandag 10 juli 2017 @ 15:49:
Dat is dus idd ook mijn gehele issue. En momenteel ook ons gehele discussie punt, want dat betekend dus dat je gebruikersvriendelijkheid in gaat leveren om makkelijker te kunnen programmeren.. Vertel dat maar is aan de UI expert .

misschien een rare vraag maar hoe lever je dan in?
Je kan toch voor elke change (blur event) een ajax call doen en daaruit concluderen of iets wel of niet valid is.
Hoef je de validatie alleen op de backend te doen en zo intensief is het valideren van data nou ook weer niet.
Dan zou je hetzelfde moeten kunnen als dat je validatie op 2 plekken doet.

[ Voor 5% gewijzigd door hellfighter87 op 10-07-2017 16:09 ]

[Essie689]

hellfighter87 schreef op maandag 10 juli 2017 @ 16:08:
[...]
misschien een rare vraag maar hoe lever je dan in?
Je kan toch voor elke change (blur event) een ajax call doen en daaruit concluderen of iets wel of niet valid is.
Hoef je de validatie alleen op de backend te doen en zo intensief is het valideren van data nou ook weer niet.
Dan zou je hetzelfde moeten kunnen als dat je validatie op 2 plekken doet.

Dat was als reactie op het voorbeeld dat men geen validatie clientside uitvoerde (of zeer beperkt) en men voornamelijk alles pas tijdens de submit controleerde.

Jou voorbeeld is idd hoe wij het vroeger ook uitvoerde.. Maar bij een paar duizend input velden en tig gelijktijdige gebruikers gaat dat toch echt wel problemen veroorzaken.

Misschien is het er wel gewoon niet wat ik zoek.. En misschien is er wel een goede reden voor.. Ik ben hem alleen nog niet tegen gekomen .

[ Voor 3% gewijzigd door Essie689 op 10-07-2017 16:21 ]

[Hydra]

Essie689 schreef op maandag 10 juli 2017 @ 15:49:
Ik denk dat dit wel het meeste gebruiker voorbeeld is:

Ik snap prima wat je bedoelt maar het is een beetje een ouderwetse aanpak van OO programmeren. Tegenwoordig is het gangbaarder om op context boundaries te checken.

[Oxidda]

Hydra schreef op maandag 10 juli 2017 @ 16:27:
[...]


Ik snap prima wat je bedoelt maar het is een beetje een ouderwetse aanpak van OO programmeren. Tegenwoordig is het gangbaarder om op context boundaries te checken.

Ik snap niet waarom een ouderwetse aanpak word afgeschoten? Lijkt me ook niet goede doel van de discussie.

Over delen van validatie aan de voor en achterkant:

Aurelia zelf heeft hier wat over geschreven: http://aurelia.io/hub.htm...atest/securing-your-app/1

En dat is precies wat hier eerder al word verteld. Front-end validatie is voor user experience. Je kan wel je checks aan beide kanten willen delen, maar dan worden je server side checks gewoon veels te licht. Wat er voor zorgt dat je applicatie onveilig word. Natuurlijk word er dan weer een uitbreiding gedaan op de bestaande checks, maar dan nog spring je in hoepels en ga je wellicht een route in die alles alleen maar nog onoverzichtelijker en onduidelijker maakt. En dit geeft het een potentiele hacker inzicht in hoe jij validaties doet en kan mogelijke zwakheden vinden.

Maar vergeet niet dat je , naast die saaie validatie checks op data ook nog de OWASP top 10 moet meenemen. Wat in mijn inziens het alleen maar belangrijker maakt dat je backend op orde is ofwel : een backend die maling neemt aan de voorkant en zijn eigen veel strengere weg in slaat.

Begrijp me goed, lui zijn is op zich goed (DRY; Don't repeat yourself) maar daar kan je ook in doorslaan of het erg overtrekken, met negatieve gevolgen van dien.

[Gomez12]

Essie689 schreef op maandag 10 juli 2017 @ 15:49:
[...]

Ik denk dat dit wel het meeste gebruiker voorbeeld is:

code:

class EmailAddress  
{
    private $address;

    public function __construct($address)
    {
        if (!filter_var($address, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException(sprintf('"%s" is not a valid email', $address));
        }

        $this->address = $address;
    }

    public function __toString()
    {
        return $this->address;
    }
}

Dit betekend dat zodra je een object van het type EmailAddress dat je zeker weet dat deze geldig is.
En dit principe voer ik zo'n beetje op al mijn value objects door. Ik vind dat persoonlijk echt enorm prettig werken.

Leuke aanpak als je FILTER_VALIDATE_EMAIL 10 msec duurt. Dan moet je ergens een lijst produceren met 50 namen en emailadressen uit je dbase en dan ben je al een halve seconde kwijt qua wachttijd.

Dit soort acties is redelijk killing voor je performance.

[Beyond]

Tegenwoordig zie je vaak dat de frontend en de backend worden gescheiden. Je zou dus meerdere frontends kunnen hebben op 1 backend. Misschien dat je in de toekomst zelfs de API beschikbaar wilt stellen voor derden. Daarom moet je validatie ook altijd aan de backend kant doen.

[Oxidda]

Gomez12 schreef op dinsdag 11 juli 2017 @ 13:32:
[...]

Leuke aanpak als je FILTER_VALIDATE_EMAIL 10 msec duurt. Dan moet je ergens een lijst produceren met 50 namen en emailadressen uit je dbase en dan ben je al een halve seconde kwijt qua wachttijd.

Dit soort acties is redelijk killing voor je performance.

Ja vrij killing als je dit in grote een collection gebruikt, anders niet, ligt dus aan hoe je dit object gebruikt natuurlijk.

Het ligt dus meer aan waar het voor bedoeld is en hoe het gebruikt gaat worden ipv dat het bij default een performance probleem oplevert.

Neemt niet weg dat ik deze route ook niet zou inslaan, maar hier een apart stukje validatie voor zou gebruiken ipv het afhankelijk te maken aan me obj, die heb ik het liefst zo simpel mogelijk.

[Hydra]

Oxidda schreef op dinsdag 11 juli 2017 @ 14:51:
Neemt niet weg dat ik deze route ook niet zou inslaan, maar hier een apart stukje validatie voor zou gebruiken ipv het afhankelijk te maken aan me obj, die heb ik het liefst zo simpel mogelijk.

Wat dus precies de reden is dat je dit aan je boundaries doet. Het heeft normaliter weinig zin om e-mail adressen uit je DB te gaan valideren; dat zou je moeten hebben gedaan bij invoer. Voorbeeldje uit een rest controller die ik vandaag gemaakt heb:

Java:

fooBarService.getFooBar(
                            validCountryCode(countryFrom),
                            validCurrencyCode(currencyFrom),
                            validCountryCode(countryTo),
                            validCurrencyCode(currencyTo),
                            validAmount(paymentAmount),
                            validAmount(receptionAmount))

[ Voor 31% gewijzigd door Hydra op 11-07-2017 15:53 ]

[Oxidda]

Hydra schreef op dinsdag 11 juli 2017 @ 15:52:
[...]


Wat dus precies de reden is dat je dit aan je boundaries doet. Het heeft normaliter weinig zin om e-mail adressen uit je DB te gaan valideren; dat zou je moeten hebben gedaan bij invoer. Voorbeeldje uit een rest controller die ik vandaag gemaakt heb:

Java:

fooBarService.getFooBar(
                            validCountryCode(countryFrom),
                            validCurrencyCode(currencyFrom),
                            validCountryCode(countryTo),
                            validCurrencyCode(currencyTo),
                            validAmount(paymentAmount),
                            validAmount(receptionAmount))

En toch zijn er nog wel use cases te vinden waarin dat wel wenselijk is, zeker als je gaat integreren met legacy applications die niet met de nieuwe software kunnen praten. Het een sluit het andere niet uit, er word hier veel met aannames gereageerd of hoe men zelf vind "dat het zou moeten zijn".

Er zijn erg veel use cases te verzinnen voor verschillende scenarios, dat deze nu toevallig naadloos aansluiten bij eigen gedachtes om een punt te maken .

Een andere gedachte kan ook zijn, je database is ook een boundary , het ligt er maar net aan hoe je deze specificeert en ook dat ligt weer aan de eisen van het systeem.

Maar ik denk dat mijn punt, als de jouwe wel duidelijk is. Ik moet ophouden met het topic te ver te laten ontsporen .

[Zundrium]

Als ik het goed begrijp, is het hoofdprobleem het twee maal definiëren van je objecten met attributes in de front-end en back-end. Ik kan over Aurelia weinig zeggen omdat ik daar niet mee heb gewerkt. Maar ik kan wel zeggen hoe ik dit probleem tackle met Angular 2.

Wat ik hiervoor gebruik is Restangular. (https://github.com/2muchcoffeecom/ng2-restangular) Je kan dan eenvoudig met wat instellingen een service opzetten die genoeg heeft aan `let account = Restangular.one('accounts', 1234)`, dan heb je het model met waardes voor je neus en kan je wijzigen wat je wilt alsof het een dict is, vervolgens kan je het opslaan met `account.save()`. Je kan de validatie dynamisch oppakken aangezien er ook datatypes van de velden meegegeven worden. Deze informatie krijgt hij via de OPTIONS request naar je REST API.

Je kan het nog meer automatiseren door te werken met angular-schema-form (https://github.com/json-schema-form/angular-schema-form). Dan kan je op basis van je model met Restangular een JSON object maken waarmee weer een compleet formulier met validatie wordt uitgepoept.

Aangezien Aurelia ook volwassen is verwacht ik ook een mooie wrapper voor REST API services. Als je dat hebt word het maken van een formulier op basis van een scriptje vrij eenvoudig. Als je de velden veranderd naar inputvelden en op basis van datatype daar een validatie aanhangt ben je er lijkt me.

[Essie689]

Zundrium schreef op dinsdag 11 juli 2017 @ 16:02:
Als ik het goed begrijp, is het hoofdprobleem het twee maal definiëren van je objecten met attributes in de front-end en back-end. Ik kan over Aurelia weinig zeggen omdat ik daar niet mee heb gewerkt. Maar ik kan wel zeggen hoe ik dit probleem tackle met Angular 2.

Wat ik hiervoor gebruik is Restangular. (https://github.com/2muchcoffeecom/ng2-restangular) Je kan dan eenvoudig met wat instellingen een service opzetten die genoeg heeft aan `let account = Restangular.one('accounts', 1234)`, dan heb je het model met waardes voor je neus en kan je wijzigen wat je wilt alsof het een dict is, vervolgens kan je het opslaan met `account.save()`. Je kan de validatie dynamisch oppakken aangezien er ook datatypes van de velden meegegeven worden. Deze informatie krijgt hij via de OPTIONS request naar je REST API.

Je kan het nog meer automatiseren door te werken met angular-schema-form (https://github.com/json-schema-form/angular-schema-form). Dan kan je op basis van je model met Restangular een JSON object maken waarmee weer een compleet formulier met validatie wordt uitgepoept.

Aangezien Aurelia ook volwassen is verwacht ik ook een mooie wrapper voor REST API services. Als je dat hebt word het maken van een formulier op basis van een scriptje vrij eenvoudig. Als je de velden veranderd naar inputvelden en op basis van datatype daar een validatie aanhangt ben je er lijkt me.

Dat is idd ook wel misschien een goed oplossing! Bedankt voor de tip.

Oxidda schreef op dinsdag 11 juli 2017 @ 16:00:
[...]


En toch zijn er nog wel use cases te vinden waarin dat wel wenselijk is, zeker als je gaat integreren met legacy applications die niet met de nieuwe software kunnen praten. Het een sluit het andere niet uit, er word hier veel met aannames gereageerd of hoe men zelf vind "dat het zou moeten zijn".

Er zijn erg veel use cases te verzinnen voor verschillende scenarios, dat deze nu toevallig naadloos aansluiten bij eigen gedachtes om een punt te maken .

Een andere gedachte kan ook zijn, je database is ook een boundary , het ligt er maar net aan hoe je deze specificeert en ook dat ligt weer aan de eisen van het systeem.

Maar ik denk dat mijn punt, als de jouwe wel duidelijk is. Ik moet ophouden met het topic te ver te laten ontsporen .

De data in de database wordt inderdaad niet alleen door het nieuw te ontwikkelen stuk software gevuld, maar is al reeds en blijft ook gevuld worden (in de komende jaren) door de legacy software. Dus vandaar dat we de data uit de database ook niet direct vertrouwen.

[ Voor 26% gewijzigd door Essie689 op 13-07-2017 12:13 ]