"One day, someone showed me a glass of water that was half full. And he said: 'Is it half full or half empty?' So I drank the water. No more problem." - Alexander Jodorowsky
Vraag
Beste antwoord (via Ossebol op 05-12-2016 17:02)
Alle reacties
Doorgaans zal een microservice een (REST) api exposen om zaken mee af te hangen. De applicatie zal die applicatie dan benaderen via een HTTP request en daar dingen mee doen, om vervolgens in de view (angular) te renderen.
Om een lang verhaal kort te houden, moet je, je view geen model/control logic laten uitvoeren. Data verwerken wil je in een dedicated "data store" afhandelen en mits een (angular) controller door laten vloeien naar je view.
Persoonlijk heb ik een bias van hier tot gunter omdat ik zelf een library hiervoor beheer (consumerjs) maar er zijn verschillende oplossingen mogelijk. Een tip die ik je wil meegeven is om altijd MVC te benaderen en nooit alles te willen oplossen in 1 library. Genoeg applicaties die deze fout hebben gemaakt en nu 100% afhankelijk zijn van jQuery.
Dus kies een library voor je datamodel (iets dat REST api's "consumed"), en voor je controller (iets dat model X aan view en Y koppelt) en voor je view (iets dat X in Y toont zoals Angular).
Vaak zijn je controller en je view dezelfde library (zoal in Angular) maar meestal heb je iets dedicated voor data stores.
[ Voor 13% gewijzigd door Ed Vertijsment op 06-11-2016 02:36 . Reden: Meer detail. ]
Het is ongetwijfeld wel mogelijk om, door heel veel beveiliging te omzeilen, een externe HTML-pagina in je eigen DOM te krijgen, maar het ontgaat me even wat je daar dan precies mee wil doen.
Angular is zeker niet alleen een templating library, het lijkt meer op Aurelia. Of eigenlijk lijkt Aurelia op Angular, aangezien het gebouwd is door een ex-lid van het Angular 2 team dat ontevreden was over de kant die het project op gingEd Vertijsment schreef op zondag 06 november 2016 @ 02:33:
AFAIK is angular een templating library (ik heb zelf meer ervaring met andere libraries zoals react en aurelia). Niet perse bedoeld om externe (micro) services te benaderen.
[ Voor 34% gewijzigd door NNF op 06-11-2016 11:17 ]
Misschien snap jij mijn use case niet en ik de jouwe niet
Persoonlijk lijkt het mij geen goed idee om een html input in te laden middels een (Angular) http client en dat te gebruiken in je applicatie. Beter lijkt mij om de microservice een API te laten exposen en die aan te roepen d.m.v. bijvoorkeur een data store ("vanilla" http werkt ook maar vind ik vergelijkbaar met rouwe sql zonder orm).
Ik zou gewoon een component maken die async data van een microservice ophaalt d.m.v. een REST api. Waarom wil je per se een include doen?
In principe wil ik de letterlijke site (nouja, een microservice ervan) includen in een Angular-template via ssi, maar ik begrijp dus dat Angular ook een alternatief voor ssi aanbiedt, tenzij ik het verkeerd begrijp.
We gebruiken REST, maar die gebruiken de microservices weer om data te verkrijgen. Je moet het zo zien: we hebben een service voor menu en header en een andere service voor de daadwerkelijke content. Die service wordt geïncluded en haalt zijn data dmv OData uit een andere service.
Hopelijk ben ik een beetje duidelijk, zeg het anders vooral! Dank voor de inhoudelijke antwoorden tot zover! Altijd goed om alternatieven te horen
[ Voor 8% gewijzigd door Ossebol op 06-11-2016 21:14 ]
"One day, someone showed me a glass of water that was half full. And he said: 'Is it half full or half empty?' So I drank the water. No more problem." - Alexander Jodorowsky
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| import { Component } from '@angular/core'; import { DomSanitizer } from '@angular/platform-browser'; @Component({ selector: 'app-x', template: ` <iframe [src]="newFrame"></iframe> `, }) export class NewComponent { newFrame: any; constructor(private sanitizer: DomSanitizer) { this.newFrame = sanitizer.bypassSecurityTrustResourceUrl('<external source here>'); } } |
"One day, someone showed me a glass of water that was half full. And he said: 'Is it half full or half empty?' So I drank the water. No more problem." - Alexander Jodorowsky