[PHP/Java] Besparen bij het implementeren van veel classes?

[Config]

Momenteel ben ik een systeem aan het maken dat voor het grootste gedeelte bestaat uit een hoop classes die een directe relatie tot fysieke objecten heeft. Nu loop ik al een tijdje mee in het PHP wereldje, maar ik heb nog geen framework gezien wat je in staat stelt om vanuit metadata te kunnen werken. Telkens weer moet je de classes aanmaken en elk stukje logica invoeren, en elk formuliertje maken, en elk admin formuliertje maken, etc.
Natuurlijk zijn er dingen als PEAR:DB die wat dingen vergemakkelijken en encapsuleren, maar echt spannend wordt het vooralsnog niet.

Is er iets in PHP of in Java (Java mag, omdat ik er geen probleem mee zou hebben om de business logic daarin te hebben, met PHP als front-end en Smarty voor de presentatie) dat mij het werk van ophalen van data uit de database, wegschrijven, authorisatie, zoeken, verwijderen van records, relaties (deze auto is van persoon X, deze dakpan ligt op dit dak), etc. uit handen neemt? Het is zo'n vreselijke bezigheid om telkens maar weer opnieuw het wiel uit te moeten vinden. Graag zou ik meer met metadata (beschrijvingen) werken.

[ibmos2warp]

Misschien zoek je een framework zoals cakephp, of zoals Muscrerior hieronder zegt CodeIgniter.

[ Voor 50% gewijzigd door ibmos2warp op 20-10-2007 15:37 ]

[Muscrerior]

[fanboy]
Pssst...CodeIgniter
[/fanboy]

[ Voor 12% gewijzigd door Muscrerior op 20-10-2007 15:34 ]

[Config]

* Config gaat ff kijken

[orf]

[fanboy]
Pssst...Zend Framework
[/fanboy]

[Config]

orf schreef op zaterdag 20 oktober 2007 @ 16:01:
[fanboy]
Pssst...Zend Framework
[/fanboy]

Ik ben geen expert op het gebied van ZF, maar volgens mij is dat toch iets teveel een set van losse modules/componenten voor allerlei standaardproblemen.

Ik zoek specifiek iets waartegen je kunt zeggen: Een huis(object) bestaat uit een aantal verdiepingen(relatie met objecten), met kamers (idem), en alle objecten hebben allerlei eigenschappen. En dan wordt mijn code dus bijvoorbeeld:

//definities
House =>
name => housetype //een eigenschap
type => enum
options => appartment, studio
relation => Room, 1:N //een relatie

Room =>
...

//business logic
$array["type"] => "studio";
$found = house::find($array);
while(..) {
$house->set(...,...);
$house->save();
}

..kortom, waar je heel declaratief bezig bent, en je alleen zegt wat je wil, en zo min mogelijk hoe je dat wil.

[Config]

FYI, SugarCRM heeft deze "Meta based UI" best aardig uitgewerkt. In Sugar roep je gewoon wat voor eigenschappen je over een object wil bijhouden. Sugar maakt de formulieren voor je, alsook de zoekformulieren. Ook kun je zelf de data uitkiezen die je wil zien (kolommen, sortering) etc. Echter, Sugar is niet handig als framework, aangezien het uitbouwen van deze logica uit SugarCRM zelf een groot karwei zou zijn.

[B-Man]

Dan kom je vwb de DB zaken uit bij een ORM (o.a. Propel of ezpdo).

Als je ook wilt dat formulieren voor Create Read Update Delete (CRUD) in grote lijnen automatisch gegenereerd worden, kun je kijken naar een framework wat z.g.n. scaffolding voor je doet, zoals RubyOnRails klonen voor PHP, bijboorbeeld CakePHP en PHP on Trax.

[ Voor 3% gewijzigd door B-Man op 20-10-2007 17:21 ]

[Config]

Thnx guys, vooral ezpdo spreekt mij enorm aan . Het simpelweg zeggen "Author has many Book", het automatisch persistent houden van je foreign keys en het automatische saven aan het eine van je script is gewoon retegaaf . Ohw, vergeet trouwens niet het aanspreken van objecten als arrays.

