Over logica en presentatie

[.oisyn]

Dit topic is afgesplitst van [alg] Slechtste programmeervoorbeelden deel 4

Hacku schreef op zondag 12 juli 2009 @ 21:54:

ik hou m'n html gescheiden van php code.

Ah, jij output alleen maar statische HTML?

Dat argument hoor ik wel vaker hier op GoT. In de meeste gevallen blijkt het een verkeerde interpretatie van de richtlijn om domein en presentatie te scheiden. Door de presentatie in een andere taal te doen (met een DSL als Smarty oid) is die scheiding natuurlijk evident, maar een dergelijke scheiding kan net zo goed terwijl je je presentatie gewoon door PHP laat verzorgen.

Dus, heb je daar onderbouwing bij? Waarom wil je geen PHP code in je templates?

[ Voor 66% gewijzigd door Janoz op 15-07-2009 15:06 ]

[XWB]

.oisyn schreef op zondag 12 juli 2009 @ 22:05:
[...]

Tja, als jij altijd statische HTML output is dat idd een mogelijke keuze. Bij variabele content, wat in 99.9999% van de webapps het geval is is het natuurlijk een no-go. Tenzij je argument strict gaat om "PHP code" - je wilt geen PHP code in je templates, maar wel Smarty code oid? Beetje suf imho. Heb je daar onderbouwing bij? Want het lijkt een beetje op het standaard pattern waarin je model scheid van presentatie, maar feitelijk is het dat niet - presentatie kan net zo goed, gescheiden van het model, door een PHP script verzorgd worden.

Ja, ik weet dat alles suf en kut en ruk is en jij de über coder bent. Een beetje minder aanvallend mag ook wel, dan wil ik misschien nog eens zinnig antwoorden.

[.oisyn]

f5 'ns, ik had m'n reactie al lang en breed aangepast. En waarom mag ik niet iets suf vinden? Als je je daardoor al aangevallen voelt ligt het probleem toch echt bij jezelf denk ik . En ben jij nu niet een beetje op de man aan het spelen door te zeggen dat ik mezelf de übercoder vind?

Anyway, ik ben nog altijd oprecht benieuwd naar je gedachtengang erachter. Wellicht kun je me overtuigen.

[ Voor 69% gewijzigd door .oisyn op 12-07-2009 22:24 ]

[XWB]

.oisyn schreef op zondag 12 juli 2009 @ 22:05:
[...]

Ah, jij output alleen maar statische HTML?

Dat argument hoor ik wel vaker hier op GoT. In de meeste gevallen blijkt het een verkeerde interpretatie van de richtlijn om domein en presentatie te scheiden. Door de presentatie in een andere taal te doen (met een DSL als Smarty oid) is die scheiding natuurlijk evident, maar een dergelijke scheiding kan net zo goed terwijl je je presentatie gewoon door PHP laat verzorgen.

Dus, heb je daar onderbouwing bij? Waarom wil je geen PHP code in je templates?

Scheiden van php en html code is niet de juiste benaming, ik zeg het vaak zo uit gemak. Uiteraard heb je Smarty code in je templates bij dynamiche applicaties (daar kom je niet aan onderuit), maar dat is een minimum en nog steeds leesbaar. Ik vind het fijner werken om eerst alle php code te kunnen schrijven zonder steeds <?php te moeten openen en sluiten. Los daarvan heeft een Smarty veel handige functies zoals caching en nog veel andere zaken. Uiteraard wordt alles vertaald naar php code, php is immers een template engine. Misschien dat een voorbeeld nog wat duidelijker is:

Dit:

PHP:

$data = array ();
$data[4] = 'Test 1';
$data[8] = 'Test 2';
$data[16] = 'Test 3';

// en nog 1000 andere handelingen

$smarty->assign ( 'data', $data );
$smarty->assign ( 'selectedTest', 4 );

HTML:

<select name="test">{html_options options=$data selected=$selectedTest}</select>

Is voor mij prettiger en overzichtelijker werken dan dit:

PHP:

<?php
$data = array ();
$data[4] = 'Test 1';
$data[8] = 'Test 2';
$data[16] = 'Test 3';

?>
<select name="test">
<?php
foreach ( $data as $value => $text ) {
?> 
<option value="<?php echo $value; ?>"><?php echo $text; ?></option>
<?php
}
?>
</select>
<?php
// en nog 1000 keer de php tag openen en sluiten
?>

En andere vinden het weer ruk.

En waarom mag ik niet iets suf vinden? Als je je daardoor al aangevallen voelt ligt het probleem toch echt bij jezelf denk ik .

Dat mag je, maar ik heb vaak de indruk dat je alles suf vind. Maar het kan idd aan mij liggen.

En ben jij nu niet een beetje op de man aan het spelen door te zeggen dat ik mezelf de übercoder vind?

Je posts komen (bij mij toch) vaak zo over, daarom edit je ze ook vaak?

[ Voor 9% gewijzigd door XWB op 12-07-2009 22:40 ]

[.oisyn]

Hacku schreef op zondag 12 juli 2009 @ 22:38:

Scheiden van php en html code is niet de juiste benaming, ik zeg het vaak zo uit gemak.

Ah, dat haalt een beetje de hele discussie onderuit . Ik ben zeker niet tegen Smarty. Maar ik kijk altijd maar raar op als mensen PHP code in HTML "fout" vinden, met als argument dat je dat moet scheiden. Dat klinkt vaak een beetje als klok en klepel.

Is voor mij prettiger en overzichtelijker werken dan dit:

Mee eens, maar je code is nogal langer dan nodig geschreven en daarnaast kun je daar natuurlijk ook functies voor maken, net zoals Smarty die heeft. En dan wordt het (bijv)

PHP:

<select name="test"><?=html_options($data, $selectedTest)?></select>

Dat mag je, maar ik heb vaak de indruk dat je alles suf vind. Maar het kan idd aan mij liggen.

Ik heb idd vaak een uitgesproken mening

Je posts komen (bij mij toch) vaak zo over, daarom edit je ze ook vaak?

Ik edit vaak omdat ik na het submitten aan nog iets denk om te zeggen, wat uiteindelijk dan niet meer in de opbouw van m'n post past, en dus moet er veel geedit worden. Idd niet erg handig als er meteen op gereageerd wordt, misschien moet ik iets langer wachten voordat ik op submit druk. Desalniettemin vond ik mijn post nog altijd niet aanvallend

[ Voor 13% gewijzigd door .oisyn op 12-07-2009 23:16 ]

[Janoz]

Hacku schreef op zondag 12 juli 2009 @ 22:38:


Dit:

PHP:

$data = array ();
$data[4] = 'Test 1';
$data[8] = 'Test 2';
$data[16] = 'Test 3';

// en nog 1000 andere handelingen

$smarty->assign ( 'data', $data );
$smarty->assign ( 'selectedTest', 4 );

HTML:

<select name="test">{html_options options=$data selected=$selectedTest}</select>

Is voor mij prettiger en overzichtelijker werken dan dit:

PHP:

<?php
$data = array ();
$data[4] = 'Test 1';
$data[8] = 'Test 2';
$data[16] = 'Test 3';

?>
<select name="test">
<?php
foreach ( $data as $value => $text ) {
?> 
<option value="<?php echo $value; ?>"><?php echo $text; ?></option>
<?php
}
?>
</select>
<?php
// en nog 1000 keer de php tag openen en sluiten
?>

Beetje een zwart wit voorbeeld. Neem bijvoorbeeld je tweede stukje. ZOu je data een iets duidelijkere naam geven (ja, ik weet dat het nu even voor het voorbeeld is) en hetgeen je in de eerste 6 regels in een appart bestand zet (samen met die 1000 andere dingen), lijkt dit bestand dan niet verdomde veel op je bestand uit voorbeeld 1? En komt de rest van het bestand dan niet enorm overeen met het smarty template?

[ Voor 3% gewijzigd door Janoz op 12-07-2009 22:57 ]

[fleppuhstein]

Hacku schreef op zondag 12 juli 2009 @ 22:38:
[...]

PHP:

<?php
$data = array ();
$data[4] = 'Test 1';
$data[8] = 'Test 2';
$data[16] = 'Test 3';

?>
<select name="test">
<?php
foreach ( $data as $value => $text ) {
?> 
<option value="<?php echo $value; ?>"><?php echo $text; ?></option>
<?php
}
?>
</select>
<?php
// en nog 1000 keer de php tag openen en sluiten
?>

Is wel een slordige manier van php gebruiken, terwijl hetzelfde ook over zichtelijk kan:

PHP:

<?php
// Deze toewijzingen horen eigenlijk al niet in je template te zitten.
$data = array ();
$data[4] = 'Test 1';
$data[8] = 'Test 2';
$data[16] = 'Test 3';
?>

<select name="test">
  <?php foreach ( $data as $value => $text ): ?> 
    <option value="<?php echo $value; ?>" ><?php echo $text; ?></option>
  <?php endforeach; ?>
</select>

Waarbij duidelijk is dat correcte indentation de leesbaarheid altijd ten goede komt. En geen onnodige regels gebruiken, maar dan komen we weer in de gevoelige discussie van een eige manier van code schrijven volgens je eigen code regels. Daar wil ik mij niet aan branden.

Maar gegeven feit is dat iedereen met php kennis weet wat hier gebeurd, terwijl met je Smarty voorbeeld, moet je ook op de hoogte van smarty zijn.

[.oisyn]

Je kunt je <php echo ...; ?>'s nog verkorten tot <?=...?> of <?php=...?>

[prototype]

Uit pure nieuwschierigheid Hacku, hoe geloof jij dat MVC doorgevoerd dient te worden in een webapplicatie? Ik denk dat als dit eenmaal duidelijk is er het e.e.a. zinvol besproken kan worden.

[fleppuhstein]

.oisyn schreef op zondag 12 juli 2009 @ 23:15:
Je kunt je <php echo ...; ?>'s nog verkorten tot <?=...?> of <?php=...?>

Ja, alleen dit zijn toch wel de fouten die door de PHP internal crew worden gemaakt. Dit zijn de zogenaamde shorttags, met andere woorden, een smerige shortcut. Omdat ze het maar niet eens konden worden.

Gevaar is dus bij dit gebruik dat je het script/applicatie ooit eens wilt draaien waar de config mischien de shorttags disabled heeft staan, en dan doettie het niet.

En daarbij dacht ik dat ze in PHP 6 er eindelijk uit gaan. Hopelijk wordt versie 6 veel rommer uit eerdere versies weg gehaald, net als de error supression waar vandaag eerder over is gesproken.

[.oisyn]

fleppuhstein schreef op zondag 12 juli 2009 @ 23:23:
[...]


Ja, alleen dit zijn toch wel de fouten die door de PHP internal crew worden gemaakt. Dit zijn de zogenaamde shorttags, met andere woorden, een smerige shortcut. Omdat ze het maar niet eens konden worden.

De <? is de shorttag voor <?php, maar <?php= is geen shorttag. En die verdwijnt dact ik ook niet. De kern van m'n post was natuurlijk het weghalen van de echo en de trailing ;, niet het omzeilen van de 'php' in de tag
Woeps, <?php= wordt (nog) niet ondersteund. Ok, I stand corrected.

net als de error supression waar vandaag eerder over is gesproken

Alsjeblieft niet. Ik bespaar m'n gebruikers liever de lelijke PHP error meldingen.

[ Voor 21% gewijzigd door .oisyn op 12-07-2009 23:41 ]

[Cartman!]

prototype schreef op zondag 12 juli 2009 @ 23:19:
Uit pure nieuwschierigheid Hacku, hoe geloof jij dat MVC doorgevoerd dient te worden in een webapplicatie? Ik denk dat als dit eenmaal duidelijk is er het e.e.a. zinvol besproken kan worden.

Ik ben wel benieuwd hoe Hacku dit dan ziet... ik was namelijk altijd fel tegen op het gebruiken van logica in je views maar sinds we over zijn op Zend Framework (MVC) is dat over. Het is fantastisch en tevens erg logisch imo. Waarom zou je in de controller al wat met je data gaan doen en de formatting bepalen?

[Erkens]

.oisyn schreef op maandag 13 juli 2009 @ 03:58:
Zoals ik al zei, dat is niet context-gevoelig. Error handlers in PHP werken nogal ruk imho. Als ik een file wil openen met fopen(), en die file mag best nog niet bestaan, dan ben ik helemaal niet geïnteresseerd in een error handler. fopen() die gewoon false retourneert is prima. De @ is dan noodzakelijk (of je moet moeilijk gaan doen door tijdelijk een nieuwe dummy handler in te stellen die niets doet (waarbij je mogelijk ook nog eens hele andere errors negeert), of tijdelijk de E_WARNING uit de error reporting gooien)

Zelf gebruik ik tegenwoordig steeds vaker de Exceptions van PHP met hulp van de ErrorException-class (waarbij je helaas nog wel een error_handler moet gebruiken, maar dat is meer een tussenstap omdat PHP op dat gebied idd wat vaag/complex/irritant/ruk is).
Hiermee kan je dus gewoon try/catch blokken om je mysql_connect of fopen gebruiken. (overigens is het mij altijd wel een raadsel geweest waarom ze altijd een E_WARNING gooien bij een file die niet bestaat, ook al handel je het zelf af...) Erg handig dus

Cartman! schreef op maandag 13 juli 2009 @ 10:21:
[...]

Ik ben wel benieuwd hoe Hacku dit dan ziet... ik was namelijk altijd fel tegen op het gebruiken van logica in je views maar sinds we over zijn op Zend Framework (MVC) is dat over. Het is fantastisch en tevens erg logisch imo. Waarom zou je in de controller al wat met je data gaan doen en de formatting bepalen?

Ehm, formatting doe je toch altijd al in de view? Daar heeft de controller niks mee van doen. Het is inderdaad logischer

[.oisyn]

Erkens schreef op maandag 13 juli 2009 @ 11:43:
[...]

Zelf gebruik ik tegenwoordig steeds vaker de Exceptions van PHP met hulp van de ErrorException-class

Hey da's ook wel een aardige oplossing idd

[prototype]

