Archief - Lancering Open Source CMS: Fork CMS

netlash · 11 okt 2010

We hebben ons Content Management Systeem opengesteld voor de rest van de wereld.
Feel free to use it:

Blog - Fork CMS

Feedback is uiteraard welkom!

little · 11 okt 2010

OC maken van je eigen CMS.... chapeau!
Gretig kijken en kennis maken

Tyfius · 11 okt 2010

Wat mij wel meteen opvalt is het overdadig gebruik van nutteloze commentaar. Letterlijk elke file die ik open trek staat er vol van:

PHP:

public function execute()
{
  // call parent, this will probably add some general CSS/JS or other required files
  parent::execute();

  // parse
  $this->parse();

  // display the page
  $this->display();
}

Omdat dit echt in elke file van jullie CMS en Spoon library is vraag ik me toch af wat de reden daarvoor is. De code is duidelijk genoeg en dit zorgt naar mijn mening alleen voor onnodig tijdsverlies.

Langs de ene kant juich ik elke vorm van open source toe, langs de andere kant vraag ik me af of jullie niet ontzettend veel tijd zouden besparen door een van de bestaande open source systemen te gebruiken.
Is er een bepaalde reden dat jullie geopteerd hebben voor de eigen ontwikkeling van een CMS? En wat zijn de plannen naar de toekomst?

adrianhates · 11 okt 2010

Tyfius zei:
Wat mij wel meteen opvalt is het overdadig gebruik van nutteloze commentaar. Letterlijk elke file die ik open trek staat er vol van:

PHP:

