Plugin architectuur

    • FangorN wrote:

      Om vast te kunnen stellen of de gekozen oplossingsrichting juist is is het misschien handig om ons te vertellen wat je precies probeert te bereiken.

      Nu zeg je min of meer "ik heb een hamer gekozen, hoe moet ik deze gebruiken" terwijl de daadwerkelijke klus die je probeert uit te voeren het snoeien van de heg is.

      Zoals een van de reacties op SO ook opmerkt:
      I would ask for you to give more information of the nature of php app your writing, And how you see plugins fitting in.

      In mijn optiek ben ik toch vrij duidelijk. Ik heb research gedaan, maar vind teveel informatie om er echt wegwijs uit te worden. Een van de gevonden design patterns heb ik naar voren gehaald, omdat deze in mijn ogen het best is voor wat ik wil.

      Wat wil ik dan juist? Ik ben op zoek naar een manier om plugins in een ongeschreven script te implementeren. Het uiteindelijke doel is om zoveel mogelijk vrijheid te behouden. Ik wil dus functionaliteiten toe kunnen voegen die ik misschien helemaal niet had bedacht, m.a.w. voorbedachte hooks lijken mij geen oplossing. Mijn vraag was dan ook:

      Victor wrote:

      Heeft iemand een mening hierover? Waarom dit bijvoorbeeld bad practise is of juist een goede strategie. Andere 'patterns' zijn ook zeer welkom!

      Hoe specifiek moet ik worden als ik een abstract iets wil maken?
      Met vriendelijke groet,

      Victor
      Beheerder ICTscripters
    • Je kunt code niet eindeloos abstract houden. Op een gegeven moment moet deze iets concreets doen. En dan moet je tot op zekere hoogte vastleggen hoe iets werkt en wat iets doet / kan doen m.a.w. je zult een aantal ontwerpbeslissingen moeten nemen die dit vastleggen, je offert altijd "vrijheid" op naarmate je applicatie concreter wordt (specifiekere zaken doet).

      Je case is op dit moment veel te algemeen. Je wilt iets maken dat modulair is en schaalbaar met als uiteindelijk doel dat iets (onder andere?) forward compatible is. Uhm, sorry dat ik het zo zeg, maar dat is eigenlijk gewoon de manier waarop je in het algemeen (object georiënteerde) code zou moeten schrijven?

      Op een gegeven moment moet je de stap abstract > concreet maken anders zal je code nooit iets concreets doen.

      Wat versta jij precies onder plugins (hoe zou dit in de praktijk eruit moeten zien)? Om die vraag te kunnen beantwoorden is het ook wel handig als je weet waarvoor je de plugins precies schrijft? In wat voor behoefte voorzien deze? Er bestaat niet zoiets als een universeel programmeer recept (er zijn nu eenmaal verschillende oplossingen voor verschillende vraagstukken, is ook de reden dat er meerdere design patterns bestaan), noch zijn plugins per definitie de oplossing voor jouw specifieke probleem, wat deze ook moge zijn.
    • Hoe ik het nu voor me zie, maar dit is verder dus nog allemaal ongeschreven, is dat ik als het ware een soort basis CMS heb van waaruit ik plugins kan inladen om de functionaliteiten uit te breiden. Deze plugins zijn packages met een standaard opzet en dependencies, etc.
      Zo kan ik voor ieder project andere plugins aankruisen en hoef ik deze er dus niet in te programmeren. Voor het ene project zou ik een userlogin willen hebben en voor het ander juist een betalingsysteem.
      Ik wil de basis ook echt tot de basis beperken, zodat ik qua plugins alle vrijheid behoud. Zo zou ik graag ook de basis cms zelf nog willen kunnen aanpassen met de plugins. (E.g. functies toevoegen als gebruikers beheren, etc.)

      Iets duidelijker?
      Met vriendelijke groet,

      Victor
      Beheerder ICTscripters
    • Is voor wat je nu wilt doen het extenden van classes en/of het hebben van een soort van "core" en "application" directory (laatstgenoemde directory wordt eerst gecontroleerd op classes) niet afdoende? Classes zijn van zichzelf al prima uitbreidbaar mits je je bedient van protected (en niet van final)?

      En wie zou dit aan moeten kunnen passen/uit moeten kunnen breiden, en in hoeverre mag dit programmeerbaar zijn? Je zou ook gewoon hele sobere core-modules kunnen hebben, wat sowieso wel een goed idee is om je codebase een beetje klein te houden.