Cartman! schreef op maandag 13 juli 2009 @ 10:21:
[...]

Ik ben wel benieuwd hoe Hacku dit dan ziet... ik was namelijk altijd fel tegen op het gebruiken van logica in je views maar sinds we over zijn op Zend Framework (MVC) is dat over. Het is fantastisch en tevens erg logisch imo. Waarom zou je in de controller al wat met je data gaan doen en de formatting bepalen?

Heb niet echt veel gewerkt met Zend Framework maar ik vind het nogal raar dat mensen een heel template mechanisme proberen te bouwen in iets dat eigenlijk in feite een template taal is. Again PHP staat voor PHP Hypertext Preprocessor, en dat is het dan ook, het is een preprocessor voor hypertext meuk. Dat je er tegenwoordig niet alleen dat mee kan is onderhand wel duidelijk, maar PHP's speerpunt wordt toch echt gereflecteerd in z'n naam, het feit dat het dus hypertext meuk kan preprocessen.

Dat hele verhaal van logica in je views gebruiken "not done is" moet ook maar eens ophouden imo ;-), en elke developer die ook voor andere platformen heeft ontwikkeld weet dat "geen logica in je views" nogal "questionable" is. Wat is hier eigenlijk precies de gedachtengang achter vraag ik me dan af, vooral als mensen dan Smarty templates erbij gaan halen die zelf ook control structures introduceert en eigenlijk een subset van PHP in een PHP bewerkstelligd. In desktop apps is de view vaak ook gewoon een code laag en nergens staat beschreven dat dit perse via een DSL moet zijn. Vandaar dat ik me dan ook afvraag waar deze gedachtengang ten eerste vandaan komt en ten tweede wat de voordelen er dan van zouden moeten zijn om geen logica in je views te hebben (waarbij .oisyn imo de terechte opmerking maakt dat je dan alleen html output ). Velen denken wel dat ze nu door $tpl->assign('foo', 'bar'); doen MVC beter handhaven, maar de realiteit is dat dit regeltje aan code 9/10 keer plaatsvind in de controller (die hoofdzakelijk verantwoordelijk dient te zijn voor user input afhandelen en interactie met de modellen). En als je dit al in een laag zou doen die je de view beschouwd, dan heb je in je .tpl files weer een extra laag aangebracht : wat is het voordeel van deze extra laag vraag ik me dan af. Als je het dan toch zo gelaagd wil doen, output dan alleen XML en transformeer het met XSL... dat was ook toch zo'n succes he?

[Verwijderd]

prototype schreef op dinsdag 14 juli 2009 @ 03:07:
[...]

[verhaal over PHP en views e.d.]

Ik ben het absoluut niet met je eens wat betreft die scheiding van model view controller.

Logic in je view is lelijk. Waarom: bij het scheiden van deze drie voeg je een duidelijke structuur toe. Het betekent niet alleen dat je afzonderlijk aan deze drie kunt werken, het betekent ook dat zaken op een logische plaats staan, waardoor je geen 'spaghetticode' krijgt.

Het toewijzen van variabelen, het assignen, gebeurt in de controller omdat de controller elke beslissing maakt. Dus ook welke content er geassigned wordt naar de view of UI.

Templates kun je zoals je weet ook in bijvoorbeeld java zelf gebruiken, niet alleen in servlets. Ook hier geldt weer: overzicht is de sleutel. Je bouwt een UI. Je laat de controller beslissen wanneer welke UI geladen wordt. Niet andersom. Wat gebeurt er als je het andersom doet? Je krijgt een hele kluwen aan onoverzichtelijke code.

Dat is dus het laatste grote voordeel van templates: je kan 1 controller laten bepalen wanneer ie welke view tevoorschijn haalt, waardoor je vrijwel zeker dingen voorkomt waarmee je verschillende variaties op het opbouwen van een view hebt in 1 klasse. Die verschillende variaties zouden op zich niet het grootste probleem zijn als je een goed doordachte builder gebruikt, maar dat is weer een ander verhaal.

Ik zou jou willen uitdagen om de code van mensen die MVC en andere design patterns netjes uitvoeren te vergelijken met die waar jij voorstander van lijkt te zijn door middel van een complexiteitstool. Je zult versteld staan .

Dus in het kort: views zijn om weer geven. Controller om beslissingen te nemen. Je moet het zo zien: Jij bent manager. Je hebt een typiste(view). Je hebt een blaadje met gegevens (model). Als jij als manager iets uitgetypt wilt hebben door de typiste eis je daarbij dat ze geen eigen input geeft. Jij leest het blaadje, jij beslist welke informatie relevant is en formuleert dat voor de typiste. Het enige wat de typiste moet doen is jouw gedicteerde tekst overschrijven. Niets meer en niets minder. Dan wil je ook niet dat zij op de 'variabelen' die jij doorgeeft gaat beslissen wat zij daar neer moet zetten. Nee, dat komt allemaal bij jou vandaan. En zo werkt MVC dus ook in mijn ogen.

[MBV]

Verwijderd schreef op woensdag 15 juli 2009 @ 00:00:
[...]


[verhaal over templates]

Zoals jij het nu uitlegt is geen MVC meer, maar iets anders. Welke naam zullen we eraan geven? En complexiteitsanalyse is 1. erg lastig bij PHP (geen/weinig tools) en 2. zegt een metric niet zo bar veel, je kan het hooguit gebruiken als indicatie van 'deze functie moet misschien refactored worden'.
Daarnaast mag een View van iedereen beslissingen nemen, denk maar aan deze situaties:
- if $value < 0 then format=red else format=black
- if $count > 85 then 3-col-layout else 2-col-layout
- foreach $item ... (vraag maar aan McCabe )

offtopic:
Als je het niet met me eens bent over metrics, zoek dan eens wat wetenschappelijk bewijs op welke metrics beter werken dan Effective Lines of Code, inclusief een specificatie van die metric die ondubbelzinnig is, d.w.z. je geeft de spec aan 2 personen en ze geven dezelfde getalletjes bij dezelfde bron. Daar gaat eLOC al de mist in. * MBV doet er zijn afstudeeropdracht over, en de onderzoeken die je af en toe ziet over metrics... Kennelijk hebben mensen die zo'n metric verzinnen of zo'n tool bouwen geen zin om een statistisch onderzoek te doen welke metrics werken. Lijken ze waarschijnlijk een beetje op mij

Ik ken overigens wel 2 bedrijven die hun eigen metrics hebben ontwikkeld, en daar ook succes mee hebben. Die verzamelen alle metrics die ze kunnen vinden, hangen wat wegingsfactoren eraan en tadaaaaa, hij werkt.

[ Voor 7% gewijzigd door MBV op 15-07-2009 00:13 ]

[Verwijderd]

MBV schreef op woensdag 15 juli 2009 @ 00:11:
[...]

Zoals jij het nu uitlegt is geen MVC meer, maar iets anders. Welke naam zullen we eraan geven? En complexiteitsanalyse is 1. erg lastig bij PHP (geen/weinig tools) en 2. zegt een metric niet zo bar veel, je kan het hooguit gebruiken als indicatie van 'deze functie moet misschien refactored worden'.
Daarnaast mag een View van iedereen beslissingen nemen, denk maar aan deze situaties:
- if $value < 0 then format=red else format=black
- if $count > 85 then 3-col-layout else 2-col-layout
- foreach $item ... (vraag maar aan McCabe )

offtopic:
Als je het niet met me eens bent over metrics, zoek dan eens wat wetenschappelijk bewijs op welke metrics beter werken dan Effective Lines of Code, inclusief een specificatie van die metric die ondubbelzinnig is, d.w.z. je geeft de spec aan 2 personen en ze geven dezelfde getalletjes bij dezelfde bron. Daar gaat eLOC al de mist in. * MBV doet er zijn afstudeeropdracht over, en de onderzoeken die je af en toe ziet over metrics... Kennelijk hebben mensen die zo'n metric verzinnen of zo'n tool bouwen geen zin om een statistisch onderzoek te doen welke metrics werken. Lijken ze waarschijnlijk een beetje op mij

Oh prima. Moment

[Verwijderd]

Chidamber & Kemerer, moet je kennen.

http://www.aivosto.com/project/help/pm-oo-ck.html

Als jij goede bronnen (bibliotheken) hebt kun je daar zo een hele mooie paper over vinden.

Alle metrics die je daar ziet zijn veel waardevoller dan (E)LoC

Edit:

ik mag waarschijnlijk geen publicaties kopieren, maar als je hierop zoekt kom je wel een stukje verder:

OO Metrics in Practice
David P. Darcy
Chris F. Kemerer

[ Voor 26% gewijzigd door Verwijderd op 15-07-2009 00:37 ]

[Verwijderd]

MBV schreef op woensdag 15 juli 2009 @ 00:11:
[...]


- if $value < 0 then format=red else format=black
- if $count > 85 then 3-col-layout else 2-col-layout
- foreach $item ... (vraag maar aan McCabe )

En nog wat:

- beslissingen over kleur kun je ook gewoon in de controller maken
- layouts stuur je door in de template manager. Geneste layouts stuur je door in een template manager die je dan ook weer in een template manager-instantie kunt stoppen
-McCabe zegt alleen dingen over de Cyclomatic Complexity, niks over dat ie in de view wordt toegepast

2. zegt een metric niet zo bar veel, je kan het hooguit gebruiken als indicatie van 'deze functie moet misschien refactored worden'.

Nou ja, daar heb ik dus een andere mening over. Ik heb dit jaar een paper geschreven over complexiteitsmetrieken (waarschijnlijk ook zo een waar jij het over hebt) en je kunt op verschillende manieren tegen je code aan kijken. Ik zou ook niet weten wat je er anders mee wilt doen dan refactoren.

[ Voor 26% gewijzigd door Verwijderd op 15-07-2009 00:26 ]

[RayNbow]

Ten eerste, gebruik de edit-knop om dubbel/triple/etc-posten tegen te gaan.

Verwijderd schreef op woensdag 15 juli 2009 @ 00:00:
[...]

Ik ben het absoluut niet met je eens wat betreft die scheiding van model view controller.

Logic in je view is lelijk. Waarom: bij het scheiden van deze drie voeg je een duidelijke structuur toe. Het betekent niet alleen dat je afzonderlijk aan deze drie kunt werken, het betekent ook dat zaken op een logische plaats staan, waardoor je geen 'spaghetticode' krijgt.

Presentation logic kan prima in je View. Business logic houd je in je Controller.

[MBV]

Verwijderd schreef op woensdag 15 juli 2009 @ 00:16:
Chidamber & Kemerer, moet je kennen.

http://www.aivosto.com/project/help/pm-oo-ck.html

Als jij goede bronnen (bibliotheken) hebt kun je daar zo een hele mooie paper over vinden.

Alle metrics die je daar ziet zijn veel waardevoller dan (E)LoC

Dikke kans dat die op mijn stageadres (bedrijf in de TU/e) in de kast ligt. Voor mijn opdracht niet relevant: die gaat over embedded SQL. De metrics ken ik wel, o.a. van de grote verschillen die je krijgt als je 2 tools dezelfde metrics laat uitrekenen op dezelfde code

Verwijderd schreef op woensdag 15 juli 2009 @ 00:20:
[...]
En nog wat:

- beslissingen over kleur kun je ook gewoon in de controller maken

Waarom zou je? MVC, zoals dat in dat mooie GoF-boek staat beschreven, biedt o.a. de mogelijkheid om meerdere views aan een model te hangen. Bijv. een digitale en een 'analoge' thermometer. Hoe moet je dan in de controller beslissen welke kleur er wordt gekozen, zeker als je niet eens weet hoeveel soorten views er zijn?

- layouts stuur je door in de template manager. Geneste layouts stuur je door in een template manager die je dan ook weer in een template manager-instantie kunt stoppen

Is dat een reactie op mijn post?

-McCabe zegt alleen dingen over de Cyclomatic Complexity, niks over dat ie in de view wordt toegepast

McCabe telt het aantal beslissingen, en een for-loop telt als beslissing. Was meer als geintje bedoeld.

Nou ja, daar heb ik dus een andere mening over. Ik heb dit jaar een paper geschreven over complexiteitsmetrieken (waarschijnlijk ook zo een waar jij het over hebt) en je kunt op verschillende manieren tegen je code aan kijken. Ik zou ook niet weten wat je er anders mee wilt doen dan refactoren.

