Projektstruktur med programmering i fokus (m. PHP som exmpel)

Kimppa · 2013-10-10, 15:28

Tror det är lättare att förklara om jag skriver "kod-aktigt":

PHP-dokument (Om detta är klasser från ett "funktionsdokument"):

Citat:

$html = new HTML;
$head = new HEAD;
$content = new CONTENT;
$foot = new FOOT;
$elements = new ELEMENTS;

<?php

$html->page(

$head->start();
$head->title("title");
$head->end();

$content->(
$elements->h1("header");
$elements->paragraph("paragraph");
);

$foot->end();

);

?>

Vet inte hur bra det där är skrivet men skulle det vara möjlit att göra något sådant? Ser väldigt bökigt ut för tillfället men man kanske bara måste hitta sitt eget.

Sen kommer man ju självklart alltid få skriva vissa funktioner/metoder för projekt men hade tänkt det som en bas för HTML i första hand.

Jag föredrar att inte använda fördefinerade ramverk då jag hellre söker och försöker lösa problemen själva. Det kanske är dumt och tar längre tid men ser programmering som en hobby.

En kock kanske har en egen kockbok

(ändrar mig till amatörkock då jag sa hobby innan) :P

Johnny Viking · 2013-10-10, 16:35

För mig känns det som att du försöker skriva en templating engine, i PHP. Sånt är trevlig, men ska jag säga, det finns flertalet sådana, i mikro till giganter.

Om du på en vanliga simpel PHP sida vill wrappa en header och footer med potentiella variabler, så skulle jag skapa en PHP-fil, som styrs av en PHP-class och metoder samt argument till metoderna. Du sätter då default-argument, som kan överstyras vid behov.

Grovt exempel

Citat:

echo $template->header(array("title" => "blah"));
echo $article->body();
echo $template->footer();

På så sätt så har du iaf möjlighet att i framtiden överstyra alla sidor i ett nafs.

Fast, jag kanske helt missförstått och repeterar vad andra sagt

Clarence · 2013-10-10, 17:01

Citat:

Ursprungligen postat av Kimppa

EDIT: Jag använder mig av "ramverk" ungefär på samma sätt som templates/mallar i Word, när jag kodar CSS med speciella margins för headers, text, etc. (som går att återanvändas i olika projekt för bra artiklar etc.)

