Laat het mij mezelf gemakkelijk maken om de vraag niet te ingewikkeld te stellen door ze "in het algemeen" te stellen...
Als je een soort van cms-systeem wil maken (ik zeg soort omdat ik nog niet goed weet wat ik exact ga doen), wat werkt dan het simpelst, snelst en vooral efficienste?
Hiermee bedoel ik:
Zou je een framework gebruiken en zo ja, welk en waarom? (zo neen, waarom niet?)
Dit gezegd zijnde:
Wat doen we met het design-gedeelte (HTML en CSS)?
Gaan we meteen voor HTML5 en CSS3 of gebruiken we nog gewoon verder met de "oudere" standaarden?
Is er ook een oplossing voor de browser-specific CSS3 dingen (webkit, IE en mozilla) of blijft nog steeds deze tags gebruiken totdat hiervoor een echte standaard is voor alle browsers?
Ik kan denk ik nog wel 100 vragen stellen, maar ik wil toch graag eerst hierover al eens kijken wat de antwoorden zijn...
Zou je een framework gebruiken en zo ja, welk en waarom? (zo neen, waarom niet?)
Ja, symfony Even zonder grappen, Symfony components worden gebruikt in Drupal8, Joomla! 3.0, een paar kleine cms's en in Symfony CMF (het grote Content Management Framework project van de symfony community)
Citaat:
Gaan we meteen voor HTML5 en CSS3 of gebruiken we nog gewoon verder met de "oudere" standaarden?
Ja, HTML5.0 komt dit jaar uit en zal vanaf volgend jaar de standaard zijn, gewoon gebruiken dus! (met eventueel fallbacks (door gebruik van bijv. Modernizr) naar polyfills)
Citaat:
Is er ook een oplossing voor de browser-specific CSS3 dingen (webkit, IE en mozilla) of blijft nog steeds deze tags gebruiken totdat hiervoor een echte standaard is voor alle browsers?
Toch 1 klein (of voor mij een heel GRÓÓT) puntje over Symfony...
Als ik zie hoe Martijn2008 hier zo mee zit te knoeien (lees: moeilijkheden mee heeft) en dat hij beduidend méér ervaring heeft met PHP dan ik, dan zakt de moed me toch in de schoenen om daar mee te beginnen...
Ik ken mijn weg wel binnen PHP, maar ik ben geen PHP-genie...
Hoe pak ik het dan het beste aan om daar mee aan de slag te gaan (buiten de docu erop na te lezen)?
Hi UpLink, geinig dat je me noemt in je vorige post. Ik adviseer je eerst helder te hebben wat voor applicatie je wilt bouwen, alvorens je verder gaat. Wat moet de applicatie doen? Hoe ziet de sitemap eruit? Welke invoerschermen zijn er etc.
Daarna zou ik kijken op wat voor platform de applicatie moet gaan draaien. Mijn applicatie moet multi platform werken, dit heeft geresulteerd tot de keus van PHP. JAVA had ook een optie geweest, maar daar heb ik minder ervaring mee.
Vervolgens heb je de keus om zonder of met framework te werken. Een framework bespaart je veel werk, je hoeft minder coderegels te tikken en je hoeft je geen zorgen te maken over de afhandeling onder de motorkap van het framework. Daarom heb ik gekozen voor een framework.
Ik heb me de laatste tijd niet zoveel bezig gehouden omtrent de ontwikkelingen van PHP frameworks. Toen ik me ging oriënteren ontdekte ik dat er heel veel zijn: Zend Framework, Symfony, Kohana en nog tal van andere. Daarna ben ik een forum topic gestart over de keus van een PHP Framework.
Op advies van WouterJ heb ik toen gekozen om mijn applicatie met Symfony Framework te bouwen.
In eerste instantie kijk je er misschien tegenop om voor een framework te kiezen, gezien ik lees dat je basis-kennis van PHP hebt, echter als je je focus op 1 framework legt dan verleg je daarmee ook je grenzen en wordt je er vanzelf handig mee. Ik zou niet meer zonder Symfony een PHP applicatie maken.
Merk op dat er nu inmiddels 3 leden zijn die gekozen hebben voor Symfony Framework. Hoe meer leden voor dit framework zouden kiezen, hoe beter we elkaar kunnen helpen.
En merk op dat als ik heel eerlijk ben dat als je wat beter de documentatie leest je al heel erg ver kan komen. De meeste vragen van Martijn komen doordat hij te snel iets wilt en niet eerst rustig de basis kent.
Citaat:
Hoe pak ik het dan het beste aan om daar mee aan de slag te gaan (buiten de docu erop na te lezen)?
Word er een beetje knetter van eerlijk gezegd, zeker als je (nog) niet weet wat je exact wil dat heel het systeem gaat moeten doen...
Het enige dat ik wel spijtig vind is dat Symfony geen eigen template engine heeft (of ik moet erover gekeken hebben). Verder heeft het wel alles zowat aan boord waar ik (voorlopig) naartoe wil...
Is zo'n template-engine moeilijk om zelf te maken (als dit nodig blijkt) en binnen Symfony te laten functioneren zonder dat dit problemen oplevert?
Ik trek mijn haren echt op dit moment
//EDIT:
Klein vraagje: (en nu gaan er enkele mensen hier half dood vallen denk ik :-p )
Ik werk enorm graag met tabellen. Ik weet dat opmaak met tabellen een beetje 90's is, maar ik vind het lekker werken, in tegenstelling tot div's die van tijd tot tijd wel eens moeilijk durven doen met hun positioneringen binnen verschillende browsers...
Iedereen verkiest GEEN tabellayout!
Een layout in tabellen is ook gewoon veel lastiger dan iets met bv divs..Het maken opzichzelf misschien nog niet, maar het aanpassen later zeker wel.
Maak voor jezelf een simpel header, 2 kolommen en een footer layout (en dan bedoel ik zelf maken en geen template nemen), de eerste keer is dat veel zoekwerk, omdat je blijkbaar de css ook niet kent, maar daarna gooi je zon lay in 3 minuten op tafel.
Ik weet dat tabellen tegenwoordig alleen maar gebruikt worden voor tabular data zoals data uit een database weergeven en dergelijke...
Ik ken de CSS wel die gebruikt word voor de positionering van divs en dergelijke, het is alleen dat dit niet (altijd) in alle browsers hetzelfde word weergegeven terwijl dit met tabellen meestal wel onmiddellijk overal hetzelfde is...
Daarom dat ik soms wat twijfel om met div's te werken...
Maar heb toch snel ff iets in elkaar gegooid:hier....
Het enige dat ik wel spijtig vind is dat Symfony geen eigen template engine heeft (of ik moet erover gekeken hebben). Verder heeft het wel alles zowat aan boord waar ik (voorlopig) naartoe wil...
Ik denk dat je verkeerd hebt gekeken. Ik denk dat Symfony de enige in dat lijstje is die een templating engine (twig) gebruikt. De andere hebben alleen maar templating helpers.
Ik heb ondertussen al gekeken naar enkele frameworks en ik zie ook ondertussen door de bomen het bos niet meer...
Word er een beetje knetter van eerlijk gezegd, zeker als je (nog) niet weet wat je exact wil dat heel het systeem gaat moeten doen...
Haha, zoals ik je al vertelde had ik hetzelfde probleem.
UpLink schreef:
Het enige dat ik wel spijtig vind is dat Symfony geen eigen template engine heeft (of ik moet erover gekeken hebben). Verder heeft het wel alles zowat aan boord waar ik (voorlopig) naartoe wil...
Vergeet het selecteren van een framework even. Ik begrijp niet waarom je een framework aan het selecteren bent. En jij snapt dat waarschijnlijk ook niet, aangezien je geen doel hebt met je applicatie.
Daarom is mijn advies: probeer eerst helder te hebben wat voor applicatie je wilt maken en welke doelen je daarbij hebt. Vanuit dat perspectief kun je verder werken.
Het verbaast me dat er nog niemand hard op die tabellen gereageerd heeft.
Aub gebruik het niet. Niet voor klanten, niet voor jezelf. Het is een bad practice. Dat het in elke browser hetzelfde doet, tjah, dat doen afbeeldingen ook. Waarom dan niet een afbeelding van elke pagina tonen? Nog gemakkelijker... Maar not done.
Het kan lijken alsof tabellen enkel voordelen hebben, maar:
1. Het toont verouderd. Zowel naar zoekmachines als naar mensen die er achteraf aan moeten werken.
2. Het is moeilijker aanpasbaar.
3. Performance. Layout in CSS kan gecached worden. Tables in je pagina moeten elke keer opnieuw geladen worden.
4. Mobile en responsive. Ik zou je graag eens tabellen zien gebruiken hiervoor.
5. Semantiek. Hou inhoud en layout gescheiden.
6. Toegankelijkheid.
Het verbaast me dat er nog niemand hard op die tabellen gereageerd heeft. Â
Aub gebruik het niet. Niet voor klanten, niet voor jezelf. Het is een bad practice...
Ik denk dat de keus voor wel of geen tabellen van meer zaken afhangt. Met name het budget en doel van een applicatie hebben veel invloed. Op bijvoorbeeld een intranet website kan een lijst met gebruikers prima in een tabel worden geplaatst.
@toegankelijkheid, denk aan screenreaders...een reader die een tabel opleest, (verzin zelf de volgorde van lezen..ik weet die echt niet) of een compleet verhaaltje uit kolom 1, en een compleet verhaaltje uit kolom 2.
edit: @ Pieter, een tabel niet gecached ....???
edit edit: bij mijn firefox wordt het iig perfect gecahed! (volgens about:cache)
Het feit dat ik nadacht om voor tabellen te gaan was omwille van het feit dat ik dit persoonlijk gemakkelijk werken vind, maar dat ik in het verleden ook al meegewerkt heb aan een CMS.
Sommigen zullen het misschien kennen, Jupiter CMS (of Jupiter Content Manager).
Er hadden op het einde zoveel mensen aan gesleuteld dat het gewoon zo lek als een zeef was en rijp voor de prullenmand was.
Dat CMS was ook volledig opgebouwd in tables. Vandaar dat ik het erg gemakkelijk werken vind/vond.
Natuurlijk is veranderen nooit slecht en zeker als ik de puntjes van Pieter bekijk.
@Vintage, wat die caching betreft: als je layout met externe CSS zit je layouting in je externe cssfile, ipv grotendeels in je html. Als de cssfile eenmalig geladen is en er wordt goed gecached, dan is de layout al voor het grootste deel geladen op elke pagina. Als je op elke pagina tabellen gebruikt, moeten die tabelcodes elke keer opnieuw geladen worden door de eindgebruiker. OK, dat is allemaal statisch, maar het is minder efficiënt. Tabellenlayout vraagt meer code.
@Martijn, het merendeel heeft vinTage al uitgelegd. Ik begrijp dat het van meer factoren afhangt, maar geen budget vind ik geen goeie reden. Het kost niet per definitie meer om iets in css te doen. Hangt allemaal af van de skills van de developer. Een lijst gebruikers met info over die gebruikers? Dat mag, dat is tabulaire data. Ik wil gewoon zeggen, gebruik de dingen waarvoor ze gemaakt zijn.
Bedankt voor je voorbeeld, vinTage. Je geeft een voorbeeld van een CSS-opmaak van 2 kolommen, hoe gaan we dan om met een tabel van bijvoorbeeld 6 kolommen?
De kolommen kunnen immers bij een CSS opmaak ook naar onderen schieten, dat is bij een tabel volgens mij niet mogelijk, doordat de kolommen dan smaller worden.
vinTage schreef:
Feit dat je dat zegt, zegt al voldoende
Haha, ik maak een keus per situatie. Voor een backend is SEO bijvoorbeeld niet belangrijk. Als een tabel sneller te maken is dan CSS dan verkies ik de tabel. Sommige websites worden naar een paar maanden toch vervangen.
Ik vind het argument 'tabellen is sneller dan semantische HTML' onzin. Sorry dat ik het zeg, maar het is compleet subjectief. Zodra ik een website met tabellen zou moeten maken ben ik er dagen mee bezig, met semantische HTML misschien een middagje.
Daarnaast is het juist andersom. Een tabellen pagina is zeer moeilijk bij te houden. Stel ik wil even iets veranderen, dan ben ik uren bezig dit op te zoeken in de tabel, ect. Met een semantische pagina zou dit gewoon 1..2..3 in de CSS aan te passen zijn.
Wat is het verschil in tijd om een rij in een tabel bij te voegen in je opmaak tegenover een div bijplaatsen en deze correct te positioneren?
Ik ben namelijk langer bezig een DIV bij te plaatsen en deze op de correcte plaats (in ALLE browsers) te krijgen tegenover gewoon even een stukje code voor de tabel bij te plaatsen en alles in 1 keer correct te hebben in ALLE browsers...
table == table
div != div
Dat is mijn opvatting in de opmaak... Sommige mensen zijn pro table's, anderen contra...
En imho zijn er tegenwoordig meer mensen die (bijvoorbeeld) Dreamweaver opzetten om een div bij te kletsen omdat dit gewoon drag-and-drop is... En dan kunnen we inderdaad spreken van "Div's werkt veel sneller" ...
Ik werk namelijk (nog steeds) met die goeie ouwe Notepad of Notepad++ als er PHP of dergelijke mee gemoeid is...
And just to be clear... Volgens mij kan je met een table + CSS evenveel aanvangen dan met een div + CSS... Het is gewoon de manier waarop je naar dingen kijkt...
@UpLink,
Ik denk dat het eerder een kwestie van gewoontes is en eens buiten je comfortzone komen is. Werken met divs is complexer dan de logica achter tabellen begrijpen. Eens je het treffelijk vasthebt, kan je er meer mee en kan je het sneller.
Citaat:
Sommige websites worden naar een paar maanden toch vervangen.
@Marijn, dan is het geen goeie site.
Als je overweegt om met tabellen te werken, gebruik je dan ook nog frames? Toch veel gemakkelijker? En de marquee tag enzo? Geen javascript nodig voor beweging.
Voor alles een tijd. Als je mobile in het achterhoofd wil houden, werk je niet meer met tabellen.
En imho zijn er tegenwoordig meer mensen die (bijvoorbeeld) Dreamweaver opzetten om een div bij te kletsen omdat dit gewoon drag-and-drop is... En dan kunnen we inderdaad spreken van "Div's werkt veel sneller" ...
Dit vind ik echt belachelijk. Ik heb in mijn leven nog nooit een WYSIWYG editor gebruikt en ik gebruik zo'n beetje de most basix editor in de wereld (genaamd Vim). Zomaar beweren dat iedereen die semantische HTML (dus die HTML gebruikt waarvoor het bedoelt is) schrijft een beetje aan het drag-and-droppen is vind ik echt belachelijk.
Citaat:
Volgens mij kan je met een table + CSS evenveel aanvangen dan met een div + CSS... Het is gewoon de manier waarop je naar dingen kijkt.
Ik denk het niet. Zomaar wat dingen:
- Laat jij mij maar eens zien hoe je iets van 10 blokken allemaal met een andere hoogte (zoals op http://wouterj.github.com ) met tabellen gaat oplossen.
- Verklein meteen je scherm maar eens op die site, ik denk niet dat je dit responsive design met tabellen kunt krijgen.
Citaat:
Ik ben namelijk langer bezig een DIV bij te plaatsen en deze op de correcte plaats (in ALLE browsers) te krijgen tegenover gewoon even een stukje code voor de tabel bij te plaatsen en alles in 1 keer correct te hebben in ALLE browsers...
Ik vraag me af waar het 'in alle browsers' vandaan komt. Ik heb nog nooit iemand gezien die CSS2 gebruikte waarin hij een probleem kreeg bij het plaatsen van een nieuwe div. Maar goed, misschien kun je een leuk voorbeeldje geven?
Er zijn hier TIG topics met vragen hoe ze hun probleem opgelost krijgen omdat bijvoorbeld IE het niet goed weergeeft en FF/Chrome/Opera wel, of omgekeerd...
Daar heb je hier op SiMa alleen al 1001 topics over...
We kunnen hier uren over discussieren hoe jij vind dat div's moeten gebruikt worden en dat dat (voor zover ik versta) de enige oplossing is als je je scherm verkleint (waaronder ik mobile-versie versta).
Waartegen ik dan weer vind dat er met tables niks mis is en dat je met wat CSS ook je tables kan aanpassen zodat je je indeling mooi kan schikken en dat er ook iets anders bestaat dan enkel die mobile waar iedereen tegenwoordig zo op door zit te drammen.
enzovoort...
enzovoort...
enzovoort...
Het gaat er hier om wat het beste is voor een CMS (zowel back-end als front-end) ...
Daarnaast heb ik dat CMS (waar ik enkele jaren terug aan meegewerkt had) teruggevonden tussen mijn puinhoop van bestanden op een externe HDD stond en voor de gein ook even geïnstalleerd op de webserver...
Begin geen commentaar te geven op de functionaliteit... Bekijk gewoon het design... VOLLEDIG, je leest het goed, opgemaakt met tables... ik denk dat je dat design toch voor een stuk kan vergelijken met SiMa hier (qua uitzicht toch)...
Als jij hiervan het tegendeel wil bewijzen, feel free... zet heel de boel om naar div's en bewijs mij welk verschil ik ga krijgen met die tables en div's op het mobile gedeelte...
Goed, er is een vergissing aan het insluipen. We hebben het hier voornamelijk niet over de voorkant van de website, meer over de achterkant.
HTML is een taal die in 1991 door CERN bedacht is om data over te brengen tussen de verschillende meet locaties. Het is een taal waarmee je gewoon raw tekst omzet naar dingen die de computer begrijpt. Als je hier naar deze site kijkt begrijp jij dat 'zelf cms maken' de titel is van dit topic en dat de tekst in deze reactie opgebouwd is uit alinea's. Een browser weet dit niet, daarvoor heeft hij HTML nodig.
In HTML zijn er heel veel elementen. Met deze elementen geef je de tekst een waarde. Je zegt tegen de browser: hé, dit is een titel van dit topic en dat daar is een alinea en dat daar is een link.
Het is dus in HTML de bedoeling tekst zoveel mogelijk een goede waarde te geven.
Langzaamaan werd internet en HTML populair bij de mensen en kwam er in 1996 CSS bij. Mensen wouden meer dan wat simpele tekst. De makers van een browser begonnen toen alle elementen user agent styles mee te geven. Hiermee probeerden ze ons leven makkelijker te maken; ipv dat wij alle titels groter moesten maken zorgde de ua styles daarvoor.
Er kwam hierdoor 1 probleem: Mensen begonnen zich niet meer bezig te houden met de semantiek van HTML, maar met hoe je je HTML zo kunt schrijven dat je makkelijk CSS kunt gebruiken. Dat is dus totaal verkeerd, HTML staat los van CSS. CSS is iets wat in dienst staat van HTML, iets extra's, niet andersom.
Ik kan in een hele website niks anders dan de body tag gebruiken. Wordt de site daar mooi van? Zeker weten. Waarom doen we dat dan niet? Omdat HTML daar niet voor bedoeld is. De body is de body van de website, dat komt maar 1 keer voor.
En zo moeten we dus ook naar het table element kijken. De semantische waarde van een element staat beschreven in de HTML specificaties, in ons geval:
Citaat:
The table element represents data with more than one dimension, in the form of a table.
-- The table element
Met meer dan 1 dimensie worden bijv. resultaten bedoelt. 1 resultaat is gekoppeld aan andere resultaten en daarom aan andere dimensies.
Tekst heeft maar 1 dimensie en een site content ook. De site content bestaat welliswaar uit secties die bij elkaar kunnen horen, maar het is niet zo dat 1 hele rij of een hele kolom bij elkaar hoort, wat bij tabellen wel het geval moet zijn.
Hierdoor is een table uitgeschakeld voor het gebruik in lay-outs.
Zo'n website die jij hebt zal ik ook niet met tabellen bouwen, echter voor het tonen van resultaten uit een database kan het handig zijn. Bijvoorbeeld een tabel met een overzicht van alle leden met de kolommen: voornaam, achternaam, geboortedatum, woonplaats etc.
Laat ik nu net even iets aan het lezen zijn (een tijdschrift) en laat er nu net een framework genoemd worden dat ik nog niet gezien had of van gehoord had.
Laravel gebruikt wat symfony componenten en ik hou niet zo van dat framework. Te veel facades en dus statics.
Het is leuk voor het rijtje waar code igniter in staat, de frameworks voor beginners, maar wil je wat meer dan moet je toch echt bij de top frameworks als zf, symfony, ect. kijken.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Even zonder grappen, Symfony components worden gebruikt in Drupal8, Joomla! 3.0, een paar kleine cms's en in Symfony CMF (het grote Content Management Framework project van de symfony community)
Actiefste leden van de maand