Ik kijk er naar uit het perspectief van een externe adviseur die iets moet zeggen over de kwaliteit van code (wat ik niet zelf doe, maar wat mijn collega's doen en waar ik recent veel presentaties over heb gehoord). En dan kijk je naar de code die hoog scoort op verschillende metrics. Waarbij het mij in alle gevallen die ik tot nu toe heb bekeken opvalt hoe sterk de correlatie is tussen de verschillende metrics.

[Verwijderd]

RayNbow schreef op woensdag 15 juli 2009 @ 00:36:
Ten eerste, gebruik de edit-knop om dubbel/triple/etc-posten tegen te gaan.


[...]

Presentation logic kan prima in je View. Business logic houd je in je Controller.

Nou ja goed, daar zijn verschillende kijkwijzen op.

() = controller,
[] = view

(ControllerClass) -> [ PresentationLogicClass -> ViewHTML ]

Zou ook kunnen.

Ik zie persoonlijk die presentation logic ook als controller. Zie mijn voorbeeld over de typiste.

[Verwijderd]

MBV schreef op woensdag 15 juli 2009 @ 00:39:
[...]

Dikke kans dat die op mijn stageadres (bedrijf in de TU/e) in de kast ligt. Voor mijn opdracht niet relevant: die gaat over embedded SQL. De metrics ken ik wel, o.a. van de grote verschillen die je krijgt als je 2 tools dezelfde metrics laat uitrekenen op dezelfde code

De tools zijn inderdaad niet altijd zoals je op basis van de theorie mag verwachten .

Waarom zou je? MVC, zoals dat in dat mooie GoF-boek staat beschreven, biedt o.a. de mogelijkheid om meerdere views aan een model te hangen. Bijv. een digitale en een 'analoge' thermometer. Hoe moet je dan in de controller beslissen welke kleur er wordt gekozen, zeker als je niet eens weet hoeveel soorten views er zijn?

Omdat zoals ik al schreef:

Dat is dus het laatste grote voordeel van templates: je kan 1 controller laten bepalen wanneer ie welke view tevoorschijn haalt, waardoor je vrijwel zeker dingen voorkomt waarmee je verschillende variaties op het opbouwen van een view hebt in 1 klasse.

Die kun je dan eventueel i.s.m. een Factory laten kiezen welke view je wilt gebruiken. Zo begreep ik dat boek hoor.

McCabe telt het aantal beslissingen, en een for-loop telt als beslissing. Was meer als geintje bedoeld.

Hehe, maar ik gebruik sowieso geen for-loops of andere beslissingen in mn view. Dat moet je ten eerste niet willen als je een paar designers voor je hebt werken die niks van programmeren snappen. En ten tweede kan de controller dan zelf al beslissen wat er in komt en niet pas in de view.

Ik kijk er naar uit het perspectief van een externe adviseur die iets moet zeggen over de kwaliteit van code (wat ik niet zelf doe, maar wat mijn collega's doen en waar ik recent veel presentaties over heb gehoord). En dan kijk je naar de code die hoog scoort op verschillende metrics. Waarbij het mij in alle gevallen die ik tot nu toe heb bekeken opvalt hoe sterk de correlatie is tussen de verschillende metrics.

Nou ja, goed, ik klink misschien wat betweterig, maar probeer zeker dat artikel van C&K te bemachtigen. Ik hoop dat je er wat aan hebt . W.b. die correlatie: dat valt af en toe nog vies tegen. Uiteraard is een klasse die groot is vatbaar voor meerdere complexiteitsproblemen, maar in mijn onderzoek kwamen toch wel verschillende klassen naar boven bij verschillende metrieken (uiteraard: een klasse met veel methoden heeft grote kans dat ie veel koppelingen tussen methoden heeft, maar er is ook een metriek die juist zegt: elke methode moet een binding hebben, maar ook het liefst zo min mogelijk per methode)

Ennnnn omdat ik weet hoe moielijk het is om metrieksoftware te vinden: ik hoop niet dat je die van IBM gebruikte. Ik zou je sterk aanraden om eens bij Imagix te kijken. Ook geen topkwaliteit, maar ze hebben er wel enigszins over nagedacht, i.t.t. IBM en die anderen waarvan ik de naam kwijt ben

[ Voor 9% gewijzigd door Verwijderd op 15-07-2009 01:02 ]

[prototype]

Verwijderd schreef op woensdag 15 juli 2009 @ 00:00:
[...]


Ik ben het absoluut niet met je eens wat betreft die scheiding van model view controller.

Wat vreselijk om te horen ;-)

Logic in je view is lelijk. Waarom: bij het scheiden van deze drie voeg je een duidelijke structuur toe. Het betekent niet alleen dat je afzonderlijk aan deze drie kunt werken, het betekent ook dat zaken op een logische plaats staan, waardoor je geen 'spaghetticode' krijgt.

De view dient over het algemeen de grafische representatie te zijn van het model, en wordt over 't algemeen via observer pattern genotified van veranderingen: de verantwoordelijkheid van de weergave wordt dan gelegd bij de observer. Let op, ik heb het hier over PRESENTATION logics, i.e. logics die verantwoordelijk zijn voor de weergave van de view elementen. De observer pattern speelt hierbij als een laag aan indirectie en houdt MVC nog steeds via deze weg in stand mbt decoupling. Uit pure nieuwschierigheid en vat het zeker niet op als aanval, maar waar heb jij MVC van geleerd? :-)

Verder, spaghetticode kan iedereen maken, zelfs binnen 1 laag, dus dat argument gaat niet op.

Het toewijzen van variabelen, het assignen, gebeurt in de controller omdat de controller elke beslissing maakt. Dus ook welke content er geassigned wordt naar de view of UI.

Nope. Bij MVC dient de controller de input af te handelen van de gebruiker en eventueel operaties uit te voeren op het model. Wanneer het model als gevolg hiervan een statechange met zich meebrengt zal via observer pattern de views hiervan genotified worden en zo blijft scheiding nog steeds gewaarborgd. Dat gezegd hebbende is het bij webapplicaties net een ander verhaal door de stateless nature van HTTP requests en valt er idd wel wat voor te zeggen om in de controller variabelen vrij te geven die de view zou mogen accessen om bepaalde keuzes te kunnen maken. Rails doet dit bijvoorbeeld ook, maar let op, dit is wel degelijk iets anders dan een string replace doen op een html file oid zoals de meeste "template engines" dat doen. Vanuit dat aspect kan je eigenlijk dergelijke waarden ook zien als quasi model: ideaal is het niet, maar goed, schoner hebben we het nog niet kunnen bedenken :-)

Templates kun je zoals je weet ook in bijvoorbeeld java zelf gebruiken, niet alleen in servlets. Ook hier geldt weer: overzicht is de sleutel. Je bouwt een UI. Je laat de controller beslissen wanneer welke UI geladen wordt. Niet andersom. Wat gebeurt er als je het andersom doet? Je krijgt een hele kluwen aan onoverzichtelijke code.

Sorry maar dit is echt klinklare onzin. Again, de controller is verantwoordelijk voor het afhandelen van user input en interactie van de modellen. De view is simpelweg verantwoordelijk voor de grafische representatie van dit geheel, en kan via observer pattern prima gescheiden gehouden worden. Sterker nog, met deze aanpak kan je gewoon meerdere views maken die net de modellen b.v. anders weergeven. Jouw suggestie zou impliceren dat we meerdere controllers zouden moeten schrijven (edit: of een draak van een controller hebben die met alle mogelijkheden rekening probeert te houden), maar dat geeft niet altijd het gewenste effect mbt de views. Juist door het argument wat je noemt dat de views dan al uit gaan van een bepaalde structuur. Stel dat je zowel een HTML view als een PDF view wil hebben (ik noem maar wat). Dan kom jij er niet alleen met je controller aanpassing doordat de structuur van HTML/PDF gewoon heel anders van elkaar is. Met mijn aanpak kom je daarentegen wel door simpelweg een view te schrijven voor zowel HTML als voor PDF. De controller kan je hierbij dan zowat ongemoeid laten. ([b]edit: tenzij je uiteraard een view maakt die zo anders is dat die ook een andere controller vereist, maar again, dat kan prima met deze aanpak)

Dat is dus het laatste grote voordeel van templates: je kan 1 controller laten bepalen wanneer ie welke view tevoorschijn haalt, waardoor je vrijwel zeker dingen voorkomt waarmee je verschillende variaties op het opbouwen van een view hebt in 1 klasse. Die verschillende variaties zouden op zich niet het grootste probleem zijn als je een goed doordachte builder gebruikt, maar dat is weer een ander verhaal.

Zie mijn vorige punt. Het hebben van meerdere views itt meerdere controllers die met manipulatie direct de views proberen te vormen biedt minder flexibiliteit door die structuur die jij juist zo hoog in het vaandel houdt.

Ik zou jou willen uitdagen om de code van mensen die MVC en andere design patterns netjes uitvoeren te vergelijken met die waar jij voorstander van lijkt te zijn door middel van een complexiteitstool. Je zult versteld staan .

Ik zou jou willen uitdagen om eigenlijk een goed MVC boek erbij te pakken (MVC volgens GoF b.v. en pak dan in het bijzonder dat UML diagram dat erbij staat... wat een verassing, precies zoals ik het beschrijf ) of anders even met m'n software engineering professor te praten ;-)

Dus in het kort: views zijn om weer geven. Controller om beslissingen te nemen. Je moet het zo zien: Jij bent manager. Je hebt een typiste(view). Je hebt een blaadje met gegevens (model). Als jij als manager iets uitgetypt wilt hebben door de typiste eis je daarbij dat ze geen eigen input geeft. Jij leest het blaadje, jij beslist welke informatie relevant is en formuleert dat voor de typiste. Het enige wat de typiste moet doen is jouw gedicteerde tekst overschrijven. Niets meer en niets minder. Dan wil je ook niet dat zij op de 'variabelen' die jij doorgeeft gaat beslissen wat zij daar neer moet zetten. Nee, dat komt allemaal bij jou vandaan. En zo werkt MVC dus ook in mijn ogen.

Niet helemaal dus en daar zie ik dus ook de fout in je denken (en ja, je gaat nu vast tand en oog vechten om je gelijk te halen and well, je doet je best maar ;-)). Analogien aside, de controller is verantwoordelijk idd voor het maken van beslissingen, de model modeleert de business en de view is echter verantwoordelijk voor de grafische representatie van dit geheel. Dit kan door observer pattern te gebruiken. Als je het toch graag wil spelen op analogien dan is de view een schilder, de model... een model ( ;-) ), en de controller is de opdrachtgever c.q. artdirector. Als je als artdirector zowel een schilderij van het model in baroque style en als avant-garde wil hebben, dan schakel je daar gewoon 2 daarvoor gespecialiseerde schilders in.

In jouw analogie doet de controller teveel. Die vertelt nu de typiste hoe ze haar werk moet doen terwijl de typiste prima ook kan bepalen wat ze moet doen mbt de weergave van iets. Indien de manager er niet mee tevreden is dan kan die een andere typiste inschakelen in mijn voorbeeld. En als we de analogie doortrekken in de businesswereld, is jouw aanpak bureaucratisch en de mijne (en die ook van de GoF) gewoon horizontaal ;-)

[ Voor 1% gewijzigd door prototype op 15-07-2009 01:14 . Reden: Het is laat. ]

[MBV]

Verwijderd schreef op woensdag 15 juli 2009 @ 00:58:

Omdat zoals ik al schreef:
[...]

Dus de Controller, die volgens de GoF niet eens weet hoeveel views er zijn, moet 1) gaan beslissen welke views er zijn en 2) de layout van de views gaan bepalen? Bij mijn weten werd de layout door de views bepaald, en niet andersom.

Die kun je dan eventueel i.s.m. een Factory laten kiezen welke view je wilt gebruiken. Zo begreep ik dat boek hoor.

Hij ligt op mijn bureau bij de TU/e, ik zal het morgen nog eens doorlezen. Als daar iets anders uit komt dan de post van prototype, laat ik het weten.

[...]

Hehe, maar ik gebruik sowieso geen for-loops of andere beslissingen in mn view. Dat moet je ten eerste niet willen als je een paar designers voor je hebt werken die niks van programmeren snappen. En ten tweede kan de controller dan zelf al beslissen wat er in komt en niet pas in de view.

Hoe geef je dan een tabel weer? Als je geen for-loops in je view hebt zitten, zie ik een hele bak onwijs smerige hacks die hetzelfde effect hebben voor me...

---

Nou ja, goed, ik klink misschien wat betweterig, maar probeer zeker dat artikel van C&K te bemachtigen. Ik hoop dat je er wat aan hebt . W.b. die correlatie: dat valt af en toe nog vies tegen.

Ik zal direct toegeven dat ik niet recent naar OO-metrics heb gekeken, ik houd me daar namelijk nu niet mee bezig. Bij mijn HBO scriptie had ik die wel meegenomen, maar door de staat van de software (LOCM van meer dan 90% bij 90% van de klasses ) waren die niet bruikbaar. C-code was met perl omgezet in C++...

Ennnnn omdat ik weet hoe moielijk het is om metrieksoftware te vinden: ik hoop niet dat je die van IBM gebruikte. Ik zou je sterk aanraden om eens bij Imagix te kijken. Ook geen topkwaliteit, maar ze hebben er wel enigszins over nagedacht, i.t.t. IBM en die anderen waarvan ik de naam kwijt ben

Leuk idee, maar noem maar eens een pakket wat de bindingen tussen embedded SQL en de host-language (bijv. COBOL ) in kaart brengt, en metrieken over die embedded SQL geeft . Geef mij de definitie van een metriek en ik programmeer hem, da's geen probleem (mooi grammar die 99,9% van de code dekt is er al, en 3/4 van de metrieken is een dom tellertje), maar de validatie van metrieken op SQL valt nogal tegen. Enige wat ik heb kunnen vinden met meer onderbouwing dan 'volgens mij doet'ie het' was het aantal tabellen.

[masq]

De C in het MVC van tegenwoordig is gewoon niet meer dezelfde Controller die GoF voor ogen had. In de GoF versie is de controller niks anders dan ordinaire glue om model en views te decouplen. De Controller "2.0" doet vaak veel meer dan dat, meestal bedoeld om een stukje statefulness te brengen naar het van zichzelf zo state-loze web. De rol is verschoven van die van mediator naar die van centrale aansturing. Zie ook Whatsa Controller Anyway op c2.com.

Ook wijkt de definitie van een view vaak af van wat GoF beschrijft. Zoals ik GoF lees is een view simpelweg een representatie van een deel van het model (of een van de modellen?). Volgens deze definitie zou je prima op een scherm/pagina meerdere views kunnen hebben die allemaal hetzelfde representeren. Dat strookt niet helemaal met de "view = pagina"-definitie die vaak gebruikt wordt.

[MBV]

masq schreef op woensdag 15 juli 2009 @ 02:02:
De C in het MVC van tegenwoordig is gewoon niet meer dezelfde Controller die GoF voor ogen had. In de GoF versie van is de controller niks anders dan ordinaire glue om model en views te decouplen. De Controller "2.0" doet vaak veel meer dan dat, meestal bedoeld om een stukje statefulness te brengen naar het van zichzelf zo state-loze web. De rol is verschoven van die van mediator naar die van centrale aansturing. Zie ook Whatsa Controller Anyway op c2.com.

Ook wijkt de definitie van een view vaak af van wat GoF beschrijft. Zoals ik GoF lees is een view simpelweg een representatie van een deel van het model (of een van de modellen?). Volgens deze definitie zou je prima op een scherm/pagina meerdere views kunnen hebben die allemaal hetzelfde representeren. Dat strookt niet helemaal met de "view = pagina"-definitie die vaak gebruikt wordt.