$book;
$author;
-->
<?
$author['book'] = $book;
?>
..en je relatie is vastgelegd

Dit vat mijn (vage) verhaal van mijn OP hierboven samen: http://www.phparch.com/issuedata/articles/article_185.pdf

[StephanL]

Ik zie laatste tijd dat er veel word gesmeten met frameworks als oplossingen voor het goed organiseren van php code.

Ik heb juist het idee dat zo'n framework erg omslachtig werkt. Je moet zo'n framework van voor naar achter leren kennen om er alles uit te halen. Je hebt de code niet in eigen beheer en naar mijn mening ga je er niet netter van programmeren. Ook heb ik het idee dat wanneer je je code terug bekijkt als je die met frameworks heb gemaakt dat je geen idee hebt wat het code doet.

Het voordeel als je alles zelf programmeert is dat je weet hoe het is gemaakt en vooral hoe het in elkaar steekt en waar alles staat. Het belangrijkste dat je van elke regel code weet wat er staat.

Ok ik doe mijn bevindingen niet omdat ik ervaring heb met bepaalde frameworks, maar gebaseerd op de tutorials van de verschillende frameworks. Misschien ben ik er nog niet klaar voor, maar vooralsnog heb ik het idee dat het niet mijn ding is.

[Config]

Ieder zijn ding natuurlijk!

Voor wat betreft mijzelf: ik zie mijzelf eerder als een implementeerder/ontwerper van processen, dan als een coder. Ik werk wel graag met een framework (ik was zelf al bezig met een soortgelijk iets, wat natuurlijk nooit zo goed als een algemeen framework zou zijn geworden, gezien de hoeveelheid developers die meelezen en de tijd die erin is gestoken) omdat ik mijn visie graag werkelijkheid wil zien worden. Het programmeren is voor mij slechts een reis, niet de bestemming.

Mijn toekomstvisie: we zullen steeds meer willen zeggen wat we willen, en niet hoe. Binnenkort gaan we deze frameworks grafisch gebruiken, waarbij we objecten en relaties kunnen maken met knoppen, pijltjes, etc. Daarna wellicht ook de business logic zelf, al is dat weer een stap verder. Dit laat ons weer nadenken over functionaliteit en klantgerichtheid, i.p.v. onderliggende kleinere zaken. Natuurlijk moet de onderliggende code wel goed in elkaar zitten, en daar ligt ook zeker nog een taak voor coders. Maar degene die het eindprodukt maakt, zal niet te lang stil staan bij de preciese werking van de code.

Als je dit leest, en je bent het ontzettend oneens met mij, omdat je alle controle en flexibiliteit wil behouden, dan mag dat natuurlijk. Maar vergeet SQL niet: het is toch opmerkelijk dat sommigen aan de PHP kant een grote neiging tot controle willen behouden, terwijl ze voor wat betreft hun database gewoon uitgaan van wat hun dbms ze aanreikt...

[Verwijderd]

Config schreef op zondag 21 oktober 2007 @ 13:06:
...

Mijn toekomstvisie: we zullen steeds meer willen zeggen wat we willen, en niet hoe. Binnenkort gaan we deze frameworks grafisch gebruiken, waarbij we objecten en relaties kunnen maken met knoppen, pijltjes, etc. Daarna wellicht ook de business logic zelf, al is dat weer een stap verder.

...

Zal ik jou eens wat leuks vertellen? Dit bestaat al! Echter niet open source. De beste manier van werken is door het wiel geheel zelf uit te vinden. Bekijk alle frameworks, en pak alleen die facetten waarvan jij vindt dat ze goed zijn. Neem de ideeen over, maar bouw zelf iets waarover jij tevreden bent. Het framework en de code generator die wij binnen ons bedrijf gebruiken is zelf ontwikkeld. Zo blijf je juist de flexibiliteit behouden die je wilt.
Wanneer je werkt met een willekeurig framework, dan zal je inderdaad naar verloop van tijd merken dat je Delete action, je Edit action, je Add action er allemaal nagenoeg hetzelfde uitzien. Ook je formuliertjes, je javascript validatie, je server side validatie, de popupjes voor het koppelen van relaties. Na drie projecten merk je dat je gewoon een ordinaire knip en plak programmeur bent geworden van je eigen oude code. Dat is het moment dat je systemen ontwikkelt waarvan de user interface dusdanig uitgedacht is, dat je merkt dat je constant hetzelfde doet. Tegen die tijd wil je je systeem op een veel hoger abstractie niveau definieren. Boeiend dat je niet 100% kan genereren, zolang je 80% kan genereren is dat altijd nog een dikke vette winst.

