bij mva
Maak je in de adapter class dan een object model en een object view aan en
waar roep je de methods van model en view dan aan vanuit de instantianted object?
dus op dit punt roept je alles van de adapter object $obj aan?
Dat hangt ervan af waarvoor je de adapter gebruikt. Strikt genomen doet het adapter design pattern niets anders dan de interfaces van een object aanpassen ("adapteren") aan wat een ander object verwacht.
Bedankt
In een MVA systeem heb je drie aparte klassen die met elkaar, officieel via events, communiceren. Deze weten dus eigenlijk niks van elkaar af. De adapter maakt dus zeker niet de model en view aan.
kun je voorbeeld tonen van een event naar view zoals een click event bij jquery moet ik daar aan denken? bedankt
In dat geval geldt eigenlijk maar één hoofdregel: je moet alles altijd via adapters aansluiten. Bij MVC kan er nog interactie zijn tussen model en view, bij MVA per se niet.
Een event (e) uit een view (V), bijvoorbeeld een klik op een pictogram, wordt lineair verwerkt:
Ve -> A -> M
Bij MVA kan (en mag) je de rol van de adapter hier invullen met dit pattern:
Code (php)
Hiermee kun je vervolgens het model Foo en de view Bar zo aansluiten via een adapter:
Code (php)
Als je bijvoorbeeld componenten van een Ajax-applicatie onderbrengt in aparte applicaties, is zo'n basisopzet eigenlijk vaak al voldoende.
Voor grootschalige webapplicaties (en desktopsoftware) zul je met name de interfaces nog verder moeten uitbreiden. Je hebt dan namelijk honderden of duizenden events, waarvoor het zinvol is zowel models als views te voorzien van listeners. Tegenover de events staan dan listeners die luisteren naar het optreden van bepaalde gebeurtenissen.
Ward van der Put op 19/06/2014 08:23:11:
Ik had inderdaad over de afkorting MVA heen gelezen.
In dat geval geldt eigenlijk maar één hoofdregel: je moet alles altijd via adapters aansluiten. Bij MVC kan er nog interactie zijn tussen model en view, bij MVA per se niet.
Een event (e) uit een view (V), bijvoorbeeld een klik op een pictogram, wordt lineair verwerkt:
Ve -> A -> M
Bij MVA kan (en mag) je de rol van de adapter hier invullen met dit pattern:
Hiermee kun je vervolgens het model Foo en de view Bar zo aansluiten via een adapter:
Als je bijvoorbeeld componenten van een Ajax-applicatie onderbrengt in aparte applicaties, is zo'n basisopzet eigenlijk vaak al voldoende.
Voor grootschalige webapplicaties (en desktopsoftware) zul je met name de interfaces nog verder moeten uitbreiden. Je hebt dan namelijk honderden of duizenden events, waarvoor het zinvol is zowel models als views te voorzien van listeners. Tegenover de events staan dan listeners die luisteren naar het optreden van bepaalde gebeurtenissen.
In dat geval geldt eigenlijk maar één hoofdregel: je moet alles altijd via adapters aansluiten. Bij MVC kan er nog interactie zijn tussen model en view, bij MVA per se niet.
Een event (e) uit een view (V), bijvoorbeeld een klik op een pictogram, wordt lineair verwerkt:
Ve -> A -> M
Bij MVA kan (en mag) je de rol van de adapter hier invullen met dit pattern:
Code (php)
Hiermee kun je vervolgens het model Foo en de view Bar zo aansluiten via een adapter:
Code (php)
Als je bijvoorbeeld componenten van een Ajax-applicatie onderbrengt in aparte applicaties, is zo'n basisopzet eigenlijk vaak al voldoende.
Voor grootschalige webapplicaties (en desktopsoftware) zul je met name de interfaces nog verder moeten uitbreiden. Je hebt dan namelijk honderden of duizenden events, waarvoor het zinvol is zowel models als views te voorzien van listeners. Tegenover de events staan dan listeners die luisteren naar het optreden van bepaalde gebeurtenissen.
Ik heb het inderdaad over de MVA niet de andere.
Ve -> A -> M
Ik ben mij aan het voorbereiden om de MVA te gebruiken te leren eigenlijk.
Heb al wikipedia doorgenomen en rondgekeken en puzzelstukjes komen op zn plaats.
Ward van der Put jij geeft mij een goeie overzicht van wat er te verwachten staat en ik gebruik dit als referentie voor mij verdere speurtocht.
Kan je nog een kleine overzicht geven (koppelend op MVA) wat.
-een interface is
-waarom een abstract class AbstractAdapter?
Kan je misschien ook een 'kale' index.php geven in het geval van een pictrogram klik dat
een record verwijderd of wijzig. Om nog beter gebruik te maken van de voorbeeld aangeboden. Met zeer veel waardering op de komende reactie.
Francoi gckx op 26/06/2014 16:46:53:
Kan je nog een kleine overzicht geven (koppelend op MVA) wat.
-een interface is
-waarom een abstract class AbstractAdapter?
-een interface is
-waarom een abstract class AbstractAdapter?
Een interface schrijft voor welke methoden moeten worden geïmplementeerd, maar vult die niet in. Een abstracte klasse doet hetzelfde, maar vult methoden wel gedeeltelijk concreet in. (Je kunt daarmee stellen dat een interface eigenlijk een 100% abstracte klasse is.)
Aangezien je verschillende dingen op elkaar wilt aansluiten, zullen ze dezelfde aansluitingen moeten hebben. Daarvoor gebruik je de interfaces. Je kunt bij MVA bijvoorbeeld in de ControllerInterface vastleggen dat elke controller een setter-methode voor het accepteren van een event moet hebben.
Omdat je bij MVA op de adapter zowel een model als een view wilt aansluiten, heb ik dat in mijn voorbeeld gedaan met een abstracte klasse AbstractAdapter waarin de constructor public function __construct(ModelInterface $model, ViewInterface $view) het gebruik van de twee interfaces voor models en views verplicht stelt.
Francoi gckx op 26/06/2014 16:46:53:
Kan je misschien ook een 'kale' index.php geven in het geval van een pictrogram klik dat een record verwijderd of wijzig. Om nog beter gebruik te maken van de voorbeeld aangeboden.
Veel PHP-frameworks zijn eigenlijk al meer MVA dan gewoon MVC omdat er nooit direct contact is tussen het model en de view. De controller wordt dan in feite een adapter. Voor voorbeelden kun je bijvoorbeeld in de CodeIgniter User Guide duiken.