Volgens mij vergis je je: GoF (Design Patterns door Gamma&Co) beschrijft alleen MVC in Smalltalk, en verder de patterns die binnen MVC voorkomen (observer etc) Uiteraard kan je de View op meerdere lagen zien, bijvoorbeeld een HTML-view, een PDF-view, en een webservice die hetzelfde model ontsluit. Maar in smalltalk heb je 2 dingen op hetzelfde scherm die hetzelfde gegeven weergeven (tabel en grafiek bijv). Centraal in al die views staat volgens mij wel dat de view beslist hoe iets wordt weergegeven, en niet alleen het theme is.

[PrisonerOfPain]

De GoF definitie van MVC is dan ook niet een op een toepasbaar op het web; inmiddels is het pattern een stukje doogeevolueerd, en zo omgebogen dat het toepasbaar is op het web. Dat wil niet zeggen dat de drie onderdelen erg veel in betekenis hebben veranderd maar wel dat een exacte definitie meestal moeilijker te geven is dan voorheen het geval was. Iets wat zeker bij de View en Controller het geval is omdat die op protocol niveau (HTTP / HTML) meer verbonden zijn dan bij, desktop applicaties.

masq schreef op woensdag 15 juli 2009 @ 02:02:
Dat strookt niet helemaal met de "view = pagina"-definitie die vaak gebruikt wordt.

Meestal word daarom gesproken van composite views om aan te geven dat je een hierarchie hebt van meerdere views in een pagina.

[ Voor 44% gewijzigd door PrisonerOfPain op 15-07-2009 11:01 ]

[Janoz]

Verwijderd schreef op woensdag 15 juli 2009 @ 00:20:
- beslissingen over kleur kun je ook gewoon in de controller maken

Wacht even. Jij vind dat het bepalen van de kleur waarmee iets gerenderd wordt niet in de view thuis hoort, maar in de controller? En dan gaat er niet een belletje rinkelen dat er misschien iets niet helemaal in orde is?

Ik heb even je typiste voorbeeld erbij gehaald:

Dus in het kort: views zijn om weer geven. Controller om beslissingen te nemen. Je moet het zo zien: Jij bent manager. Je hebt een typiste(view). Je hebt een blaadje met gegevens (model). Als jij als manager iets uitgetypt wilt hebben door de typiste eis je daarbij dat ze geen eigen input geeft. Jij leest het blaadje, jij beslist welke informatie relevant is en formuleert dat voor de typiste. Het enige wat de typiste moet doen is jouw gedicteerde tekst overschrijven. Niets meer en niets minder. Dan wil je ook niet dat zij op de 'variabelen' die jij doorgeeft gaat beslissen wat zij daar neer moet zetten. Nee, dat komt allemaal bij jou vandaan. En zo werkt MVC dus ook in mijn ogen.

Het enige dat je als manager doet is acties op je briefje uithalen. Deze informatie moet erbij, deze informatie moet eraf en deze informatie mag er in deze situatie niet op staan. In de pure originele vorm van MVC geef je vervolgens het briefje aan de typiste (of eigenlijk: het briefje roept de typiste om te zeggen dat hij veranderd is). De typiste bepaald vervolgens de typografie. Zij bepaald de afstand tussen de paragrafen, het lettertype, de marges. Zij bepaald of de tabulaire data om en om gekleurde rijen krijgt en welke kleuren dat zijn. Zij bepaald ook welke kolommen nu wel of niet van belang zijn. Zij bepaald in welke volgorde alles gesorteerd is en eventueel of het over meerder pagina's verdeeld zou moeten worden. Zij kan zelfs beslissen om het niet in een tabel, maar als grafiek weer te geven. Dat is de view, dat is presentatie en ook daar heb je logica voor nodig.

[Verwijderd]

prototype schreef op woensdag 15 juli 2009 @ 01:05:
[...]

Wat vreselijk om te horen ;-)

Ja he . Het is goed om er over na te denken. En dan ben ik het liever niet met iemand eens dan wel, want dat dwingt je daar meer toe.

1) De view dient over het algemeen de grafische representatie te zijn van het model, en 2) wordt over 't algemeen via observer pattern genotified van veranderingen: de verantwoordelijkheid van de weergave wordt dan gelegd bij de observer. Let op, ik heb het hier over PRESENTATION logics, i.e. logics die verantwoordelijk zijn voor de weergave van de view elementen. De observer pattern speelt hierbij als een laag aan indirectie en houdt MVC nog steeds via deze weg in stand mbt decoupling. Uit pure nieuwschierigheid en vat het zeker niet op als aanval, maar waar heb jij MVC van geleerd? :-)

Verder, spaghetticode kan iedereen maken, zelfs binnen 1 laag, dus dat argument gaat niet op.

1) Precies. Dus die moet dan niet ook nog eens gaan beslissen wat te doen.

2) Een observer neemt geen beslissingen. Een observer doet een update naar de waarden die door de observable zijn doorgegeven.

Stel je nou eens voor: je hebt 100 Views. En die 100 Views moeten allemaal hun eigen beslissing nemen. Dan heb je dus een Cyclomatic Complexity van 100 keer zo groot dan als je die in de Controller laat nemen en de View hiervan notified. Indien een state-change het veranderen van een kleur inhoudt, dan zegt de Controller: view.setColor(). En in de setColor() wordt dan een refresh gedaan van de UI. Dat doet die view dan wel, maar die view beslist niks. Die view past alleen zijn eigenschappen toe.

1)Nope. Bij MVC dient de controller de input af te handelen van de gebruiker en eventueel operaties uit te voeren op het model. Wanneer het model als gevolg hiervan een statechange met zich meebrengt zal via observer pattern de views hiervan genotified worden en zo blijft scheiding nog steeds gewaarborgd. Dat gezegd hebbende is het bij webapplicaties net een ander verhaal door de stateless nature van HTTP requests en valt er idd wel wat voor te zeggen om in de controller variabelen vrij te geven die de view zou mogen accessen om bepaalde keuzes te kunnen maken. Rails doet dit bijvoorbeeld ook, maar let op, dit is wel degelijk iets anders dan een string replace doen op een html file oid zoals de meeste "template engines" dat doen. Vanuit dat aspect kan je eigenlijk dergelijke waarden ook zien als quasi model: ideaal is het niet, maar goed, schoner hebben we het nog niet kunnen bedenken :-)

1) Ja en dus? Wat is hierin dan de Observable? Dat is dus de Controller.

Sorry maar dit is echt klinklare onzin. Again, de controller is verantwoordelijk voor het afhandelen van user input en interactie van de modellen. De view is simpelweg verantwoordelijk voor de grafische representatie van dit geheel, en kan via observer pattern prima gescheiden gehouden worden. Sterker nog, met deze aanpak kan je gewoon meerdere views maken die net de modellen b.v. anders weergeven. Jouw suggestie zou impliceren dat we meerdere controllers zouden moeten schrijven (edit: of een draak van een controller hebben die met alle mogelijkheden rekening probeert te houden), maar dat geeft niet altijd het gewenste effect mbt de views. Juist door het argument wat je noemt dat de views dan al uit gaan van een bepaalde structuur. 2)Stel dat je zowel een HTML view als een PDF view wil hebben (ik noem maar wat). Dan kom jij er niet alleen met je controller aanpassing doordat de structuur van HTML/PDF gewoon heel anders van elkaar is. Met mijn aanpak kom je daarentegen wel door simpelweg een view te schrijven voor zowel HTML als voor PDF. De controller kan je hierbij dan zowat ongemoeid laten. ([b]edit: tenzij je uiteraard een view maakt die zo anders is dat die ook een andere controller vereist, maar again, dat kan prima met deze aanpak)

1) Dat vind ik dus klinkklare onzin, want als je goed las heet die draak van een Controller een Facotry pattern. Die is daarin gespecialiseerd. En ik snap niet waar je het in godsnaam vandaan haalt dat je met mijn systeem maar 1 type view kunt gebruiken? Dat is juist de clue: dat kan wel. Het enige wat je moet doen is de juiste data doorgeven. Die data die benodigd is blijft namelijk altijd hetzelfde. Al heb je 3 miljoen Views. De Controller zegt: ik wil die en die data doorgeven in die en die view. Die view presenteert dan die data, op zijn manier, maar wel de data die uitgekozen is door de Controller. De View verandert naar gelang de waarden van de Controller anders zijn.

En wat betreft de states:

stel je dit voor:

code:

//Controller:

public void createView(){
        ViewFactory vf = new ViewFacotry();
        View view = vf.getConcreteView("honingraten");
}


public void notify(){
     if (state = "active"){
         view.setActive(); //roep de 'update' aan
     }

     if (state = "idle"){
         view.setIdle(); //roep de 'update' aan
     }
}

//View (elke view die je kunt verzinnen):

ViewMetVisjesMotief{



      public void setIdle(){
              // in het visjesmotief is de kleur van Idle blauw
              setColorVanBetreffendeElementen(COLOR.blue);
                refreshView();
        }
      public void setActive(){
              // in het visjesmotief is de kleur van Idle blauw
              setColorVanBetreffendeElementen(COLOR.red);
                refreshView();
        }
}

ViewMetHoningRaten
        public void setIdle(){
             // in het visjesmotief is de kleur van Idle geel
                setColorVanBetreffendeElementen(COLOR.yellow);
                refreshView();
      public void setActive(){
              // in het visjesmotief is de kleur van Idle blauw
              setColorVanBetreffendeElementen(COLOR.red);
                refreshView();
        }
}

De View beslist hier he-le-maal niets. Maar hij heeft wel zijn eigen weergave, op commando van de Controller. De controller bepaalt welke view er noodzakelijk is. De controller bepaalt welke state er actief is en geeft de View de opdracht de bijbehorende kleur in zijn stijl op te halen. Die controller kan uit meerdere types views kiezen en ze dynamisch veranderen.

MOet je je nu eens voorstellen dat de if statement in de view gedaan wordt (idem dito voor de foreach):

code:

//Controller:


public void createView(){
        ViewFactory vf = new ViewFacotry();
        View view = vf.getConcreteView("honingraten");
}

public void notify{
     view.update(state);
}

//View (elke view die je kunt verzinnen):

ViewMetVisjesMotief{
     public void update(){
          if (state = "active"){
              view.setActive(); //roep de 'update' aan
          }

          if (state = "idle"){
              view.setIdle(); //roep de 'update' aan
          }
     }

      public void setIdle(){
              // in het visjesmotief is de kleur van Idle blauw
              setColorVanBetreffendeElementen(COLOR.blue);
                refreshView();
        }

      public void setActive(){
              // in het visjesmotief is de kleur van Idle blauw
              setColorVanBetreffendeElementen(COLOR.red);
                refreshView();
        }
}

ViewMetHoningRatenMotief(){
     public void update(){
          if (state = "active"){
              view.setActive(); 
          }

          if (state = "idle"){
              view.setIdle(); 
          }
     }

        public void setIdle(){
             // in het visjesmotief is de kleur van Idle geel
                setColorVanBetreffendeElementen(COLOR.yellow);
                refreshView();

      public void setActive(){
              // in het visjesmotief is de kleur van Idle blauw
              setColorVanBetreffendeElementen(COLOR.red);
                refreshView();
        }
}

Hopla! Cyclomatic Complexity van 10000% in het geval van 100 Views. Dan neemt je CC met elke klasse die je maakt 2 toe. Dat wil je echt niet.

Het is misschien verwarrend, maar de view hoeft geen keuzes te maken wat betreft zijn weergave. De keuzes staan al vast: het is aan de controller deze keuze te activeren.

2) Nee. Je ziet het helemaal verkeerd. HEt enige wat de controller uiteindelijk doet is de juiste waarden doorgeven (de bean dus). Die waarden worden geplaatst in de view. Daar hoeft de view niks over te beslissen. De view doet alleen dom zijn kleurenpatroon, zijn plaatjes, alles wat specifiek is aan hem weergeven. Maar de beslissing welke staat hij moet weergeven is al in de Controller (Observable) gemaakt.

Ik zou jou willen uitdagen om eigenlijk een goed MVC boek erbij te pakken (MVC volgens GoF b.v. en pak dan in het bijzonder dat UML diagram dat erbij staat... wat een verassing, precies zoals ik het beschrijf ) of anders even met m'n software engineering professor te praten ;-)

Er staat ner-gens iets wat mijn kijkwijze negativeert . Het boek maakt onderscheid tussen M, V en C. Joh, dat doe ik ook . Wat jij hier allemaal zegt is zelfs klakkeloos overgenomen uit dat boek. Wist je al dat:

Een Design Pattern is de kern van de oplossing van een veelvuldig voorkomend programmeerprobleem

Vind je het gek dat er meningsverschillen over bestaan

Ik zou het anders zelf nog een keer lezen: wat die JSP-pagina doet is het uitlezen van een bean binnen zijn lay-out. Als je die bean eenmaal hebt doorgegeven hoeven daar geen beslissingen meer over genomen te worden. Als je een foreach loop hebt pak je elke keer een UI element die je op elkaar bouwt a.d.h.v. bijv. een Builder-Controller.

Niet helemaal dus en daar zie ik dus ook de fout in je denken (en ja, je gaat nu vast tand en oog vechten om je gelijk te halen and well, je doet je best maar ;-)). Analogien aside, de controller is verantwoordelijk idd voor het maken van beslissingen, de model modeleert de business en de view is echter verantwoordelijk voor de grafische representatie van dit geheel. Dit kan door observer pattern te gebruiken. Als je het toch graag wil spelen op analogien dan is de view een schilder, de model... een model ( ;-) ), en de controller is de opdrachtgever c.q. artdirector. Als je als artdirector zowel een schilderij van het model in baroque style en als avant-garde wil hebben, dan schakel je daar gewoon 2 daarvoor gespecialiseerde schilders in.

Ja eh, prima, daar ben ik het ook mee eens. Maar dat zegt nog steeds dat de schilder geen beslissingsbevoegdheid heeft.

Je hebt mij niks horen zeggen over de verschillende stijlen. Dat zijn de verschillende Views en daar kun je er best meerederen van hebben?

