PDF software MVC opzet

[djluc]

Ik zit met een simpele vraag maar hij ligt toch wat lastiger dan gedacht:

We ontwikkelen software die PDF documenten maakt. Er is een interface waar de user wat instelt en op basis daarvan worden verschillende onderdelen in de PDF gezet.

Elk onderdeel is een Model (nieuwsitem, statische text, etc).

Er zijn 2 mogelijke vormen van output: html en pdf.

Wat moet de PDF worden: Een view of een model? Het is een vorm van opslag (de PDF wordt op de server opgeslagen) dus met die redenatie hebben we nu een model. Daarin zit dus een functie: addToPDF welke de gegevens toevoegt aan de PDF.

Aan de andere kant kan het ook een view zijn? Het is een output vorm. Dan zou ik echter vanuit die view weer een save moeten aanvragen?

[Kalentum]

Misschien beide: zowel een model als een view. Het samenstellen van de pdf (dus de gebruiker laten selecteren welke informatie erin moet) kun je afhandelen in een aparte controller + model (zeker als die pdf's nog een keer aangemaakt moeten kunnen worden), het genereren van de eigenlijke pdf kan via een view.

[djluc]

Ok, maar dan krijg ik dus in mijn view code als:

PHP:

 $this->p = null;
      
    try {
      $this->p = new PDFlib();
      $this->p->set_parameter("license", "xxxxx-xxxxx-xxxxxx-xxxxx-xxxxx");
      $this->p->set_parameter("errorpolicy", "return"); // check return values of load_font() etc.
      $this->p->set_parameter("hypertextencoding", "winansi"); // used to prevent problems with japanese systems
      
      /*  open new PDF file; insert a file name to create the PDF on disk */
      if ($this->p->begin_document("", "") == 0) {
        die("Error: " . $this->p->get_errmsg());
      }
      
      $this->p->set_info("Creator", "TenToday");

Op één of andere manier heb ik niet het gevoel dat dit mooi is. Maargoed, ik ben dus hele schone views gewend met alleen HTML en variabelen daarin.

Die models blijven sowieso inderdaad om de gegevens op te halen zoals niewsitems. Maar wellicht dat die volgende functie wellicht weg kan ja:

PHP:

  public function addObjectToPDF(&$p, $left, $bottom, $width, $height) {
    
    //$p->setfont($font1, 16.0);
    $p->set_text_pos($left, $bottom);
    $p->show($this->currentRecord['value']);
  }

Dit staat dus nu in het model StaticText bijvoorbeeld wat dus een tekst uit de database haalt. Dit zou dan een aparte view moeten worden die we kunnen renderen?

[Deikke]

Normaalweg intepreteer ik alleen de gegevens laag als 'models', en daarmee praat ik vanuit de controller. Een pdf bewaart geen gegevens maar is gewoon een uitdraai van deze gegevens, net zoals html uitvoer. Dat je de geexporteerde gegvens lokaal opslaat in plaats van verstuurd doet hiet niks aan af. Het is gewoon een View, maar je stuurt de uitvoer nu ergens anders heen.

Ik zie een view trouwens ook meer als een template. De controller geeft de benodigde gegevens aan een bepaalde view, de view wordt uitgevoerd en de uitvoer wordt door de controller naar de juiste uitvoer locatie geleid.

[Kalentum]

djluc schreef op zondag 22 maart 2009 @ 17:19:
Ok, maar dan krijg ik dus in mijn view code als:

PHP:

...

Op één of andere manier heb ik niet het gevoel dat dit mooi is. Maargoed, ik ben dus hele schone views gewend met alleen HTML en variabelen daarin.

Dat lijkt vies maar dat komt omdat html (en xml) gewoon tekst is en PDF niet. Je doet in de view gewoon wat nodig is om een geldig pdf document te krijgen, net zoals je in de view ook dingen moet doen om een geldig HTML document te krijgen.

[marty]

djluc schreef op zondag 22 maart 2009 @ 16:47:
Er zijn 2 mogelijke vormen van output: html en pdf.

Wat moet de PDF worden: Een view of een model?

Ik denk dat je zelf al antwoord op je vraag heb gegeven. HTML beschouw je dus altijd als view.... het feit dat je hier een ander document van maakt (PDF) verandert niets aan wat het is. Al zou je er een PNG van maken ... het blijft gewoon een view.

[djluc]

Ok duidelijk, gevoel en logisch nadenken zit nog weleens verschil in

[djluc]

Het was even een klus maar dit is inderdaad een stuk mooiere methode. Nu ik er mee werk zie ik inderdaad dat het een stuk logischer is.

Een andere dubieuze is afbeeldingen resizen. Weer zo'n dilemma, gek word ik er van! Het is data bewerking maar aan de andere keuze bepaald de view hoe. De view krijgt de afbeeldingsformaten echter weer vanuit een model. Kortom: Vaag!

[BCC]

Eeh, dat is toch duidelijk een controller feature?

[djluc]

Tsja, aan de ene kant wel, aan de andere kant weet een controller vaak niet welk formaat een afbeelding gaat worden. Dat is iets van de presentatie?

[BCC]

? Waar doe je dat nu dan? De controller hoort aan de view aan te geven wat hij moet "tekenen".

[Verwijderd]

Model slaat maten op.
Controler controleerd of maten legaal zijn.
View tekend de opgegeven maten.

Model geeft aan dat er iets gewijzigd is.
Controler vangt deze signalen op en geeft deze door aan de view.
View tekend de wijzigingen.

Met deze regels kom ik meestel wel tot een nette oplossing.

[Freeaqingme]

Hoewel het niet direct onderdeel uitmaakt van het MVC pattern, zou ik hier een view helper voor gebruiken.

[frickY]

Lijkt me een view.
Dat je output naar disk in plaats van een beeldscherm doet hier niets aan af.

[djluc]

Een bedankje hier is wel op z'n plaats denk ik! Inmiddels zit de software strak in elkaar en hebben we door de opsplitsing mvc op de bovenstaande manier een hele nette oplossing. De code leest nu inderdaad helemaal logisch en is overzichtelijk.

Het afbeeldingen verhaal is op dit moment in de controller geïmplementeerd. Deze krijgt een url met het origineel van het model. Afhankelijk van de maten die ingesteld zijn in het models bepaald de controller of we gaan resizen. Die plaatst stuurt dan de juiste url naar de view.

[BCC]

Plaatjes

[djluc]

Haha, ik zal zodra het ook interface technisch mooi is er mee aan de slag gaan! Op dit moment ben ik bezig om daar wat moois van te maken.

[BlackHawkDesign]

Ik kwam dit topic toevallig tegen en afgelopen weken heb ik me verdiept in het MVC pattern. Wat ik veel uit jullie verhalen opmaak is dat jullie steeds de controller voor de view inzetten om te praten met de model. Echter kan een view ook direct met het model praten, om de data die het model levert, op het scherm te presenteren.

De controller dient met name om de user input af te handelen. Het is dus niet goor om code als, getArticles, wat een functie van je model is, aan te roepen in je view en deze vervolgens de data omzet in een presentatie.

De MVC pattern is namelijk geen top down structuur.

Ik wilde dit nog even toevoegen aan de discussie

[djluc]

Interessante kijk! Ok, dus je maakt eigenlijk in je views gewoon instances aan van je models en vraagt daar informatie op?

[BCC]

Het ligt allemaal aan de situatie.
Het uitgangspunt is olgens mij altijd dat je zo min mogelijk logica in de view wil.

Stel je hebt een persoon model waarvan je de naam wil weergeven.
Optie 1

code:

controller:
person = Person.find(:first)
@full_name = person.full_name

view:
<%= h @full_name %>

Optie 2

code:

controller:
@person = Person.find(:first)

view:
<%= h @person.full_name %>

Ik vind zelf Optie 2 nog wel acceptabel, maar als je dit gaat doen:

code:

controller:
@person = Person.find(:first)

view:
<% @person.friends.each do |friend| %>
  <%= h friend.full_name %>
<% end %>

Vind ik zelf dat er al te veel logica in de view zit.

code:

controller:
@person = Person.find(:first)
@friends = @person.friends

view:
<% @friends.each do |friend| %>
  <%= h friend.full_name %>
<% end %>

Maar dat is denk ik vooral persoonlijk voorkeur. Een designpattern is een middel, geen doel.

[ Voor 5% gewijzigd door BCC op 01-04-2009 19:08 ]

[djluc]

Maar dat is toch niet het punt wat gemaakt wordt?

BlackHawk stelt dit:

code:

view:
@friends=Person.find(:first)
<% @friends.each do |friend| %>
  <%= h friend.full_name %>
<% end %>

[BCC]

Dat vind ik dus al veel te ver gaan Dat hoort IMHO in de controller.

[djluc]

Het scheelt wel een method in de controller die eigenlijk alleen maar data doorschuift. Kortom: Het kan ook wel voordelen hebben? Iemand hiermee ervaring?

[BCC]

Ja, ik View gaat over je output. Controller over het vergaren van Data. .find moet dus in de controller en niet in de view.

[djluc]

Wanneer gebruik je dan wel de directe verbinding tussen view en model? Het is een onderdeel van het idee als je bijvoorbeeld de afbeelding op deze pagina bekijkt:
Wikipedia: Model�view�controller

[BCC]

Simpele zaken, zoals person.name , person.gender etc.

[BlackHawkDesign]

djluc begreep me inderdaad heel goed, zo bedoelde ik het inderdaad.

Op Wikipedia staat ook netjes:

quote: wiki

A view uses the model indirectly to generate an appropriate user interface (for example, the view lists the shopping cart's contents). The view gets its own data from the model. The model and controller have no direct knowledge of the view.

Anders krijg je weer een top down structuur en volgens mij tentamen Design patterns is het MVC geen top down structuur, maar zoals alle plaatjes aangeven.

quote: BCC

Maar dat is denk ik vooral persoonlijk voorkeur. Een designpattern is een middel, geen doel.

Dat is helemaal correct, echter is jou implementatie van het MVC niet geheel correct. Ik keur hem zeker niet af, maar ik wilde dat wel even zeggen

quote: djluc

Het scheelt wel een method in de controller die eigenlijk alleen maar data doorschuift. Kortom: Het kan ook wel voordelen hebben? Iemand hiermee ervaring?

Dat is idd het voordeel, anders ga je extra dingen doen in je controller wat alleen maar meer code is. Je maakt dus een extra vertaalslag. (Momenteel pas ik het toe in mijn applicatie en bevalt me heel goed)

p.s: wat is IMHO?
p.s: Mocht je het gebruik van design patterns interessant vinden: http://www.dofactory.com/Patterns/Patterns.aspx In het boek head first Design patterns, worden ze uitgebreid besproken met hele goeie voorbeelden. Echt een aanrader!

[ Voor 26% gewijzigd door BlackHawkDesign op 04-04-2009 13:42 ]

[Verwijderd]

BlackHawkDesign schreef op zaterdag 04 april 2009 @ 13:07:

p.s: Mocht je het gebruik van design patterns interessant vinden: http://www.dofactory.com/Patterns/Patterns.aspx In het boek head first Design patterns, worden ze uitgebreid besproken met hele goeie voorbeelden. Echt een aanrader!

^{Dan zou ik toch echt voor http://www.amazon.com/Des...oks&qid=1238848402&sr=8-1 gaan. Toch een wat betere samenhang en tevens erg leerzaam mbt. OO.}

[djluc]

Dus het is eigenlijk wel een bedoelde best practice om vanuit je view gewoon je model aan te roepen. Mm, wordt weer een flink redesign zo lijkt het!

[BlackHawkDesign]

Jep, echter zoals BCC al terecht op merkte, een design pattern is een middel niet een doel. Want het MCV model schrijf ook voor om gebruik te maken van het Observer pattern, dat er voor zorgt dat zodra gegevens in het model zijn geupdate dat automatisch je view wordt aangepast. Echter werkt dit niet praktisch bij webdevelopment aangezien je niet zelf je view kan refreshen.

Ik wilde alleen maar aangeven dat het MCV model voorschrijft dat je dus wel je gegevens binnenhaalt met je view en niet met je controller. De manier waarop je een of uberhaupt het gebruik van een designpattern ligt aan de ontwikkelaar en soms zijn er betere redenen om het niet te doen of een aangepaste versie dan wel.

Ik zou het dus niet aanpassen. Je zou in een nieuw project kunnen kijken welke manier je beter bevalt.

[ Voor 30% gewijzigd door BlackHawkDesign op 06-04-2009 09:50 ]