In feite definieer je nu al wat je wil, en hoe je het gaat doen is van latere zorg. Je begint altijd met een omschrijving als; een Boek heeft meerdere Auteurs, een Auteur heeft meerdere Boeken. Een Boek behoort tot een Categorie.
Als ik dit zou lezen, zie ik de user-interface die ik wil hebben direct voor me. In het verleden, toen we nog geen code generator hadden, zakte me de moed soms in de schoenen. ORM classes schrijven! User interfaces voor toevoegen, bewerken, verwijderen, zoeken, overzicht gaap! Validatie... error views, user input controlleren. Whaaaaa. Op dit moment beschrijven we op abstract niveau in XML de database structuur. Aan de hand daarvan worden de ORM classes en een User Interface XML bestand gegenereerd. Daarin kan je wijzigingen aanbrengen, en vervolgens de UI en Actions genereren. Voorbeeld:

XML:

<?xml version="1.0" encoding="UTF-8"?>
<modules>
    <module name="crm">
        <model>
            <entity name="company">
                <attribute name="name" type="String" />
                <attribute name="website" type="URI" />
                <attribute name="email" type="Email" />
                <has-many entity="employee" />
            </entity>
            <entity name="employee">
                <attribute name="name" type="String" />
                <attribute name="salary" type="Money" />
                <attribute name="dateOfBirth" type="Date" />
                <belongs-to entity="company" />
            </entity>
        </model>
    </module>
</modules>

Klein gedeelte van ui.xml die gegenereerd wordt door model.xml. Je kan bv een column weghalen uit je datagrid (overzicht), aangezien je daar vaak niet alle velden wil zien, maar slechts een paar. Dat vereist dan natuurlijk wel enige handmatige aanpassing in je ui.xml.

XML:

<?xml version="1.0"?>
<ui>
    <entity name="company">
        <action name="companyOverview">
            <toolbar>
                <item><invoke action="companyAdd" /></item>
            </toolbar>
            <errorMessages />
            <datagrid>
                <columns>
                    <invoke action="companyDelete" />
                    <invoke action="companyEdit" />
                    <invoke action="companyView" />
                    <!-- a company has many employee -->
                    <invoke action="employeeOverviewRestrictOnCompany" />
                    <column>name</column>
                </columns>
            </datagrid>
        </action>
        <action name="companyAdd">
            <toolbar>
                <item><invoke action="companyOverview" /></item>
            </toolbar>
            <errorMessages />
            <form id="companyForm">
                <fieldset>
                    <field type="String" required="required">name</field>
                    <field type="String">website</field>
                    <field type="String">email</field>
                </fieldset>
                <fieldset>
                    <!-- vanwege de prefix List, weet de generator dat je 
                    meerdere werknemers kan koppelen aan een bedrijf. 
                    Wil je het koppelen van werknemers niet doen bij het 
                    toevoegen van het bedrijf, dan kan je dit natuurlijk 
                    handmatig uit de ui.xml weghalen... Vooral handig 
                    als je een boek toevoegt, en je meteen de schrijvers 
                    wil koppelen, etc. -->
                    <field type="ListEmployee">employee</field>
                </fieldset>
            </form>
        </action>
    </entity>
</ui>

Op zo'n abstract niveau beschrijven levert een aantal zeer belangrijke voordelen op. Je bouwt in 2 uur wat je voorheen minstens 40 uur kostte. Wat je genereert is goed, en veilig (onder de aanname dat je generator goede en veilige code uitspuugt). Zo blijft alles consequent en sluipen foutjes er minder snel in. De portabiliteit is enorm. Je kan genereren naar Java, .NET, PHP. Het enige wat je hoeft te doen is de generator templates aan te passen. Begin klein, en bouw het groter uit.