In jouw analogie doet de controller teveel. Die vertelt nu de typiste hoe ze haar werk moet doen terwijl de typiste prima ook kan bepalen wat ze moet doen mbt de weergave van iets. Indien de manager er niet mee tevreden is dan kan die een andere typiste inschakelen in mijn voorbeeld. En als we de analogie doortrekken in de businesswereld, is jouw aanpak bureaucratisch en de mijne (en die ook van de GoF) gewoon horizontaal ;-)

De typiste heeft haar eigen stijl. Inhoudelijk heeft ze niks te zeggen.

[Verwijderd]

Janoz schreef op woensdag 15 juli 2009 @ 11:23:
[...]

Wacht even. Jij vind dat het bepalen van de kleur waarmee iets gerenderd wordt niet in de view thuis hoort, maar in de controller? En dan gaat er niet een belletje rinkelen dat er misschien iets niet helemaal in orde is?

Nope: ik vind dat de Controller moet doen: setColorActive();

De 'typiste' kan dan zien: " he colorActive(), dat is bij het type brief dat ik moet schrijven: rood"

Ik heb even je typiste voorbeeld erbij gehaald:

[...]

Het enige dat je als manager doet is acties op je briefje uithalen. Deze informatie moet erbij, deze informatie moet eraf en deze informatie mag er in deze situatie niet op staan. In de pure originele vorm van MVC geef je vervolgens het briefje aan de typiste (of eigenlijk: het briefje roept de typiste om te zeggen dat hij veranderd is). De typiste bepaald vervolgens de typografie. Zij bepaald de afstand tussen de paragrafen, het lettertype, de marges. Zij bepaald of de tabulaire data om en om gekleurde rijen krijgt en welke kleuren dat zijn. Zij bepaald ook welke kolommen nu wel of niet van belang zijn. Zij bepaald in welke volgorde alles gesorteerd is en eventueel of het over meerder pagina's verdeeld zou moeten worden. Zij kan zelfs beslissen om het niet in een tabel, maar als grafiek weer te geven. Dat is de view, dat is presentatie en ook daar heb je logica voor nodig.

Niet als er daar al voorgedefinieerde standaarden over bestaan.

Laat ik het zo zeggen:

Als je de klasse ZakelijkeBriefTypiste hebt, dan staan daar die kleuren en tabellen alle andere stijlattributen al in. Die staan al vast in het geval van zakelijke brief. Dat noem ik geen beslissing nemen.

Ik snap je punt verder, daar niet van

[ Voor 8% gewijzigd door Verwijderd op 15-07-2009 12:06 ]

[Erkens]

Verwijderd schreef op woensdag 15 juli 2009 @ 12:01:
Nope: ik vind dat de Controller moet doen: setColorActive();

De 'typiste' kan dan zien: " he colorActive(), dat is bij het type brief dat ik moet schrijven: rood"

Nee, de controller moet setActive() doen, waarna de View kan bepalen dat dit betekend dat de kleur moet veranderen. Wellicht wil je in de toekomst diezelfde code ook gebruiken voor iets waarbij het actieve "ding" niet een andere kleur moet hebben maar bijvoorbeeld cursief moet worden weergegeven

[Woy]

@BroxTheMan: In je code voorbeelden zet je zelf ook de kleur van de elementen in je View en dus spreek je jezelf nogal tegen. Je controller moet niet willen bepalen welke kleur een view iets weergeeft ( Behalve als Color een data element van de Model is natuurlijk, maar meestal is dat het niet ).

Zoals al meerdere mensen gezegd hebben is een View verantwoordelijk voor het weergeven van Data, hoe hij dat doet is zijn eigen verantwoordelijkheid.

Je kunt bijvoorbeeld een GreenNoticeView of een YellowNoticeView hebben. Het is dan dus zeker niet aan de controller om te bepalen welke kleur iets moet worden.

[ Voor 40% gewijzigd door Woy op 15-07-2009 12:09 ]

[user109731]

Ik ga me niet verder in deze discussie mengen, maar twee kleine vraagjes:

Verwijderd schreef op woensdag 15 juli 2009 @ 11:57:
dan zegt de Controller: view.setColor().

Wat nou als we een monochrome PDF willen maken, die view ondersteunt geen kleuren (maar cursieve tekst ofzo). Het is toch veel mooier om dit dus lekker door de view zélf te laten beslissen?

De te gebruiken kleur is iets wat je imho juist in de view wilt hebben, zodat je makkelijk meerdere views met een eigen stijl kunt maken

Hoe denk jij over het HTML/PDF voorbeeld van prototype? Daar zou jij dus twee controllers + twee views maken?

[ Voor 4% gewijzigd door user109731 op 15-07-2009 12:10 ]

[Verwijderd]

Erkens schreef op woensdag 15 juli 2009 @ 12:04:
[...]

Nee, de controller moet setActive() doen, waarna de View kan bepalen dat dit betekend dat de kleur moet veranderen. Wellicht wil je in de toekomst diezelfde code ook gebruiken voor iets waarbij het actieve "ding" niet een andere kleur moet hebben maar bijvoorbeeld cursief moet worden weergegeven

Dat was een voorbeeld . Maar dan nog staat er voor View 1 vast dat ie in het geval van status "active" kleur G gebruikt. En niet dat ie in View 1 nog eens gaat kijken: "is ie active?"

[Verwijderd]

Woy schreef op woensdag 15 juli 2009 @ 12:07:
@BroxTheMan: In je code voorbeelden zet je zelf ook de kleur van de elementen in je View en dus spreek je jezelf nogal tegen. Je controller moet niet willen bepalen welke kleur een view iets weergeeft ( Behalve als Color een data element van de Model is natuurlijk, maar meestal is dat het niet ).

Zoals al meerdere mensen gezegd hebben is een View verantwoordelijk voor het weergeven van Data, hoe hij dat doet is zijn eigen verantwoordelijkheid.

Je kunt bijvoorbeeld een GreenNoticeView of een YellowNoticeView hebben. Het is dan dus zeker niet aan de controller om te bepalen welke kleur iets moet worden.

Pfff. HEt was een voorbeeldje. Ok, slecht voorbeeldje, maar wat ik wilde zeggen is dat je d beslissingen over welke View niet in de View doet wan t dan is het al te laat.

En dat is dus wel aan de controller. De controller zegt: he GreenViewNotice, wil jij voor mij even deze bean weergeven.

[ Voor 4% gewijzigd door Verwijderd op 15-07-2009 12:11 ]

[Verwijderd]

JanDM schreef op woensdag 15 juli 2009 @ 12:09:
Ik ga me niet verder in deze discussie mengen, maar twee kleine vraagjes:

[...]

Wat nou als we een monochrome PDF willen maken, die view ondersteunt geen kleuren (maar cursieve tekst ofzo). Het is toch veel mooier om dit dus lekker door de view zélf te laten beslissen?

De te gebruiken kleur is iets wat je imho juist in de view wilt hebben, zodat je makkelijk meerdere views met een eigen stijl kunt maken

Hoe denk jij over het HTML/PDF voorbeeld van prototype? Daar zou jij dus twee controllers + twee views maken?

Ja goed, maar dan moet ie niet in de view nog aankomen: if(active) color = null. Bij wijze van.

Dan zeg je: pdfMonoChrome.setStatus(). Dat is de beslissing. De kleur die er bij hoort zoekt ie dan op. Opzoeken is geen beslissen.

[MBV]

Verwijderd schreef op woensdag 15 juli 2009 @ 12:09:
[...]


Dat was een voorbeeld . Maar dan nog staat er voor View 1 vast dat ie in het geval van status "active" kleur G gebruikt. En niet dat ie in View 1 nog eens gaat kijken: "is ie active?"

Iedereen valt vooral over jouw voorbeeld dat de controller bepaalt wat de kleur van een ding in de View wordt, en vervolgens is het alleen 'een voorbeeld'?

Een View is vrij om elke kleur te gebruiken die hij wil, en die kleur te laten afhangen van wat hij wil. In mijn voorbeeld (ergens bij het begin van deze discussie) gaf ik 'if < 0 color=red' als voorbeeld van een beslissing die de View neemt. Uiteraard voor iets als een bankrekening. Bij een lijstje met items, met een aparte kleur voor active, haalt de View uit het Model of een item active is, en neemt vervolgens de beslissing om die cursief en paars te maken. Daar beslist de Controller toch niet wélke kleur er wordt weergegeven? Hij geeft alleen een andere status aan het item.

[Verwijderd]

MBV schreef op woensdag 15 juli 2009 @ 12:18:
[...]

Iedereen valt vooral over jouw voorbeeld dat de controller bepaalt wat de kleur van een ding in de View wordt, en vervolgens is het alleen 'een voorbeeld'?

Een View is vrij om elke kleur te gebruiken die hij wil, en die kleur te laten afhangen van wat hij wil. In mijn voorbeeld (ergens bij het begin van deze discussie) gaf ik 'if < 0 color=red' als voorbeeld van een beslissing die de View neemt. Uiteraard voor iets als een bankrekening. Bij een lijstje met items, met een aparte kleur voor active, haalt de View uit het Model of een item active is, en neemt vervolgens de beslissing om die cursief en paars te maken. Daar beslist de Controller toch niet wélke kleur er wordt weergegeven? Hij geeft alleen een andere status aan het item.

Ja heuh, toen ontdekte ik dat het voorbeeld niet zo sterk was , maar het is niet het concrete voorbeeld wat ik duidelijk wilde maken.

Wat ik duidelijk wil maken is dat het in mijn ogen handiger is om die if statements buiten de view te houden.

[Janoz]

Verwijderd schreef op woensdag 15 juli 2009 @ 12:09:
[...]


Dat was een voorbeeld . Maar dan nog staat er voor View 1 vast dat ie in het geval van status "active" kleur G gebruikt. En niet dat ie in View 1 nog eens gaat kijken: "is ie active?"

Dat klopt. De view doet gewoon modelItem.isActive() en bepaald dan een andere kleur (of italic of bold of wat dan ook). De controler zorgt alleen dat de active boolean gezet wordt, meer niet. De controler heeft helemaal niks te maken met het groen of bold zijn van een active element.

Verwijderd schreef op woensdag 15 juli 2009 @ 12:11:
[...]


Pfff. HEt was een voorbeeldje. Ok, slecht voorbeeldje, maar wat ik wilde zeggen is dat je d beslissingen over welke View niet in de View doet wan t dan is het al te laat.

En dat is dus wel aan de controller. De controller zegt: he GreenViewNotice, wil jij voor mij even deze bean weergeven.

Ah, nu beginnen er dingen te dagen. Ik heb het vermoeden dat we hier te maken hebben met een klassiek voorbeeld van iemand die moeite heeft met het onderscheiden van semantiek en presentatie. Je ziet het bijvoorbeeld heel veel in het webdesign. css-styles die groen of oranje heten terwijl ze eigenlijk emphasized of quote hadden moeten heten. Een view hoort geen 'greenview' te heten, maar webview, pdfview ofandereToepassingView. Die view kan vervolgens zelf wel weten of hij groen geel of pimpelpaars is.

Op zich leuk bedacht hoor, maar het staat zo enorm stom wanneer de applicatie na een huisstijl wijziging nog steeds een greenview class heeft die vervolgens een rode pagina rendered. De content is niet veranderd, de semantiek is hetzelfde, maar de huisstijl dicteert dat nu al het groen rood moet zijn.

Verwijderd schreef op woensdag 15 juli 2009 @ 12:15:
Ja goed, maar dan moet ie niet in de view nog aankomen: if(active) color = null. Bij wijze van.

Dan zeg je: pdfMonoChrome.setStatus(). Dat is de beslissing. De kleur die er bij hoort zoekt ie dan op. Opzoeken is geen beslissen.

if (modelItem.isActive) typografie = italic
is ook een beslissing. Dat is ook logica. Als je alle items bij langs gaat heb je een lusje. Bij elke regel wordt opnieuw beslist of die wel of niet italic moet. Dit is wat hier al tijden bedoeld wordt met presentatie logica. Het is de meest simpele vorm. In het geval van de pdf kan het nog een stuk ingewikkelder worden aangezien het hele pdf genereer gebeuren ook onderdeel is van de presentatie logica (of stuur jij vanuit de controler enkel een volledig geencodeerde bytearray naar de view die enkel nog naar een bestand.pdf weggeschreven moet worden), maar je zou ook aan een grafiekje kunnen denken. In principe zou deze gewoon dezelfde bean binnenkrijgen als die tabel view. Het enige verschil is dat er nu van alles op een canvas geplot wordt, eventueel wat gerekend en gegokt wordt aan het bereik van het assenstelsel en dat dit dan aan de gebruiker getoond wordt.

[Pathogen]

Om even op de Model-View-Controller discussie in te haken:

Ik zou presentation logic in de view verwerken, en wel om de volgende redenen.
Op het moment dat je een nieuwe view wilt produceren, is het niet handig als je ook in de controller moet werken.
Dat is vervelend, omdat:
- Je op 2 plekken code aan moet passen ipv 1, meer werk
- Je 2 points of failure maakt ipv 1, meer testwerk/risico
- In sommige gevallen er zelfs een scheiding van verantwoordelijkheden is: 1 programmeur onderhoudt de controller en een andere de view(s), meer personen aan het werk

[Verwijderd]

Janoz schreef op woensdag 15 juli 2009 @ 12:38:

Ah, nu beginnen er dingen te dagen. Ik heb het vermoeden dat we hier te maken hebben met een klassiek voorbeeld van iemand die moeite heeft met het onderscheiden van semantiek en presentatie. Je ziet het bijvoorbeeld heel veel in het webdesign. css-styles die groen of oranje heten terwijl ze eigenlijk emphasized of quote hadden moeten heten. Een view hoort geen 'greenview' te heten, maar webview, pdfview ofandereToepassingView. Die view kan vervolgens zelf wel weten of hij groen geel of pimpelpaars is.

Op zich leuk bedacht hoor, maar het staat zo enorm stom wanneer de applicatie na een huisstijl wijziging nog steeds een greenview class heeft die vervolgens een rode pagina rendered. De content is niet veranderd, de semantiek is hetzelfde, maar de huisstijl dicteert dat nu al het groen rood moet zijn.