public function execute() { // call parent, this will probably add some general CSS/JS or other required files parent::execute(); // parse $this->parse(); // display the page $this->display(); }

Omdat dit echt in elke file van jullie CMS en Spoon library is vraag ik me toch af wat de reden daarvoor is. De code is duidelijk genoeg en dit zorgt naar mijn mening alleen voor onnodig tijdsverlies.

zorgt dit bijkomend ook niet voor 'verdubbeling' van de filesize, als je elke lijn een commentaarregel geeft?

Maar ik heb geen commentaar op de code zelf , er zit heel wat werk/tijd en kunnen in! Het resultaat van jarenlang werk dus.

Wat me minder aanstaat is dat jullie nu ook wel alles kenbaar maken en zelf aangeven dat dit systeem bij zowat alle van jullie grote klanten gebruikt wordt. Zit hier geen risico in waarmee jullie de klanten eventueel hard zouden kunnen nekken indien er toch een gaatje kan gevonden worden?

Het is nog niet zozeer als andere open source software ( ik verwijs naar wordpress en drupal die toch soms grote beveiligingslekken hebben), maar hier heeft wel nog geen hele community eens zijn kritiek op geleverd ..

Wolfr · 11 okt 2010

adrianhates zei:
zorgt dit bijkomend ook niet voor 'verdubbeling' van de filesize, als je elke lijn een commentaarregel geeft?

Maar ik heb geen commentaar op de code zelf , er zit heel wat werk/tijd en kunnen in! Het resultaat van jarenlang werk dus.

Wat me minder aanstaat is dat jullie nu ook wel alles kenbaar maken en zelf aangeven dat dit systeem bij zowat alle van jullie grote klanten gebruikt wordt. Zit hier geen risico in waarmee jullie de klanten eventueel hard zouden kunnen nekken indien er toch een gaatje kan gevonden worden?

Het is nog niet zozeer als andere open source software ( ik verwijs naar wordpress en drupal die toch soms grote beveiligingslekken hebben), maar hier heeft wel nog geen hele community eens zijn kritiek op geleverd ..

De "verdubbeling" is enkel relevant bij bvb. javascript of CSS: bij een server side taal wordt de commentaar gewoonweg negeerd. De filesize van een PHP file maakt heel weinig verschil uit voor de performance.

Qua beveiligingslekken kan ik zeggen dat we Fork geaudit hebben door verschillende partijen; de grote sites van Netlash draaien ook op een andere versie van Fork CMS.

Wolfr (lead designer Fork CMS)

robbie7 · 11 okt 2010

Bij Netlash zelf is het zo dat bij elke file/lijn dat ze schrijven altijd commentaar moet staan, vandaar dat dit ook zo is voor fork vermoed ik. Aangezien hun projecten binnen Netlash verschillende stations moeten passeren kan ik het volledig begrijpen dat het daar allemaal becommentarieerd wordt, maar of dit goed is om het ook voor hun CMS te gaan doen dat is iets anders natuurlijk.

netlash · 11 okt 2010

adrianhates zei:
Wat me minder aanstaat is dat jullie nu ook wel alles kenbaar maken en zelf aangeven dat dit systeem bij zowat alle van jullie grote klanten gebruikt wordt. Zit hier geen risico in waarmee jullie de klanten eventueel hard zouden kunnen nekken indien er toch een gaatje kan gevonden worden?

Security door obscurity werkt niet. Als we enkel zouden betrouwen op het feit dat niemand de code kent voor veiligheid, dan zouden we slecht bezig zijn.

Integendeel, door het te open sourcen krijgen we misschien nog feedback over waar het beter kan.

krulle3 · 11 okt 2010

netlash zei:
Security door obscurity werkt niet. Als we enkel zouden betrouwen op het feit dat niemand de code kent voor veiligheid, dan zouden we slecht bezig zijn.

Integendeel, door het te open sourcen krijgen we misschien nog feedback over waar het beter kan.

Bij zulke projecten is het open source gooien vaak een aanrader omdat er dan een hele gemeenschap mee kan gaan werken en me er zeker feedback over zal krijgen.
BRAVO Netlash! Deze nemen we zeker op in onze paper over CMS die we moeten maken als een opdracht voor de module datamanagement in de richting New Media and Communication Technology

edit: Bekijk eens de telling van jullie website want er staat 169 comments terwijl dit er in detail maar 13 zijn.

Drone · 11 okt 2010

Veel comments is niet slecht. In Python applicaties/frameworks zie ik dat veel. Ook als er niet veel documentatie is zijn comments wel handig. Zeker als je een taal gebruikt die je niet compiled dan kan je altijd gemakkelijk de source eens bekijken.

Zit er eigenlijk iets van unit tests of andere testen in Fork?

adrianhates · 11 okt 2010

netlash zei:
Security door obscurity werkt niet. Als we enkel zouden betrouwen op het feit dat niemand de code kent voor veiligheid, dan zouden we slecht bezig zijn.

Integendeel, door het te open sourcen krijgen we misschien nog feedback over waar het beter kan.

Wat de verdubbeling betreft heeft het wel betrekking op de algehele filesize, niet zozeer op de verwerkingssnelheid. Maar hedendaags is dat op een webserver nu ook niet het probleem meer.

Kdenk wel dat het goed is dat er veel commentaar staat zodat een buitenstaander er in kan duiken, maar anderzijds lijkt me dit onbegonnen werk om het zomaar even te proberen.

Ik had wel het gedacht dat jullie een andere versie gebruiken voor eigen projecten

Wat betreft security through obscurity: Het is zeker niet iets waar je moet op rekenen natuurlijk , maar het kan wel helpen in eerste instantie. Het is een aanvulling op ( of wordt aangevuld door ) security by design en die 2 methodieken worden veelal samengebracht om security te verfijnen.

Ik kan anders alleen maar bevestigen dat het (nog) beter zal worden door het publiek te maken. Al zit hier een serieuze leercurve achter en ik zie niet veel mensen er aan beginnen + is het best om de andere versie toch private te houden

Ik ga er mij alleszins niet mee bezig houden , kzou alleen maar tijd en geld verliezen

edit : vooral big up to davy matthias tijs en annelies want dat is een staaltje van pro php code

another edit : Welke software wordt gebruikt voor het tonen van de analytics data? ( de taartdiagrammen bvb ) ( heb geen zin om daarvoor speciaal de code in te duiken..

)

Wolfr · 11 okt 2010

@adrian hiervoor gebruiken we HighCharts Highcharts - Interactive JavaScript charts for your webpage

Ik kan anders alleen maar bevestigen dat het (nog) beter zal worden door het publiek te maken. Al zit hier een serieuze leercurve achter en ik zie niet veel mensen er aan beginnen

We willen altijd helpen als je vast komt te zitten. Het is de bedoeling dat zowel een designer als developer hier mee overweg kan. Als je Wordpress themes kan maken kan je ook Forken!

j design · 12 okt 2010

Eerste ding op de agenda voor morgen.
Ben ondertussen al beu gekeken op de wordpress codes

.
Had anders eens het concrete5 geprobeerd.
Bedankt!

tijsverkoyen · 12 okt 2010

@Tyfius: We schrijven inderdaad een pak comments. Dat ga ik zeker niet ontkennen, maar in mijn ogen kan je nooit genoeg comments schrijven.

Als ik aan een applicatie begin ga ik meestal ook grote brokken eerst in comments uitschrijven en dan pas code. Zo kan ik al eerst eens nadenken nog voor ik een letter code heb geschreven (maar dit is natuurlijk persoonlijk).

@[drone]-[1.05] er zijn nog geen unit-tests beschikbaar.

@adrianhates: de grotere sites draaien op een oudere versie, dus eigenlijk is deze open-source versie een resultaat van alle kennis die we opgedaan hebben bij de grotere projecten. En zoals Netlash al zei: door het opensource komen er misschien zaken sneller aan het licht.

Moto · 12 okt 2010

We schrijven inderdaad een pak comments. Dat ga ik zeker niet ontkennen, maar in mijn ogen kan je nooit genoeg comments schrijven.

- Duidelijke geschreven code heeft meestal geen commentaar nodig
- Onnodige commentaar is storend en zorgt ervoor dat ge minder code ziet (extra scrollen)

Policies als elke regel code voorzien van commentaar zijn vrij lachwekkend

Zero Grav · 12 okt 2010

Moto zei:
- Duidelijke geschreven code heeft meestal geen commentaar nodig

Als ge OOP begint te programmeren op een project waar meerdere mensen aan werken en dat enorm veel klasses begint te omslaan dan is commentaar echt wel onontbeerlijk. Of ge nu megaduidelijke code schrijft of niet.

Moto zei:
Policies als elke regel code voorzien van commentaar zijn vrij lachwekkend

Vind ik ook wel. Commentaar voor elke functie die ge uitvoert is nutteloos, daarvoor hebt ge php.net. Een functieomschrijving of gewoon een blok code commenten, of occassioneel uitleggen waarom ge een functie uitvoert is iets anders.

Maar als ik dees zie dan vraag ik mij ook wel af wat het nut nog is.
//parse
$this->parse()

Moto · 12 okt 2010

Maar als ik dees zie dan vraag ik mij ook wel af wat het nut nog is.
//parse
$this->parse()

Dat bedoel ik dus met duidelijk geschreven code

Als ge OOP begint te programmeren op een project waar meerdere mensen aan werken en dat enorm veel klasses begint te omslaan dan is commentaar echt wel onontbeerlijk. Of ge nu megaduidelijke code schrijft of niet.

commentaar op zich is idd nodig, maar niet volgens een policy per functie of per class of *gasp* per regel

Het is vooral nodig bij workarounds + zaken die niet logisch lijken, of vrij moeilijke stukken dat het echt nodig is, voor interne libraries zie ik bv ook niet het nut voor elke functie van commentaar te voorzien omdan een documentje te genereren, liever dan een paar voorbeelden van hoe de library te gebruiken.

Wolfr · 12 okt 2010

Beter te veel commentaar dan te weinig. Ik ga akkoord met je parse voorbeeld, dit is inderdaad overbodig, maar als je de gewoonte hebt van alles te documenteren gaan moeilijkere stukken wél gedocumenteerd zijn. Je moet ergens een lijn trekken.

0n3Liner · 12 okt 2010

Net wat we nodig hebben! Nog één... Voor persoonlijk wat aan te kloten geen problee he, aar koaan leer keer werken et de bestaande? Of zorgen jullie er zo voor dat klanten bij jullie vastzitten?

Raad eens welke letter kapot is...

dJeez · 12 okt 2010

0n3Liner zei:
Net wat we nodig hebben! Nog één... Voor persoonlijk wat aan te kloten geen problee he, aar koaan leer keer werken et de bestaande? Of zorgen jullie er zo voor dat klanten bij jullie vastzitten?

Innovatie mag wel hoor, zeker als de bestaande op bepaalde gebieden schromelijk tekortschieten. Neem nu meertaligheid in Drupal, dat is gewoon de achilleshiel, en het is imho onbegrijpelijk dat daar niet meer aandacht aan besteed wordt - en al zeker voor een CMF dat zich als corporate oplossing wil opwerpen. Idem dito met display names trouwens, de eerste vraag daarnaar dateert van eind 2006 (Add a Display Name field to core in addition to Username | drupal.org), en nu - 4 jaar later - is daar eigenlijk - buiten wat halfslachtige, onvolledige dingen - nog steeds niks mee gebeurd, ondanks dat er enorm veel mensen naar vragen. Maar anderzijds heeft het ook wel zijn voordelen natuurlijk - zeker naar eindgebruikers toe kan je enorm veel met CCK, Views en Panels zonder 1 letter code te schrijven (performantie even buiten beschouwing gelaten

).

Los daarvan : Fork CMS zal het zeker niet worden voor mij, ik ben verknocht aan het Zend Framework ondertussen, en zal dus eerder voor een CMS opteren dat gebaseerd is op ZF (TomatoCMS zal ik wel eens bekijken denk ik).

Om terug te komen op de opmerkingen in verband met commentaar : nuttige commentaar die effectief iets bijbrengt is idd geen overbodige luxe, maar te veel nutteloze commentaar is ronduit idioot... Ik zou de tijd die je daaraan spendeert dan eerder in unit testing steken.

BTW Highcharts? Dat is toch niet gratis voor commercieel gebruik? Waar melden jullie dat, want dat is toch een vereiste volgens hun licentievoorwaarden?

Tyfius · 12 okt 2010

dJeez zei:
Innovatie mag wel hoor, zeker als de bestaande op bepaalde gebieden schromelijk tekortschieten. Neem nu meertaligheid in Drupal, dat is gewoon de achilleshiel, en het is imho onbegrijpelijk dat daar niet meer aandacht aan besteed wordt - en al zeker voor een CMF dat zich als corporate oplossing wil opwerpen. Idem dito met display names trouwens, de eerste vraag daarnaar dateert van eind 2006 (Add a Display Name field to core in addition to Username | drupal.org), en nu - 4 jaar later - is daar eigenlijk - buiten wat halfslachtige, onvolledige dingen - nog steeds niks mee gebeurd, ondanks dat er enorm veel mensen naar vragen. Maar anderzijds heeft het ook wel zijn voordelen natuurlijk - zeker naar eindgebruikers toe kan je enorm veel met CCK, Views en Panels zonder 1 letter code te schrijven (performantie even buiten beschouwing gelaten ).

Voor DisplayName kan ik je ergens volgen, al heb je dat met de Profile module snel opgelost.

En voor die meertaligheid, welke zijn de problemen die je ervaart? Ik heb een aantal meertalige websites die Drupal 6 draaien en ik heb daar toch niet echt problemen mee.

Archief - Lancering Open Source CMS: Fork CMS

netlash

Legacy Member

little

Legacy Member

Tyfius

Legacy Member

adrianhates

Legacy Member

Wolfr

Legacy Member

robbie7

Legacy Member

netlash

Legacy Member

krulle3

Legacy Member

Drone

Legacy Member

adrianhates

Legacy Member

Wolfr

Legacy Member

j design

Legacy Member

tijsverkoyen

Legacy Member

Moto

Legacy Member

Zero Grav

Legacy Member

Moto

Legacy Member

Wolfr

Legacy Member

0n3Liner

Legacy Member

dJeez

Legacy Member

Tyfius

Legacy Member