Config, ik wil hiermee aangeven dat wat jij voorziet in de toekomst, nu al realiteit is. EfBe werkt, ik meen, ook aan een project voor code genereren voor Java projecten. Weet niet precies wat ze doen, want ik heb er nooit echt diep naar gekeken. Ik hoop dat deze post mensen aan het denken zet over hun manier van ontwikkelen, en ik hoop dat dit wellicht anderen ook aanspoort dergelijke frameworks en code generators te schrijven.

[Config]

Thnx Quist . Ik heb dit soort CASE tools al in werking gezien ja . Echter, niet in open source (die lopen altijd achter - kunnen pas wat maken als iemand anders het heeft voorgedaan (en ja, meestal beter dan het origineel).

Het probleem is natuurlijk dat het in PHP niet bestaat (er bestaat heel veel niet), en dat is nu juist het taaltje dat zo lekker snel ontwikkelt . Ik mag hopen dat ook PHP'ers hun neiging naar het doelloos willen beheren van elke byte die door hun systeem gaat, overboord zetten .

[Jorick]

Ik kwam laatst iets tegen wat mij zelf wel interessant lijkt en misschien iets is wat waar de TS naar opzoek is: PHPOpenBiz.
Ik heb helaas nog geen tijd gehad om er mee aan de slag te gaan maar was wel onder de indruk van de flash tutorial. Vooral die Eclipse plugin en dat het meta based is sprak mij erg aan in het filmpje!

[ Voor 10% gewijzigd door Jorick op 22-10-2007 00:21 ]

[B-Man]

Verwijderd schreef op zondag 21 oktober 2007 @ 14:19:
[...]

Ik ben het maar deels met je eens op dit vlak. Mits je de kwaliteiten en tijd hebt, kun je ervoor kiezen om zelf een framework te programmeren. Heb ik ook gedaan, en dat werkte meer dan 5 jaar prima voor me. De laatste jaren ben ik echter afgestapt van PHP, en daarmee ook van een eigen framework naar tools/frameworks van derden.

Neem als voorbeeld Hibernate (third-party ORM voor Java/.NET). Ik heb 5 jaar gewerkt met een eigen ORM geschreven in PHP, wat prima bevallen is. Echter zat ik wel met een flinke berg code die ik enkel zelf gebruik, zelf moet onderhouden, zelf moet uitbreiden. Door third-party tools te gebruiken, die door een veel grotere community ontwikkeld, onderhouden en in productie gedraaid worden, hoef ik me daar niet meer mee bezig te houden.

Ik bedoel: waarom het wiel constant opnieuw blijven uitvinden als er meer dan genoeg stabiele tools zijn die per direct beschikbaar zijn? Tuurlijk, die kunnen vermoedelijk niet de 100% die je wil hebben, maar 90-95%. Ik dacht lange tijd dat ik het zelf beter kon maken, en die 5% dan ook in mijn zak had. Nu zie ik het anders: ik kan die 5% ook bouwen als add-on/component voor bestaande tools, zodat ik op 99-100% uitkom, in veel minder tijd.

Een aantal van mijn argumenten om bijna alles zelf te programmeren waren:
- Ik heb zelf een aantal specifieke use-cases, daarom is mijn eigen code vrijwel altijd sneller en efficienter. Tegenwoordig maakt dit veel minder uit omdat Hardware geen drol meer kost.
- Flexibiliteit: ik wilde dat ik er precies mee kon doen wat ik voor me zag, en niet wat volgens de tool "logisch" is. Tegenwoordig draai ik het om: vaak heb ik wel een bepaald idee, maar door het in context van verschillende tools te zien, is het met een tool vaak net zo goed, zoniet beter op te lossen.
- Alle ins&outs kennen. Ik wilde precies weten wat alle code deed, daarom schreef ik ook een eigen ORM, een eigen MVC framework, CMS, enz. Net zoals velen hier denk ik Tegenwoordig wil ik het gewoon niet meer weten in een aantal gevallen! Neem een tool als Hibernate, daar zit ontzettend veel complexiteit in geabstraheerd achter een simpele doch krachtige interface. Ik prik een paar bestanden erbij in mijn project, voeg wat annotaties toe aan mijn objecten, restart de applicatieserver, et voila, mijn database staat klaar.

Concluderend: als ik het bericht van Quist lees, kan ik enkel zeggen: wat jullie zelf gebouwd hebben kan prima met bestaande tools. Neem een nette ORM, pak een component based MVC framework, en wat resteert is zelf een scaffolding mechanisme te maken, of indien gewenst een simpele generator. Vermoedelijk bestaan die ook, en dan voldoen ze vermoedelijk ook nog aan universele standaarden, zodat je niet gebonden bent aan je eigen systeem.

-- Toevoeging: ik zeg er voor de duidelijkheid even bij dat ik de afgelopen jaren wel verschoven ben van kleine MKB klanten naar de top van het MKB, en daarmee met heel andere requirements zit.

[ Voor 3% gewijzigd door B-Man op 22-10-2007 10:58 ]

[Config]

Thnx B-men en Jorick voor de informatieve replies . Ik ga zeker eens kijken naar PHPObenBiz, Eclipse is mijn favo platform trouwens .

Ik ben ook zeker geinteresseerd in andere reacties/visies, andere alternatieven en ervaringen, en evt. zelfs boeken etc .

NB: ik heb zelf ook CMSen en fora e.d. gebouwd. Maar dat is toch echt meer om de taal zelf te leren (met deze frameworks gaat je dat niet lukken). Playtime is over .

[Verwijderd]

B-Man schreef op maandag 22 oktober 2007 @ 10:54:
[...]


Ik ben het maar deels met je eens op dit vlak. Mits je de kwaliteiten en tijd hebt, kun je ervoor kiezen om zelf een framework te programmeren. Heb ik ook gedaan, en dat werkte meer dan 5 jaar prima voor me. De laatste jaren ben ik echter afgestapt van PHP, en daarmee ook van een eigen framework naar tools/frameworks van derden.

...

Concluderend: als ik het bericht van Quist lees, kan ik enkel zeggen: wat jullie zelf gebouwd hebben kan prima met bestaande tools. Neem een nette ORM, pak een component based MVC framework, en wat resteert is zelf een scaffolding mechanisme te maken, of indien gewenst een simpele generator. Vermoedelijk bestaan die ook, en dan voldoen ze vermoedelijk ook nog aan universele standaarden, zodat je niet gebonden bent aan je eigen systeem.

-- Toevoeging: ik zeg er voor de duidelijkheid even bij dat ik de afgelopen jaren wel verschoven ben van kleine MKB klanten naar de top van het MKB, en daarmee met heel andere requirements zit.

Er zijn weinig tools waarvan ik zeg; wauw. Wanneer je inderdaad wisselt van platform heb je heel veel kennis die je opnieuw moet opdoen. Alles opnieuw ontwikkelen voor een nieuw platform is erg tijdrovend omdat je constant moet nagaan wat werkt en wat niet werkt.
Voor PHP is er in mijn ogen geen enkel framework dat aan mijn wensen voldoet. Overal kan ik wel iets bedenken. CakePHP, ZF, CodeIgniter en ga zo maar door. Punt is natuurlijk wel dat wanneer je niet alleen werkt, zelf ontwikkelen prima kan. Iemand die verantwoordelijk is voor het MVC Framework, de ORM etc. Wanneer je ontwikkelt voor de top van het MKB dan sta je inderdaad voor andere problemen, aangezien andere eisen gesteld worden aan de software. Dan *moet* je bijvoorbeeld met Hibernate werken en perse Oracle huppeldepup gebruiken. De klant bepaalt dan. Zolang ik daar niet mee werk, vind ik liever lekker het wiel zelf uit. Zo krijg ik ook inzicht in de werking van bepaalde kritieke onderdelen, mocht ik later over willen stappen op 3th party modules.
Het probleem van een default scaffolder of code generation framework (ik ken er slechts een paar), is dat je meteen gebonden bent aan de mogelijkheden van de desbetreffende tool. Ik wil dat handmatige wijzigingen behouden blijven wanneer ik de code opnieuw genereer nadat ik een paar kleine wijzigingen gemaakt heb aan het model. Bij standaard tools krijg je in het beste geval veel te veel functionaliteit en in het slechtste geval net niet genoeg wat je nodig hebt. En niet zelden hanteren ze weer een andere coding conventie dan die ik hanteer. De gegenereerde code gebruikt underscores ipv camel caps. Wat je ook doet, doe het consequent.
Mijn punt is. Op dit moment werk ik in een markt waarbij het aantal werknemers dat gebruik maakt van de software die ik maak doorgaans onder de 25 blijft. Alle web applicaties die ik maak voldoen aan dezelfde user interface. Of dat nou een klein CRM pakket is toegespitst op de wensen van de desbetreffende klant, of een systeem voor de veiligheidsregio om risicovolle en kwetsbare objecten te beheren. Het liefst zie ik dan dat 80% van alle code inclusief ORM classen, HTML formulieren en overzichten, Javascript validatie, Actions etc, in een klap gegenereerd wordt. Nogal het schoenmaker-blijf-bij-je-leest verhaal. Standaardiseer je manier van werken sterk, en kijk vervolgens of je die standaardisatie kan automatiseren. Ik doe nu in 2 uur wat mij voorheen minstens 40 uur kostte. Hierdoor kunnen veel hogere marges behaald worden. Geld waarmee je weer nieuw gave dingen kan ontwikkelen...Een bedrijf als Q42 die alles in-house ontwikkelt, de gaafste technologie levert, zal bij mij altijd een voorkeur genieten boven de knip-en-plak bedrijven die moduletje-hier-moduletje-daar aan elkaar lijmen. Let wel, om nu niet elke J2EE professional en .NET goeroe boos te maken; er zijn inderdaad gewoon markten waarin je niet alles zelf kan maken, en dan is het logisch dat je gebruik maakt van het werk van derden.

[B-Man]

Verwijderd schreef op dinsdag 23 oktober 2007 @ 16:46:
[...]

Volgens mij zijn we het met elkaar eens

Als je maar een flexibile manier van werken hebt, en er mensen (let op: meervoud) zijn die ermee kunnen werken, en het kunnen uitbreiden, dan zit je sowieso goed. Mijn punt is vooral: vind het wiel niet opnieuw uit waar dat niet nodig is.

Ik kom nog vaak zat situaties tegen waarin ik teruggrijp naar maatwerk, maar laat dat 10% van de projecten zijn. Voor die 10% wil ik zelf eigenlijk ook geen framework meer onderhouden, en blijven moderniseren. Dit is volgens mij vooral een kwestie van de markt waarin je als webdeveloper opereert. En natuurlijk ook: met wie je werkt. Als je samenwerkt met freelancers of meer algemeen: derden, dan moet je al vrij snel naar standaardisatie m.b.v. standaardtooling. Als je intern met een club mensen werkt op basis van een eigen platform, en er geen problemen ontstaan wanneer een of twee mensen wegvallen (om wat voor reden dan ook), prachtig.

Maar we raken offtopic volgens mij

[LauPro]

Het enige dat ik wil toevoegen aan de discussie is dat standaardizering de productie en bedrijfszekerheid zeker kan vehogen. Maar het geeft de klant daarintegen vaak wel meer speelruimte om te wisselen van dienstverleners. Dus in mijn optiek zou je zeker het onderdeel "vendor lockin" moeten meenemen in deze discussie. Ook bij open source projecten is er vaak sprake van een vendor lockin, maar deze is dan meestal een stuk goedkoper.

[WouZz]

Kijk ook eens naar MMBase. Java CMS waarin je aan de hand van een XML config je modellen en relaties kan definieren. Bijgeleverd zitten standaard editors en zogenaamde 'edit wizzards'. Zodra je je webapp hebt draaien kun je ook 'nodes' en 'relations' aanmaken via de API. Voordelen zijn dat het open source is en op veel databases draait. Nadeel is de vrij stijle leercurve.