Nee nee nee nee nee nee . Wat is dat toch dat er meteen conclusies worden getrokken die niet waar zijn. Die benaming kwam ten eerste van iemand anders, dan wordt er klakkeloos gedaan alsof ik dat verzon. En ten tweede daar draait het niet om. Het draait er om dat je verschillende types layouts kan aanwijzen om je model weer te geven en in die layouts kun je stuk voor stuk dezelfde informatie stoppen en extern al beslissen welk type weergave de View daarvoor gaat kiezen. Die View die ziet dan vervolgens in die methode staan: color = red. Maar dat noem ik geen beslissen. Dat noem ik gewoon uitvoeren.

Zie Abstract Factory. Als jij vindt dat de Factory ook in de View hoort dan denk ik dat we uitgepraat zijn, want dan is het gewoon een verschil in interpretatie die niet echt tot grote verschillen zal leiden.

[Verwijderd]

Thrackan schreef op woensdag 15 juli 2009 @ 13:35:
Om even op de Model-View-Controller discussie in te haken:

Ik zou presentation logic in de view verwerken, en wel om de volgende redenen.
Op het moment dat je een nieuwe view wilt produceren, is het niet handig als je ook in de controller moet werken.
Dat is vervelend, omdat:
- Je op 2 plekken code aan moet passen ipv 1, meer werk
- Je 2 points of failure maakt ipv 1, meer testwerk/risico
- In sommige gevallen er zelfs een scheiding van verantwoordelijkheden is: 1 programmeur onderhoudt de controller en een andere de view(s), meer personen aan het werk

Ik denk dat er gewoon een verschil in interpretatie bestaat .

-1&2 In mijn geval kun je volledig de view veranderen, zonder de code in de controller te moeten aanpassen. Zie nogmaals de Abstract Factory.
-3 Dat is ook helemaal geen probleem

Ik kan het alleen nog niet zo duidelijk maken blijkt maar weer, maar dat wordt me ook niet makkelijk gemaakt met mensen die elk concrete schoonheidsfoutje een fout van formaat maken in plaats van de moeite doen de achterliggende gedachte te begrijpen.

[Woy]

@BroxTheMan: Maar vind jij dan dus dat ( neem even een lijst van items die eventueel active kunnen zijn ) bij een enkele controller in alle Views de active items bijvoorbeeld rood ( of ieder geval dezelfde kleur ) moeten zijn?

Want dat is feitenlijk waar we nu over discussieren. Bepaald de Controller of de View welke kleur een Active Item getekend word.

Ik ( en blijkbaar een hoop andere in dit topic ) vind dat dat een keuze van de View is en niet van de Controller. ( Behalve als de kleur een onderdeel is van je Model, in het geval van een Rode Ferari o.i.d., maar dan nog is het niet de controller die de kleur bepaald maar het model )

[.oisyn]

Verwijderd schreef op woensdag 15 juli 2009 @ 13:51:
[...]


Nee nee nee nee nee nee .

Ah. Dus stel je hebt wat gegevens, die weergegeven gaan worden in een tabel. Nu is het vaak gebruikelijk om de achtergrondkleur van de regels in de tabel om en om gekozen worden, zodat duidelijk is wat bij wat hoort. Als ik je goed begrijp vind jij dus dat de controller over de data heen moet lopen, waarbij hij bij elke regel de achtergrondkleur instelt, zodat die gebruikt kan worden voor de view? En wat heeft die informatie dan voor belang bij het genereren van een grafiekje ipv een tabelletje?

En dan kun je wel roepen dat we jou niet begrijpen, maar feitelijk begrijp jij ons niet. De discussie was er namelijk al voordat jij je erin mengde, en iedereen wist waarover gepraat werd (namelijk logica in de view, hoe simpel die ook mag zijn) .

En, nogmaals, het zou prettig zijn als je verschillende reacties gewoon in 1 post verwerkt ipv steeds nieuwe posts onder elkaar te plaatsen. Denk eraan dat je in het postscherm ook nog gewoon op de quote-knoppen kunt drukken die bij de reacties staan, waarop de quote-tekst automatisch op de cursorpositie in je post zal worden geplaatst

[ Voor 32% gewijzigd door .oisyn op 15-07-2009 14:11 ]

[Verwijderd]

Woy schreef op woensdag 15 juli 2009 @ 14:01:
@BroxTheMan: Maar vind jij dan dus dat ( neem even een lijst van items die eventueel active kunnen zijn ) bij een enkele controller in alle Views de active items bijvoorbeeld rood ( of ieder geval dezelfde kleur ) moeten zijn?

Want dat is feitenlijk waar we nu over discussieren. Bepaald de Controller of de View welke kleur een Active Item getekend word.

Ik ( en blijkbaar een hoop andere in dit topic ) vind dat dat een keuze van de View is en niet van de Controller. ( Behalve als de kleur een onderdeel is van je Model, in het geval van een Rode Ferari o.i.d., maar dan nog is het niet de controller die de kleur bepaald maar het model )

Nee, dat is nou juist het hele misverstand. Ik heb een voorbeeldje gegeven dat niet slim gekozen was en nu wordt er gedaan of dat het probleem is.

De controller kan in de bean kijken of ie active is. De controller meldt dan aan het bijbehorende element dat ie van inactive op active is gezet. Dit gaat bijvoorbeede door middel van de methode setActive. In setActive staat de kleur voor het actief zijn van het item al aangegeven. Indirect beslist de controler dus wat de kleur wordt. De view beslist dan niet. De view gebruikt alleen de kleur die ie in zijn eigen methode had staan (en dat is verwarrend, want iedereen hier noemt dat logica, ik noem dat het toepassen van iets wat ingesteld is)

[Herko_ter_Horst]

Beste Brox, je lijkt op die man die op de radio een melding hoort van een spookrijder op de weg waar hij rijdt en dan denkt: "Hoezo één spookrijder? Ik zie er wel 100!".

Ja, alle views/layouts moeten dezelfde informatie van de controller krijgen. En nee, "color=red" hoort daar NIET bij. "active=true" wel. Een specifieke view kan dan beslissen om active elementen in rood te tonen. Een andere view kan besluiten om alleen active=true elementen te tonen en active=false elementen weg te laten. De controller kan geen beslissingen nemen over welke weergave een view gaat kiezen, omdat de controller helemaal niet weet welke views er zijn en al helemaal niet hoe die zich gedragen.

De controller moet geen beslissingen gaan nemen die afhankelijk zijn van een specifieke view. Als de controller moet weten welke views er allemaal zijn, is er iets mis.

Om aan te sluiten bij jouw manager/typiste voorbeeld: het lijkt me stug dat de manager zich druk wil maken om hoe een brief moet worden opgemaakt, waar het adres op envelop moet en hoeveel postzegels er geplakt moeten worden. Dat is de taak van de typiste: die heeft daar voor doorgeleerd. De manager geeft alleen de inhoud van de brief en het adres van de geadresseerde aan de typiste.

[.oisyn]

Verwijderd schreef op woensdag 15 juli 2009 @ 14:11:
In setActive staat de kleur voor het actief zijn van het item al aangegeven.

Hoe bedoel je dat precies? Is het een parameter van die methode en wordt de kleur dus door de controller doorgegeven? Of bedoel je dat de view gewoon zijn eigen kleurstelling heeft, en alleen maar kijkt of het item active is of niet en op basis daarvan een kleur kiest?

[ Voor 4% gewijzigd door .oisyn op 15-07-2009 14:20 ]

[Janoz]

Verwijderd schreef op woensdag 15 juli 2009 @ 14:11:
De controller kan in de bean kijken of ie active is. De controller meldt dan aan het bijbehorende element dat ie van inactive op active is gezet. Dit gaat bijvoorbeede door middel van de methode setActive. In setActive staat de kleur voor het actief zijn van het item al aangegeven. Indirect beslist de controler dus wat de kleur wordt. De view beslist dan niet. De view gebruikt alleen de kleur die ie in zijn eigen methode had staan (en dat is verwarrend, want iedereen hier noemt dat logica, ik noem dat het toepassen van iets wat ingesteld is)

Het lijkt me absoluut niet de bedoeling dat de setActive methode zelf de kleur bepaald. De eerder aangehaalde huisstijl verandering zou dan betekenen dat je het model of de controler aan zou moeten passen.

De controler zet iets op active. Het model weet of het active is. De view weet dat active elementen bold zijn.

Tests als isActive, en keuzes die gemaakt worden op basis van de hoeveelheid items in een lijst vind ik logica. In eerdere voorbeelden heb je notabene zelf aangegeven dat specifieke kleuren toekennen wat jouw betreft in de controller thuis horen om maar te omzeilen dat er een if in de view kwam.

[Verwijderd]

.oisyn schreef op woensdag 15 juli 2009 @ 14:17:
[...]

Hoe bedoel je dat precies? Is het een parameter van die methode en wordt de kleur dus door de controller doorgegeven? Of bedoel je dat de view gewoon zijn eigen kleurstelling heeft, en alleen maar kijkt of het item active is of niet en op basis daarvan een kleur kiest?

Kijk tof, nu gaan we ergens heen . Nogmaals het voorbeeld dat ik gaf, maar dan aangepast:

code:

Controller:

if(state=="active")
view.setActive();

if(state=="inactive")
view.setInActive();

View

public void setActive(){
     //als ie active is zet dan de volgende instellingen 
      setColor(red);
      setFontStyle(bold); //bij wijze van want dit kan natuurlijk niet zo. 
}

public void setInActive(){
     //als ie inactive is zet dan de volgende instellingen 
      setColor(green);
      setFontStyle(small); //bij wijze van want dit kan natuurlijk niet zo. 
}

Zoals je ziet kun je dan ELKE View een set(In)Active()-methode geven, maar de beslissing welke kleur er wordt gebruikt is indirect een beslissing van de Controller, omdat de View nu niet meer beslist of ie hem rood of groen maakt. Die maakt hem gewoon rood of groen al naar gelang ie in de ene of de andere methode zit.

[Verwijderd]

Verwijderd schreef op woensdag 15 juli 2009 @ 14:38:
[...]


Kijk tof, nu gaan we ergens heen . Nogmaals het voorbeeld dat ik gaf, maar dan aangepast:

code:

Controller:

if(state=="active")
view.setActive();

if(state=="inactive")
view.setInActive();

View

public void setActive(){
     //als ie active is zet dan de volgende instellingen 
      setColor(red);
      setFontStyle(bold); //bij wijze van want dit kan natuurlijk niet zo. 
}

public void setInActive(){
     //als ie inactive is zet dan de volgende instellingen 
      setColor(green);
      setFontStyle(small); //bij wijze van want dit kan natuurlijk niet zo. 
}

Zoals je ziet kun je dan ELKE View een set(In)Active()-methode geven, maar de beslissing welke kleur er wordt gebruikt is indirect een beslissing van de Controller, omdat de View nu niet meer beslist of ie hem rood of groen maakt. Die maakt hem gewoon rood of groen al naar gelang ie in de ene of de andere methode zit.

Misschien dat hier een deel spraakverwarring vandaan komt, ik denk dat velen in het voorbeeld wat je hierboven geeft vinden dat een View wél beslist welke kleur die em maakt aangezien het uitgecodeerd is in de view.
Wat vind je van onderstaande constructie:

C#:

// In de Controller:

modelItem.IsActive = true;

// Event handler in view die geregistreerd is op het model:

private void OnModelItemActiveChanged(object sender, PropertyChanged args)
{
    if(((ModelItem)sender).IsActive)
    {
        setActive();
    } 
    else 
    {
        setInactive();
    }
}

Vind je dan ook niet dat een View of beslist welke kleur items moeten hebben (en alleen maar uitvoert)?

[kenneth]

Mooie potato/potato-discussie

[tonyisgaaf]

Verwijderd schreef op woensdag 15 juli 2009 @ 14:38:
[...]
Zoals je ziet kun je dan ELKE View een set(In)Active()-methode geven, maar de beslissing welke kleur er wordt gebruikt is indirect een beslissing van de Controller, omdat de View nu niet meer beslist of ie hem rood of groen maakt. Die maakt hem gewoon rood of groen al naar gelang ie in de ene of de andere methode zit.

Waarom heeft je View een property "active"? Dat lijkt me toch meer een property van een item met een bepaald Model. De View is toch niet de data, maar hetgeen wat bepaald hoe de data (items met verschillende achterliggende Modellen) gepresenteerd wordt?

[Verwijderd]

tonyisgaaf schreef op woensdag 15 juli 2009 @ 15:07:
[...]

Waarom heeft je View een property "active"? Dat lijkt me toch meer een property van een item met een bepaald Model. De View is toch niet de data, maar hetgeen wat bepaald hoe de data (items met verschillende achterliggende Modellen) gepresenteerd wordt?

Nee, geen property: een methode . Weer een slordigheidje van mij. De setter set hier dus geen attribuut

[.oisyn]

Verwijderd schreef op woensdag 15 juli 2009 @ 14:38:
[...]


Kijk tof, nu gaan we ergens heen . Nogmaals het voorbeeld dat ik gaf, maar dan aangepast:

Ok, feitelijk klopt de aanname van Janoz dus weldegelijk. Je lijkt moeite te hebben met het onderscheiden van semantiek en presentatie. Dat een item active is is iets semantisch. Dat daar een kleur bijhoort is iets dat alleen in de presentatie bestaat. De controller bepaalt niet de kleur. De view heeft logica om de kleur te bepalen afhankelijk van de status van een item. En of je dat nou doet door een kleur in de stellen in de update methode of de property pas op te vragen bij de uiteindelijke uitvoer is een implementatie-detail, maar het blijft logica. Je kunt vinden van niet, maar dan zit je er imho gewoon naast