Menar du att du vill styra CSS via PHP-objekt? Om jag vore du så skulle jag verkligen försöka separera frontend och backend så väldigt mycket som är praktiskt möjligt. Det blir både lättare att underhålla och att vidareutveckla. Det betyder att du använder SASS/Stylus/* om du behöver "ramverk" för CSS. Använder du det också för templates så är det enklaste att du använder ett väl utvecklat template-språk. Du har enklare versioner såsom mustache och handlebars (finns till många språk) eller mer välutvecklade versioner som twig, smarty, dwoo (dessa är alla endast för PHP såvitt jag vet) etc. Använder du någon av de mer utvecklade versionerna är det desto enklare att utöka med egna taggar och plugins. Du får då en bra översikt av din HTML och samtidigt möjligheten att utöka den med flexibel kod där det behövs.

Bra liknelse med en kock, jag gillar att laga mat. Ska jag laga något mer utförligt jag inte har en aning om hur jag ska gå tillväga med så lagar jag från olika recept de första gångerna... då har jag lite koll på vilka ingredienser som kan passa och kan ett par variationer som funkar. Då har man en bra utgångspunkt att variera och förändra ifrån.

Skriver för övrigt recipes rätt mycket just nu, fått till ett bra gäng riktigt användbara cookbooks som jag laddar upp med min knife. Har också planer på att börja använda ett test kitchen. På tal om matlagning

danjel · 2013-10-10, 17:12

Tror du är inne på rätt spår..

Jag brukar använda en "View" klass ,
som hanterar olika template filer.

T.ex kan en sid template se ut så här:

<div>
<h1><?php echo $this->h1 ;?></h1>
<p><?php echo $this->content;?></p>
</div>

Sidans controller instansierar ett objekt

$page= new View("sida1.php");
$page->content = "Innehållet";
$page->h1 ="header";

Och sen brukar jag ha en template för själva layouten, det binds samman så här rent principiellt typ:

$master= new View("Master.php");

$master->content = $page->render();

Master.php :

<head>
<title>test</title>
</head>
<body>
<main><?php echo $this->content;?></main>
</Body>

Det är även bra att undvika att skapa objekt direkt från en controller , så det ser ut så här i praktiken..

class Page extends \MyLib\ControllerAbstract
{

public function index()
{

$this->view->h1 = "h1";
$this->view->content = "xx..";

$this->masterView->doc_title = " dokument titel "; // bra om man även kan modifiera master sidan direkt så här typ

return $this->view; // $this->view är en instans av "View" klass
}

}

Conny Westh · 2013-10-10, 17:47

Citat:

Ursprungligen postat av Kimppa

Väldigt intressanta diskussioner!

Jag kodar i mestadels PHP.

Tycker ConnyWesth tänker ganska precis som jag tänker och var ungefär vad jag menade med denna tråd.

Jag har inte menat at skriva "superavancerade" ramverk utan enklare ramverk för att skriva ut början av t.ex. HTML-dokument (då jag inte applikationsutvecklar) och även slutet för HTML dokumentet.

För tillfället så använder jag mig av två PHP-funktioner för de flesta av mina projekt (enklare projekt) och de är:

1. Skriver ut allt från DOCTYPE till början på BODY.
(Brukar göra någon custom header som jag kan använda mig av i första fuktionen, oftast väldigt olikt designade)
2. Avslutar andra funktionen med </BODY> och eventuell "close" av databas.

Jag har länge tänkt på detta med klasser och PHP men aldrig riktigt förstått mig på det.

Om jag fårstår dig rätt Conny:
- Skulle det vara möjligt att skapa en klass som skapar html_start->html-end, för att sedan i PHP-dokumentet (med själva webbplatsstrukturen) kunna klistra in metoder/objekt/funktioner från denna klass?

Eller är de bättre att strukturera upp det som jag gjort tidigare?

EDIT: Jag använder mig av "ramverk" ungefär på samma sätt som templates/mallar i Word, när jag kodar CSS med speciella margins för headers, text, etc. (som går att återanvändas i olika projekt för bra artiklar etc.)

Om du tänker verksamhetsspecifikt (domain-driven-development, DDD) så kan man bygga en uppsättning klasser som följer strukturen på "verksamheten" eller "domänen". Helt utan koppling till HTML över huvud taget.

Sen kopplar man ihop det hela med "tekniska" klasser som lägger på HTML-taggar där det behövs.

Man kan givetvis koppla ihop detta med en rad andra externa ramverk efter tycke och smak.

Det finns dessutom olika skiktningsmodeller:

MVC - Model-View-Controller (Gammal modell som använts i mer än 20 år)

eller

MVVM Model-View-ViewModel (Modernare variant som anpassats till många olika GUI-device). Se http://en.wikipedia.org/wiki/Model_View_ViewModel för mer info.

Det finns en annan paradigm som kallas test-driven-utveckling (TDD) men den har ett grundläggande tankefel, det går nämligen aldrig att "testa" fram bra kvalitet i en applikation. Kvaliteten måste man designa in från början genom att ha järnkoll på arkitekturen och verksamhetens krav, det är inte testerna som är kraven som många TDD förespråkare hävdar.

Jag är som sagt mer anhängare av DDD-paradigmen med arkitekturell design.

Givetvis ska man testa koden utförligt, men det är inte alltid möjligt att testa allt man behöver testa genom automatiska tester, det skulle kosta för mycket att bygga såna automatiska tester, så projektet skulle bli olönsamt. Man behöver en kombination av automatiska testrutiner och manuella för att optimera ekonomin i projekten.

Clarence · 2013-10-10, 19:39

Citat:

Ursprungligen postat av ConnyWesth

Om du tänker verksamhetsspecifikt (domain-driven-development, DDD) så kan man bygga en uppsättning klasser som följer strukturen på "verksamheten" eller "domänen". Helt utan koppling till HTML över huvud taget.

Sen kopplar man ihop det hela med "tekniska" klasser som lägger på HTML-taggar där det behövs.

Man kan givetvis koppla ihop detta med en rad andra externa ramverk efter tycke och smak.

Det finns dessutom olika skiktningsmodeller:

MVC - Model-View-Controller (Gammal modell som använts i mer än 20 år)

eller

MVVM Model-View-ViewModel (Modernare variant som anpassats till många olika GUI-device). Se http://en.wikipedia.org/wiki/Model_View_ViewModel för mer info.

Det finns en annan paradigm som kallas test-driven-utveckling (TDD) men den har ett grundläggande tankefel, det går nämligen aldrig att "testa" fram bra kvalitet i en applikation. Kvaliteten måste man designa in från början genom att ha järnkoll på arkitekturen och verksamhetens krav, det är inte testerna som är kraven som många TDD förespråkare hävdar.

Jag är som sagt mer anhängare av DDD-paradigmen med arkitekturell design.

Givetvis ska man testa koden utförligt, men det är inte alltid möjligt att testa allt man behöver testa genom automatiska tester, det skulle kosta för mycket att bygga såna automatiska tester, så projektet skulle bli olönsamt. Man behöver en kombination av automatiska testrutiner och manuella för att optimera ekonomin i projekten.

Minst sagt konstig syn på TDD, du borde testa att jobba med det ett par dagar så du får lite bättre koll på det. Dels så går det alldeles utmärkt att tillämpa både DDD och TDD i samma projekt. Precis som TDD passar med i princip alla andra utvecklingsmetoder eller patterns förutom riktigt kass kod. TDD har inget med din design att göra, även om dålig design är svår att testa ordentligt.

Det finns heller ingen pragmatisk TDD-förespråkare som säger att du ska ha 100% code coverage eller för den delen inte använda andra testmetoder.

Med MVVM ska man tänka på att den inte fått så stor spridning ännu. En annan potentiell uppstickare är HMVC. Både är värda en titt om man tycker att MVC-modellen har brister för en speciell applikation (tänk på att många MVC-ramverk i princip låter dig använda HMVC).

dAEk · 2013-10-10, 19:51

Citat:

Ursprungligen postat av ConnyWesth

Det finns en annan paradigm som kallas test-driven-utveckling (TDD) men den har ett grundläggande tankefel, det går nämligen aldrig att "testa" fram bra kvalitet i en applikation.

Det beror på vad din definition av kvalitet är. Är det t.ex. löst kopplade komponenter, abstraktion och tydlig separation? I så fall: jo, det kan man visst.

Citat:

Ursprungligen postat av ConnyWesth

Kvaliteten måste man designa in från början genom att ha järnkoll på arkitekturen och verksamhetens krav, det är inte testerna som är kraven som många TDD förespråkare hävdar.

Tillsammans utgör ju testerna en levande spec av systemet och det inkluderar verksamhetens krav. Klart att man måste ha koll på verksamhetens krav, det är ju det man ska bygga och skriva tester för! Eller fattar jag inte vad du menar?

dAEk · 2013-10-10, 19:52

Citat:

Ursprungligen postat av Clarence

Minst sagt konstig syn på TDD [...]

Så tänkte jag också men så lät jag det sjunka in lite.

Skall man vara strikt skall ju TDD forma koden och det verkar krocka med DDD som jag förstår det. Det kanske är det Conny menar?

Tester kan man såklart ha i DDD också.

Clarence · 2013-10-10, 20:11

Citat:

Ursprungligen postat av dAEk

Så tänkte jag också men så lät jag det sjunka in lite.

Skall man vara strikt skall ju TDD forma koden och det verkar krocka med DDD som jag förstår det. Det kanske är det Conny menar?

Tester kan man såklart ha i DDD också.

Håller inte med. Läser du ut TDD som en test driven design så har du gått ifrån dess ursprungliga mening och borde därmed ta tid att förklara vad du menar.

dAEk · 2013-10-10, 20:30

Citat:

Ursprungligen postat av Clarence

Håller inte med. Läser du ut TDD som en test driven design så har du gått ifrån dess ursprungliga mening och borde därmed ta tid att förklara vad du menar.

Jag menar inte att man kan strunta i arkitekturen utan mer att man har den i åtanke när man kodar. I TDD utgår man (läs. jag) från testerna, klasserna designas löpande i takt med att beroenden tillkommer; DDD verkar ha vissa förutbestämda klossar som man utgår från. Vet inte om min bild är skev men det är så jag ser på det.

Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)

Menu

Projektstruktur med programmering i fokus (m. PHP som exmpel)