Dat is waar deze hele discussie over ging, voordat jij je erin mengde - logica in de view. En als je dan een alternatieve mening presenteert is het niet zo gek dat iedereen de aanname maakt dat je denkt dat de logica van het bepalen van de kleur in de controller thuis hoort, ookal vind je dat eigenlijk niet. Alleen verschoof jij de focus van gevolg (de view doet iets op basis van de 'active' property van het item) naar oorzaak (het item is active), maar dat was helemaal niet de kern van de discussie, en dat veroorzaakte de verwarring

Overigens vind ik net als tonyisgaaf dat dat setActive() helemaal niet in je view thuis hoort. Het is gewoon een property van de klasse Item, dat uit het model komt. Tenzij setActive() een notifyer is uit het observer pattern, maar dan wordt ie dus niet aangeroepen door de controller maar door het model (de controller zal een setActive() doen op het Item in het model, waarna automatisch de setActive() notifyer van de view wordt aangeroepen).

kenneth schreef op woensdag 15 juli 2009 @ 15:03:
Mooie potato/potato-discussie

Behalve dan dat potato maar op 1 manier is uit te spreken, itt tomato

[ Voor 11% gewijzigd door .oisyn op 15-07-2009 15:26 ]

[Woy]

Verwijderd schreef op woensdag 15 juli 2009 @ 14:38:
[...]


Kijk tof, nu gaan we ergens heen . Nogmaals het voorbeeld dat ik gaf, maar dan aangepast:

code:

Controller:

if(state=="active")
view.setActive();

if(state=="inactive")
view.setInActive();

View

public void setActive(){
     //als ie active is zet dan de volgende instellingen 
      setColor(red);
      setFontStyle(bold); //bij wijze van want dit kan natuurlijk niet zo. 
}

public void setInActive(){
     //als ie inactive is zet dan de volgende instellingen 
      setColor(green);
      setFontStyle(small); //bij wijze van want dit kan natuurlijk niet zo. 
}

Zoals je ziet kun je dan ELKE View een set(In)Active()-methode geven, maar de beslissing welke kleur er wordt gebruikt is indirect een beslissing van de Controller, omdat de View nu niet meer beslist of ie hem rood of groen maakt. Die maakt hem gewoon rood of groen al naar gelang ie in de ene of de andere methode zit.

In deze code laat je toch ook de View bepalen welke kleur er getekend word? Hoe vind jij dat de Controller in deze code de kleur bepaald?

Verwijderd schreef op woensdag 15 juli 2009 @ 12:11:
[...]
De controller zegt: he GreenViewNotice, wil jij voor mij even deze bean weergeven.

Ja daar zijn de meeste het hier volgens mij wel over eens. Er word over gevallen dat jij beweert ( of lijkt te beweren ) dat de controller de kleur bepaald. De GreenViewNotice was een slecht voorbeeld van mij, maar laten we het op een TableView en ChartView hebben o.i.d. Het is de TableView die bepaalt welke kleur een row is ( en uberhaupt dat er Rows zijn ). De Controller krijgt van een Factory de juiste View, en geeft daaraan het Model door. De View gaat daarna bepalen wat de output moet zijn.

[ Voor 23% gewijzigd door Woy op 15-07-2009 15:23 ]

[Verwijderd]

Woy schreef op woensdag 15 juli 2009 @ 15:18:
[...]

In deze code laat je toch ook de View bepalen welke kleur er getekend word? Hoe vind jij dat de Controller in deze code de kleur bepaald?

Dat zit m in het if-statement, dat niet in de View maar in de Controller staat, waardoor de View niet de keuze maakt tussen rood en groen, maar groen in die situatie hoe dan ook gebruikt.

Maar goed, zie post boven jou. We zijn wel zo'n beetje uit het misverstand. 2 verschillende interpretaties van beslissen.

Ok, feitelijk klopt de aanname van Janoz dus weldegelijk. Je lijkt moeite te hebben met het onderscheiden van semantiek en presentatie. Dat een item active is is iets semantisch. Dat daar een kleur bijhoort is iets dat alleen in de presentatie bestaat. De controller bepaalt niet de kleur.

Nou niet helemaal. Het probleem zit hem waarschijnlijk meer in dat ik alleen een if/else statement als een beslissing zie en het dus ook geinterpreteerd kan worden als het toekennen van een waarde.

[ Voor 31% gewijzigd door Verwijderd op 15-07-2009 15:37 ]

[Woy]

Verwijderd schreef op woensdag 15 juli 2009 @ 15:30:
[...]


Dat zit m in het if-statement, dat niet in de View maar in de Controller staat, waardoor de View niet de keuze maakt tussen rood en groen, maar groen in die situatie hoe dan ook gebruikt.

Nee de controller bepaalt in jouw code of het object Active of Inactive is, niet of hij rood of groen is. Je View zou er immers voor kunnen kiezen om het precies andersom te renderen.

Nou niet helemaal. Het probleem zit hem waarschijnlijk meer in dat ik alleen een if/else statement als een beslissing zie en het dus ook geinterpreteerd kan worden als het toekennen van een waarde.

Dan zou ik het zelf toch anders oplossen, maar de plek van het kiezen van de kleur zijn we het dan over eens

[Jaap-Jan]

Verwijderd schreef op woensdag 15 juli 2009 @ 15:30:
[...]

Maar goed, zie post boven jou. We zijn wel zo'n beetje uit het misverstand. 2 verschillende interpretaties van beslissen.

Uiteindelijk komt het dus toch hier op neer:

Herko_ter_Horst schreef op woensdag 15 juli 2009 @ 14:14:
Beste Brox, je lijkt op die man die op de radio een melding hoort van een spookrijder op de weg waar hij rijdt en dan denkt: "Hoezo één spookrijder? Ik zie er wel 100!".

Ik bedoel, als minstens 10 personen je proberen te overtuigen, lijkt het me toch dat je er een verkeerde definitie op nahoudt.

[tonyisgaaf]

Verwijderd schreef op woensdag 15 juli 2009 @ 15:30:
[...]


Dat zit m in het if-statement, dat niet in de View maar in de Controller staat, waardoor de View niet de keuze maakt tussen rood en groen, maar groen in die situatie hoe dan ook gebruikt.

Maar goed, zie post boven jou. We zijn wel zo'n beetje uit het misverstand. 2 verschillende interpretaties van beslissen.


[...]


Nou niet helemaal. Het probleem zit hem waarschijnlijk meer in dat ik alleen een if/else statement als een beslissing zie en het dus ook geinterpreteerd kan worden als het toekennen van een waarde.

Ik snap er nog steeds geen r**t van, je doet net alsof elke View een aantal 'global' properties heeft en dat dat voldoende is om een bak data (een verzameling items met achterliggende Modellen) te formatten.
De properties (of methods, get/setters, etc.) van een View zeggen toch alleen iets over de View zelf? Ik kan me inderdaad voorstellen dat je een ColouredView met een backgroundColour property hebt. Of misschien zelfs een View met een "active" property, die bijvoorbeeld bepaalt of er wel/niet een grijze overlay over de View-content wordt projecteerd. Of zelfs een "activeTableRowBackgroundColour" property.

Dus controle vanuit je Controller over de eigenschappen van de View lijkt me prima, maar je kan toch niet de Controller de View via een setter vertellen dat de eigenschappen van een item zijn veranderd?

Jaap-Jan schreef op woensdag 15 juli 2009 @ 15:51:
[...]
Ik bedoel, als minstens 10 personen je proberen te overtuigen, lijkt het me toch dat je er een verkeerde definitie op nahoudt.

Hoe denk jij dat ons huidige gedachtegoed tot stand is gekomen, door het al een paar miljoen jaar met elkaar eens te zijn? Veel plezier met het meerennen met de massa.
Misschien heeft BroxTheMan wel gelijk, maar heeft hij dat nog niet kunnen bewijzen. Misschien dan he

[ Voor 15% gewijzigd door tonyisgaaf op 15-07-2009 16:01 ]

[Jaap-Jan]

tonyisgaaf schreef op woensdag 15 juli 2009 @ 15:52:
(..)

Hoe denk jij dat ons huidige gedachtegoed tot stand is gekomen, door het al een paar miljoen jaar met elkaar eens te zijn? Veel plezier met het meerennen met de massa.
Misschien heeft BroxTheMan wel gelijk, maar heeft hij dat nog niet kunnen bewijzen. Misschien dan he

Zo bedoel ik dat dus niet. Zie ook het stuk van hem wat ik quote, daarin wil hij een einde breien aan de discussie. Uiteindelijk heb ik (op dit moment ten minste) geen argumenten meer zien liggen, dus dan lijkt het me beter dat hij zich daarin aanpast, omdat hij anders wellicht ook raar wordt aangekeken door andere programmeurs als hij in een soortgelijke situatie terecht komt.

[Verwijderd]

tonyisgaaf schreef op woensdag 15 juli 2009 @ 15:52:

Misschien heeft BroxTheMan wel gelijk, maar heeft hij dat nog niet kunnen bewijzen. Misschien dan he

Als het al zo is, dan duurt het minimaal 30 jaar voor ik t wel kan

Jaap-Jan schreef op woensdag 15 juli 2009 @ 17:38:
[...]
Zo bedoel ik dat dus niet. Zie ook het stuk van hem wat ik quote, daarin wil hij een einde breien aan de discussie. Uiteindelijk heb ik (op dit moment ten minste) geen argumenten meer zien liggen, dus dan lijkt het me beter dat hij zich daarin aanpast, omdat hij anders wellicht ook raar wordt aangekeken door andere programmeurs als hij in een soortgelijke situatie terecht komt.

Weet jij wat ik pas raar vind? Dat je uitgaat van maar 1 weg naar Rome terwijl er meerdere zijn. Dat vind ik raar. Dat je genoegen neemt met slechts 1 interpretatie van MVC. Want dat is het. MVC is er in vele vormen en maten.

Zoals ik al zei: een Design Pattern is de kern van de oplossing van een programmeerprobleem. Dat veel mensen 1 van de varianten die die kern bevatten als de ware beschouwen zegt niet meteen dat andere varianten idioot zijn .

[MBV]

Er zijn veel varianten die je met een beetje goede wil MVC kan noemen, maar jouw variant valt daar gewoon buiten*. Volgens mij verwar je een theme namelijk met een View, en daarbij geef je een theme ook nog eens heel weinig mogelijkheden om zelf iets te doen.

De kracht van Design Patterns is nu juist dat als ik 'observer' roep, jij meteen weet waar ik het over heb: een vocabulaire. Dat heeft alleen waarde als je min-of-meer dezelfde betekenis eraan koppelt. Als jij een klein beetje miezeren 'onweer' noemt, als verkorting van 'onprettig weer', dan is dat ook erg lastig in de communicatie, toch?

* zeker als je Design Patterns als vocabulaire gebruikt blijkt dat het geval: volgens mij is het inmiddels 30 tegen 1.
_{[disclaimer]niet het hele topic gelezen[/disclaimer]}

[ Voor 13% gewijzigd door MBV op 16-07-2009 00:14 ]

[prototype]

Je noemt nu wel heel vaak abstract factory, maar die bepaalt WELKE factory gebruikt moet worden, en die op zijn beurt welke view, maar niet direct HOE deze precies eruit moet zien. Dat HOE gebeurd in de view zelf, de abstract factory instantiate gewoon een concrete factory die op zijn beurt weer de juiste elementen instantiate. Afgezien van dit CREEEREN (het is immers een CREATIONAL PATTERN), wordt alles gewoon door de concrete objecten bepaald. En hier kan gewoon prima presentation logic in, sterker nog, dat wordt zelfs van harte aangeraden omdat je hier (als je dit in de controller zou doen) te maken hebt met een ABSTRACT factory. Ga dan vooral NIET CONCRETE informatie meegeven zoals color=red aan die abstract factory, want de concrete factory/concrete view heeft daar gewoon het laatste woord over. Dat is dan ook de kracht van die pattern en je laat aan mij iig zien dat je die niet goed beheerst.

Volgens mij zit je fout in denken ook gewoon in het niet kunnen onderscheiden van semantiek van weergave. In de controller kan je met abstract factory op semantische wijze je button uitkiezen (denk b.v. aan een tristate button of twostate button), maar de daadwerkelijke weergave van die tristate of die twostate laat je over aan de concrete class die geinstantiate wordt door de concrete factory. Of je daarbij nou een groene of rode kleur bij gebruikt, dat is een kwestie die afgehandeld dient te worden in de concrete view class. Die is simpelweg om de semantiek uit te beelden.

Je beweert tot slot in je laatste reactie dat er meerdere wegen zijn die tot rome leiden maar je struikelt enorm hard op de mijne (die gewoon die van GoF is en de 30 anderen die hier het niet met je mee eens zijn). Contradictie? Goed, ik ga weer verder met m'n google tech talk voorbereiden aangezien we je niet echt kunnen overtuigen denk ik, which is fine.

[ACM]

Zijn jullie nou niet gewoon heel lang bezig met een discussie of de eerste variant zo veel mogelijk moet worden aangehouden, of dat de tweede ook goed kan zijn?

code:

Controller1 {
 doIets() {
   for(Element e : elements) {
    (e.isActive() ? view.addActiveElement(e) : view.addElement(e);
   }
 }
}

vs

Controller2 {
 doIets() {
   for(Element e : elements) {
    view.addElement(e);
   }
 }
}

View2 {
 // Deze kijkt, als ie geinteresseerd is in de activeness van e wel in addElement oid of e.isActive waar is.
}

Imho is het enige juiste antwoord daarop "dat hangt van de situatie af". Sowieso is een active-status zelf ook weer een dubieus voorbeeld omdat het van alles kan beteken en meestal ook binnen de Controller andere betekenis kan hebben.

Het voorbeeld dat een view bepaald welke elementen ie wel en niet toont is wat gevaarlijk en zou ik zelf niet zo gauw aan de view overlaten. Maar het voorbeeld dat stelt dat een view zelf bepaald of ie een odd-even patroon in tabellen heeft is iets waar de controller imho weinig mee te maken heeft.
Zelf ben ik dan nog van mening dat je sterk betrokken handelingen zo veel mogelijk bij elkaar moet zien te houden, omdat je anders het overzicht snel kwijt raakt op de plekken waar je het anders uit elkaar trekt.

Als we in dit topic kijken, dan is de keus dat mijn (en die van andere crewleden) nick een ander kleurtje moet krijgen die van de view. Simpelweg omdat dat kleurtje verder eigenlijk niks betekent. Het feit dat ik een van die anderen ben, wordt uiteraard wel vanuit de model-laag naarboven meegegeven. Maar het gaat imho veel te ver om dan een controller te laten besluiten dat mijn nick anders moet worden getoond dan die van anderen. In de rss-variant van de topicview is het bijvoorbeeld helemaal niet relevant dat mijn nick anders kan worden weergegeven.
Dat wordt overigens helemaal duidelijk als je erg veel data moet zien weer te geven, waarbij je controller ook nog eens belast wordt met een heleboel andere keuzes (rechtenchecks, welke data op te halen, etc).

[ Voor 3% gewijzigd door ACM op 16-07-2009 12:29 ]

[.oisyn]

ACM schreef op donderdag 16 juli 2009 @ 12:27:
Zijn jullie nou niet gewoon heel lang bezig...

Nou, nee, gezien het feit dat maar pakweg 5 posts gaan over wat jij nu probeert aan te stippen . De kern van de discussie was logica in de view. Pas later is er in detail getreden over dat voorbeeld dat gegeven is.

[roeleboel]

Als ik een steentje mag bijdragen:

Stel: je hebt een view die pdf's genereert.

Ga je dan:

• voor ieder papierformaat een aparte view schrijven (de tekst/uitlijning/... komt immers anders op een a4 dan op een a3, tabellen passen al dan niet gedraait op een blad, ... etc)
• 1 view maken die beslissingen voor layout neemt aan de hand van het papierformaat? (en dan bedoel ik uiteraard niet 1 monster-view met voor ieder papierformaat een aparte functie die alles afhandelt)

Ik zou 'logica' in de view steken die beslist aan de hand van het gekozen papierformaat (ik zou niet graag de programmeur zijn die voor ieder papierformaat dat bestaat in deze wereld een aparte view moet schrijven).
Dus: enorm veel 'if', 'for', 'while', ...

Wat is jullie mening hierover?

[Verwijderd]

prototype schreef op donderdag 16 juli 2009 @ 01:38:
Je noemt nu wel heel vaak abstract factory, maar die bepaalt WELKE factory gebruikt moet worden, en die op zijn beurt welke view, maar niet direct HOE deze precies eruit moet zien. Dat HOE gebeurd in de view zelf, de abstract factory instantiate gewoon een concrete factory die op zijn beurt weer de juiste elementen instantiate.

Dat klopt. Dat klopt als n bus. Ik had ook meer dit voor ogen bij het maken van een keuze:

Stel dat de kleur van View1 groen is. Van View2 rood en italic. En van View3 pimpelpaars met een plaatje er bij. Kies je dan in een eerder stadium voor om bijvoorbeeld View2 weer te geven, of kies je dat in de View zelf pas? Als je in de Controller al hebt gekozen voor View2, dan bepaalt View2 dat de kleur rood is en het text type italic, maar dan kan je kleur op dat moment zelf niet meer groen worden. Wat heb je daar als voordeel mee: je bespaart je heel veel statements in de View. Wil je een designer laten werken, dan heb je toch al heel gauw dat ze geen flauw benul hebben van wat ze daar mee aan moeten.

En valt de concrete Factory of de concrete Builder dan in de View of in de Controller?

M.i. kan je met bijvoorbeeld een Builder prima User Interfaces maken, zonder dat je ook maar een enkele loop of if-statement in je View stopt

_{ik voel dat ik vandaag in een genuanceerdere bui ben dan gisteren}

[ Voor 3% gewijzigd door Verwijderd op 16-07-2009 15:20 ]

[Herko_ter_Horst]

De controller kiest de view? Het wordt steeds gekker... De applicatie kiest welke view op welk moment getoond wordt, niet de controller. De controller hoort de views niet te kennen.

[Woy]

Verwijderd schreef op donderdag 16 juli 2009 @ 15:15:
[...]
Dat klopt. Dat klopt als n bus. Ik had ook meer dit voor ogen bij het maken van een keuze:

Stel dat de kleur van View1 groen is. Van View2 rood en italic. En van View3 pimpelpaars met een plaatje er bij. Kies je dan in een eerder stadium voor om bijvoorbeeld View2 weer te geven, of kies je dat in de View zelf pas? Als je in de Controller al hebt gekozen voor View2, dan bepaalt View2 dat de kleur rood is en het text type italic, maar dan kan je kleur op dat moment zelf niet meer groen worden.

Ok, dat is zo ongeveer hetzelfde als de andere mensen hier zeggen.

M.i. kan je met bijvoorbeeld een Builder prima User Interfaces maken, zonder dat je ook maar een enkele loop of if-statement in je View stopt

Daar ben ik het dan niet mee eens. Je zult IMHO bijna altijd loopjes en conditional statements in je View moeten hebben.

Stel je hebt een lijst met items, dan krijg je in je View iets als het volgende

C#:

public void Render()
{
    foreach (Item item in items)
    {
        if(item.Value < 0)
        {
            RenderItem(item, Color.Red);
        }
        else
        {
            RenderItem(item, Color.Green);
        }
    }
}

Het is niet voor niks dat je bijvoorbeeld ook in Smarty ( Waar de discussie mee begon ) ook loops en conditional statements hebt.

[.oisyn]

Herko_ter_Horst schreef op donderdag 16 juli 2009 @ 15:20:
De controller kiest de view? Het wordt steeds gekker... De applicatie kiest welke view op welk moment getoond wordt, niet de controller. De controller hoort de views niet te kennen.

Wellicht is dat dezelfde semantische misinterpretatie als eerst. De controller instantiate een view bij een factory en geeft daarbij wat properties door. De factory kiest de view adhv die properties. Brox zal nu wel vinden dat de controller de view kiest, net als dat ie eerst vond dat de controller de kleur bepaalt van een active item

[ Voor 33% gewijzigd door .oisyn op 16-07-2009 15:29 ]

[Gomez12]

Verwijderd schreef op donderdag 16 juli 2009 @ 15:15:
[...]
M.i. kan je met bijvoorbeeld een Builder prima User Interfaces maken, zonder dat je ook maar een enkele loop of if-statement in je View stopt

Tja heel simpel gezegd, waar wil jij bepalen hoe een tabel weergegeven moet worden? Bij een webview kan hij doorlopen ongeacht lengte / positie, bij een pdf view is het afhankelijk van de lengte van de tabel / positie op de pagina hoe hij gerenderd moet worden ( beginnend op huidige pagina en doorlopend op volgende pagina of compleet op deze pagina of compleet op volgende pagina ).

Of iets simpels wat al eerder aangestipt is, een tabel met gekleurde balken ( even / oneven rijen andere achtergrondkleur ). Ergens moet je logica stoppen om te bepalen of je op een even of op een oneven rij zit ( en niets behalve je view weet hoeveel cellen er in een rij passen, dus niets behalve je view weet of de huidige cel op een even of een oneven rij zit ( bij een fluid layout ) )

Dit is gewoon presentation logica die ik nergens anders dan in de view zie.

[Cartman!]

Ik snap de insteek van BroxTheMan ook echt totaal niet. Naar mijn idee werkt MVC als volgt:

code:

Controller:
- haal op wat je wilt uit je model
- stop die data in de view

View:
- geef data weer

In html is dat bijv. in een tabel met om en om gekleurde rijen en voor een RSS feed zet je er de juiste XML tags omheen. Wat die SetColor/Active methods doen in je controller gaat echt langs me heen, daar heeft je controller geen moer mee te maken, die geeft alleen maar shit door aan je view

[prototype]

Verwijderd schreef op woensdag 15 juli 2009 @ 14:38:
[...]


Kijk tof, nu gaan we ergens heen . Nogmaals het voorbeeld dat ik gaf, maar dan aangepast:

code:

Controller:

if(state=="active")
view.setActive();

if(state=="inactive")
view.setInActive();

View

public void setActive(){
     //als ie active is zet dan de volgende instellingen 
      setColor(red);
      setFontStyle(bold); //bij wijze van want dit kan natuurlijk niet zo. 
}

public void setInActive(){
     //als ie inactive is zet dan de volgende instellingen 
      setColor(green);
      setFontStyle(small); //bij wijze van want dit kan natuurlijk niet zo. 
}

Zoals je ziet kun je dan ELKE View een set(In)Active()-methode geven, maar de beslissing welke kleur er wordt gebruikt is indirect een beslissing van de Controller, omdat de View nu niet meer beslist of ie hem rood of groen maakt. Die maakt hem gewoon rood of groen al naar gelang ie in de ene of de andere methode zit.

Kijk, het probleem met de aanpak die je voorstelt in je vorige reacties is dat jij nu al expliciet dicteert dat er een structuur in moet zitten in de views, en dat is meteen een heikel punt. Dat blijkt helemaal in je setActive verhaal, waarbij jouw controller nu dicteert dat de view die interface ook MOET implementeren. De controller roept immers op een view setActive aan. Hiermee structureer jij je view al en heeft je controller daar kennis van en dat is niet flexibel! (Daar was de observer pattern ook voor ingezet om juist principle of least knowledge te introduceren). Stel dat jij nu b.v. een view hebt die NIKS doet met setActive, dan moet je alsnog die methode in jouw view implementeren omdat jouw controller ervanuit gaat dat die methode er hoe dan ook moet zijn. Dat is dan een lege methode, lekker, en het aantal minimale methodes wordt dan eigenlijk bepaald door de grootste view. Het alternatief is dan zoals ik al zei, om een andere controller te schrijven die niet setActive aanroept en een bijbehorende view. Goh, lekker , maar niet echt.

De slimme mannen van GoF hadden dan ook bedacht om via observer pattern de view dit soort dingen te laten bepalen... en daar gaan dus presentation logics bij komen kijken om die keuzes te maken. Dan kom jij er weer aan met je complexity cycles, maar in de praktijk zeggen die metrics echt heel weinig (spookrijdersverhaal), omdat je er ook tegenover kan zeggen dat mijn c.q. de GoF oplossing meer code localiteit biedt mbt waar beslissingen gebeuren. Bij jou zou je tussen de controller en view files moeten switchen om te kijken wat er nou precies gebeurd mbt setActive e.d en waarom die zo aangeroepen worden. Jij verdeelt eigenlijk jouw callstack depth in meerdere files en ik kies ervoor om het lokaal te bepalen met als voordeel dat mijn aanpak dus meer flexibiliteit ook biedt (en imo makkelijker onderhoudbaar door de lokaliteit) omdat het de view is die bepaalt. Mijn views kunnen via deze weg zo gek en divers van elkaar zijn als je maar wil zonder dat ik lege methoden hoef te implementeren voor jouw controller die uitgaat van methodes als setActive op de view. En via deze weg kan mijn cycle complexity lager uitvallen omdat ik misschien helemaal niks doe met bepaalde model data.

Verwijderd schreef op donderdag 16 juli 2009 @ 15:15:
[...]


Dat klopt. Dat klopt als n bus. Ik had ook meer dit voor ogen bij het maken van een keuze:

Stel dat de kleur van View1 groen is. Van View2 rood en italic. En van View3 pimpelpaars met een plaatje er bij. Kies je dan in een eerder stadium voor om bijvoorbeeld View2 weer te geven, of kies je dat in de View zelf pas? Als je in de Controller al hebt gekozen voor View2, dan bepaalt View2 dat de kleur rood is en het text type italic, maar dan kan je kleur op dat moment zelf niet meer groen worden. Wat heb je daar als voordeel mee: je bespaart je heel veel statements in de View. Wil je een designer laten werken, dan heb je toch al heel gauw dat ze geen flauw benul hebben van wat ze daar mee aan moeten.

En valt de concrete Factory of de concrete Builder dan in de View of in de Controller?

M.i. kan je met bijvoorbeeld een Builder prima User Interfaces maken, zonder dat je ook maar een enkele loop of if-statement in je View stopt

_{ik voel dat ik vandaag in een genuanceerdere bui ben dan gisteren}

Hier kom ik morgen misschien nog wel even op terug, valt nog wel wat op aan te merken maar het is laat/vroeg

[supakeen]

.oisyn schreef op zondag 12 juli 2009 @ 23:34:
[...]

De <? is de shorttag voor <?php, maar <?php= is geen shorttag. En die verdwijnt dact ik ook niet. De kern van m'n post was natuurlijk het weghalen van de echo en de trailing ;, niet het omzeilen van de 'php' in de tag
Woeps, <?php= wordt (nog) niet ondersteund. Ok, I stand corrected.


[...]

Alsjeblieft niet. Ik bespaar m'n gebruikers liever de lelijke PHP error meldingen.

Daarom heb je natuurlijk foutmeldingen wel aanstaan op je development server en niet op je productie server, daar toon je gewoon een ‘nette’ 500.

En je gebruik van PHP shorttags, deze zijn deprecated vanaf PHP6.

[Jaap-Jan]

Zijn ze deprecated, of is alleen short_open_tag in php.ini deprecated? Rasmus Lerdorf zei op 14 april 2009 zelf dit (in antwoord op iemand die pleit voor het behouden van de <?= shorttag):

quote: http://www.mail-archive.c...sts.php.net/msg41853.html

Which is one of the reasons we decided not to remove them in PHP 6.

-Rasmus

Of is er recentelijk iets veranderd? Ik kan geen recenter spul vinden, afgezien van een bug report.

Ikzelf zou het belachelijk vinden als ze ze zouden afschaffen. PHP is een template- taal voor html en daarvoor is <?= een korte manier om een variabele te kunnen echo'en. De enige reden dat wordt ontmoedigd om ze te gebruiken, is omdat ze optioneel zijn. Van mij mag dat default aan worden zodat het veilig is om ze te gebruiken. Als je xml wilt outputten, gebruik je ook maar <?= '<?xml....>' ?>, omdat het gebruik van xml niet belangrijker is dan het gebruik als template-taal voor html.

[ Voor 52% gewijzigd door Jaap-Jan op 17-07-2009 18:11 ]