Fusebox/FLiP voor PHP, J2EE, CFM, Project Aanpak

[Config]

Ok, na een mislukte start in dit topic: [rml][ PHP] Architecture/Project Opzet/Structuur[/rml], hier nog even een 'rematch' .

Ik wil het dus hebben over architectuur, project management, contact met clienten enzo. Ik bedoel: laten we eens met onze IT koppen boven coding uitkomen, en ons bezighouden met echt programmeren: analyseren, ontwerpen en implementeren.

Ik heb iets in deze trant gevonden: Fusebox. Het is in principe een framework voor het creeeren van (grote) webbased applicaties onder een aantal talen (PHP, CFM en J2EE).

Daarnaast is er FLiP. Dit is een soort gedachtengang zeg maar, een filosofie if you like. Die beschrijft stap voor stap hoe je zoiets moet aanpakken.

Nu zou ik graag hierover verder gaan . Zoals in bovenstaand topic staat moet ik een erg grote e-commerce CMS bouwen in PHP/(MySQL || PostgreSQL). Ik zou het graag breed aanpakken: filestructuur, moduleren, OOP model, optimizing met Zend, caching, scalability, documentation, snel coden, snelle code coden, etc etc!

Database optimizing! Zie ook http://www.databasejourna...mysql/article.php/1382791. Ik zie dat soort dingen hier nou noooit. Geen optimizing, geen normal form, geen DK/NF...niks! . Ik zou graag meer leren over DB design . (heb al het SQL leerboek en Leerboek Databases hiervoor aangeschaft, maar boeken zeggen ook niet alles)

XML/XSL! Ik wil XML gebruiken bij dat project, en waarschijnlijk ook XSLT. Iemand ervaring hiermee? Links? boeken? Gimme!

Come on let's make us some professional code here . Tis afgelopen met dat gepeuter .

[Verwijderd]

Ik heb _erg_ lang naar een juiste ontwikkelmethode gezocht voor dergelijke projecten. Ik loop nu stage en ik mag een Intranet ontwikkelen voor een bedrijf (100 - 150 werknemers). Ik heb op school SDM geleerd maar daar heb je niet echt veel aan bij zulke projecten. Maar omdat ik niet te veel tijd aan het zoeken naar een methode wou verspillen heb ik het toch min of meer via SDM gedaan.

Is het niet een idee om een soort eigen methode op te zetten? Gewoon hierin alle dingen die WIJ belanmgrijk vinden in een dergelijk traject. Ik ben er wel voor om ook eens iets tegen dat gepeuter te doen!

[Verwijderd]

Wat me trouwens wel opvalt is dat je het toch erg veel hebt over de technische kant van het verhaal. Je geeft zelfs al aan welke technieken je wilt gaan gebruiken. Dit is pas iets voor in de fase na de definitiestudie om je daar pas voor het eerst druk over te gaan maken. En over het implementeren zeg je ook weinig. Of wil je ook roll-out technieken opnemen? Evaluatie methoden?

[Config]

Precies .

Hier is iig mijn schema over hoe ik de technieken ga samenvoegen:



En hier wat toelichting:

· Database: Genormaliseerde MySQL of PostgreSQL database in de 4e normaalvorm. Deze moet uitvoerig geoptimaliseerd zijn en mag geen anomaliën bevatten. Er wordt gewerkt met views, indexes, etc.
· SQL: Set PHP scripts, zorgen voor alle database input/output. Dit is de enige speler die de database direct mag aanspreken.
· Processing: Set PHP scripts, met gebruik van classes, includes, templates, functies etc. Deze scripts vormen de zogenaamde 'Business Logic'. Hier wordt de content in bepaald, interactie met de bezoeker geregeld etc. Hierin bevindt zich ook de Administrator.
· Opmaak: In deze files wordt de presentatie van de XML data gedefinieerd. Er moet een keuze worden gemaakt uit Cascading Style Sheets 1 en 2, en XSLT. De browser gebruikt deze sheets om de informatie correct weer te geven.
XML: De XML datafiles die worden gegenereerd door de Processing unit. Deze bevatten puur de data die op de site wordt gebruikt. Tezamen met verschillende Opmaak profielen wordt de site opgebouwd. Met deze scripts is het dus ook mogelijk compleet andere sites te maken, met dezelfde content. Hiermee is verregaande spreiding van de doelgroep mogelijk.

[Config]

Verwijderd schreef op 05 november 2002 @ 10:41:
Wat me trouwens wel opvalt is dat je het toch erg veel hebt over de technische kant van het verhaal. Je geeft zelfs al aan welke technieken je wilt gaan gebruiken. Dit is pas iets voor in de fase na de definitiestudie om je daar pas voor het eerst druk over te gaan maken. En over het implementeren zeg je ook weinig. Of wil je ook roll-out technieken opnemen? Evaluatie methoden?

Wat zijn roll-out technieken? Ik heb toch veel System Design gehad op de Hogeschool maar daar nog nooit van gehoord .

Ik wil het zowel over de technische als de abstractere kant hebben. Maar ik ben meer bekend met de technische kant zeg maar. Ik denk dat die kant ook groter is (het ontwerpen, systeemeisen bepalen, etc etc) is meer dan documentatie, presentatie voor de klant etc. Begrijp me goed: het coden zelf komt wat mij betreft niet aan bod, wat ik WEL wil behandelen is de filosofie zeg maar, hoe je opmaak van data scheidt, hoe je classes en functies moet gebruiken, etc.

[Verwijderd]

Config schreef op 05 november 2002 @ 10:46:
Wat zijn roll-out technieken? Ik heb toch veel System Design gehad op de Hogeschool maar daar nog nooit van gehoord

Hoe wil jij de gebruikers inleiden met je product? Ik moet mijn toekomstige gebruikers nu al er op attent maken dat er een intranet komt, ik moet het management vertellen dat er echt winst te behalen is, ik moet zorgen dat het niet een eendagsvlieg wordt.

Dat bedoel ik met de roll-out.

[Verwijderd]

Config schreef op 05 november 2002 @ 10:46:
[...]
Ik wil het zowel over de technische als de abstractere kant hebben. Maar ik ben meer bekend met de technische kant zeg maar. Ik denk dat die kant ook groter is (het ontwerpen, systeemeisen bepalen, etc etc) is meer dan documentatie, presentatie voor de klant etc.

Het bepalen van de systeemeisen is bij mij absoluut niet technisch. Wat moet het systeem doen als er een gebeurtenis is. Als je hierbij al de techniek gaat betrekken dan krimp je de mogelijke oplossingen al geweldig in. Als de klant cq. opdrachtgever een website wilt die een raket kan besturen dan zet je dat gewoon bij de systeemwensen en eisen. Of het haalbaar is bepaal je later pas als je de techniek hebt gekozen. En de techniek kies je weer bij de wensen en eisen.... tenminste zo zie ik dat....

[Config]

Verwijderd schreef op 05 november 2002 @ 10:49:
[...]

Hoe wil jij de gebruikers inleiden met je product? Ik moet mijn toekomstige gebruikers nu al er op attent maken dat er een intranet komt, ik moet het management vertellen dat er echt winst te behalen is, ik moet zorgen dat het niet een eendagsvlieg wordt.

Dat bedoel ik met de roll-out.

In mijn geval zit dat wel goed, ik werk er op dit moment al, en iedereen weet dat het gaat komen

Maaar daar nemen we geen genoegen mee. Er moeten methodes/ideeen komen over hoe je dat gestandaardiseerd aan moet pakken. Hoe gaan we werken? Als er genoeg mensen mee willen doen kunnen we wel iets opzetten .

[Config]

Verwijderd schreef op 05 november 2002 @ 10:54:
[...]

Het bepalen van de systeemeisen is bij mij absoluut niet technisch. Wat moet het systeem doen als er een gebeurtenis is. Als je hierbij al de techniek gaat betrekken dan krimp je de mogelijke oplossingen al geweldig in. Als de klant cq. opdrachtgever een website wilt die een raket kan besturen dan zet je dat gewoon bij de systeemwensen en eisen. Of het haalbaar is bepaal je later pas als je de techniek hebt gekozen. En de techniek kies je weer bij de wensen en eisen.... tenminste zo zie ik dat....

Ja ik vond het al dubieus toen ik het typte...De (niet-)functionele systeemeisen horen inderdaad neit bij de technische kant. Dat onderdeel heb ik geleerd uit mijn mooie UML boekje . (aanrader).

[Config]

Nog een onderwerp (technisch):

Hal: What are you mad about?

Steve: About documentation. About commenting code, which we're told we should do "for posterity". Well, I would like to volunteer this statement for posterity: I hate documenting my code. I spent a lot of time this week looking at old code--some of it mine--and it was unpleasant. Lots of inline comments that told me exactly nothing about the application itself or the individual code files I was working on.

Hal: Ah, now I understand. You're talking about comments like

<!--- looping over array --->

Steve: Exactly! Moronic stuff. Duh. I know what a loop looks like. But WHY are you looping over this query or array or list or structure or whatever? That's what I want to know. And most comments just state the obvious. I hate inline comments. They never made any sense to me. Most programmers hate putting them in, but we do it anyway. Why? Because we've been told until we're sick of hearing it that "you should document your code". So we do. Nobody really knows why and it sure doesn't offer much help to people maintaining our code, but we waste a lot of time doing it. I mean, which is better--reading a bunch of half-baked comments that clutter up code or reading the code itself?

Bron: http://www.secretagents.c...action=free.conversation8

So true!

[Verwijderd]

Config schreef op 05 november 2002 @ 11:07:
Nog een onderwerp (technisch):
So true!

"The evil sister of developing is documentation"

[Verwijderd]

Het lijkt me idd nuttiger om hier een soort algemene discussie te houden, zodat we er allemaal wat aan hebben, en volgens mij is het vooronderzoek te specifiek om hier te bespreken als algemeen model.

Wat mij betreft beginnen we bij het ontwerp van het systeem (ff voor de duidelijkheid dan slaan we dus onderzoek en analyse in dit topic over).

[edit]
Volgens mij is dat ook de insteek van Fusebox (cmiiw)

[Verwijderd]

Ok, ik trap af:

Config schreef op 05 november 2002 @ 10:03:
...
XML/XSL! Ik wil XML gebruiken bij dat project, en waarschijnlijk ook XSLT. Iemand ervaring hiermee? Links? boeken? Gimme!
...

Waarom wil je XML / XSLT gebruiken, en gebruik je niet gewoon templates (zie vorig topic).
Ik gebruik in mijn applicaties *geen* xml, maar ik genereer gewoon html.

[Config]

Zoals ik al zij in mijn vorige topic, is dat meer iets gedwongen (niet dat ik het erg vindt). Mijn stagebegeleider kickt daar gewoon op (X*). Plus dat het erg handig is omdat je op deze manier meerder frontends (lees: websites) kan maken met dezelfde backend code! Het is altijd nog optioneel wat ik met die XML doe, misschien zet ik het wel om naar HTML met XSLT, en krijgt de browser dus nog steeds plain HTML.

[Verwijderd]

Config schreef op 05 november 2002 @ 11:41:
Plus dat het erg handig is omdat je op deze manier meerder frontends (lees: websites) kan maken met dezelfde backend code!

Met html is dat (uiteraard) ook zeer goed te doen, ik denk (nee kheb nog niet zoveel met xml gedaan, maar ok) dat xml uitvoeren iets veel moeilijkers is dan direct html.

Hmm, slechte uitleg

[Config]

Maar toch snap ik je wel hoor . Maar XML stelt 'mijn' bedrijf in staat binnen een week een compleet 'nieuwe' site neer te zetten (die door taalgebruik/layout/inhoud/) een totaal andere doelgroep bereikt, met dezelfde admin! En dezelfde database! PLUS dat je data en opmaak 100% moet scheiden, wat resulteert in meer werk, maar veel betere projecten.

[joostdiepenmaat]

Allereerst Config, ik ben het helemaal met je gedachtengang eens taz van hetgeen je wilt opzetten en op welke manier. Vaak wordt er hier op GoT wat code geschreven zonder er van tevoren over na te denken. Goed analyseren, ontwerpen, implementeren, testen zou veel mensen goed doen...... Wil je snel en efficient aan grotere projectjes werken dan is het echt verstandig om serieus over dit soort zaken te gaan nadenken!

Ik heb iets in deze trant gevonden: Fusebox. Het is in principe een framework voor het creeeren van (grote) webbased applicaties onder een aantal talen (PHP, CFM en J2EE).

Daarnaast is er FLiP. Dit is een soort gedachtengang zeg maar, een filosofie if you like. Die beschrijft stap voor stap hoe je zoiets moet aanpakken.

Ik heb 't eens bekeken en ziet d'r opzich leuk uit. Iedere standaard die je gebruikt is beter dan geen standaard! Dus waarom niet...... Er zijn diverse frameworks voor dit soort projecten. Mijn ervaring is dat niet altijd elk framework even handig werkt. Is het de bedoeling dat je meerdere projecten gaat doen? Dan is het zeker verstandig om je in het framework te gaan verdiepen en een goede standaard te gaan ontwikkelen .... Andere dingen die hierbij een rol spelen zijn natuurlijk: het aantal developers nu, in de toekomst, verandering technologie, compatibiliteit met andere talen etc. Het is voor een bedrijf het beste om EEN goede standaard te hebben!

Nu zou ik graag hierover verder gaan . Zoals in bovenstaand topic staat moet ik een erg grote e-commerce CMS bouwen in PHP/(MySQL || PostgreSQL). Ik zou het graag breed aanpakken: filestructuur, moduleren, OOP model, optimizing met Zend, caching, scalability, documentation, snel coden, snelle code coden, etc etc!

Als je weet wat je moet doen, rolt je code d'r zo uit!

Database optimizing! Zie ook http://www.databasejourna...ysql/article.php/1382791. Ik zie dat soort dingen hier nou noooit. Geen optimizing, geen normal form, geen DK/NF...niks! . Ik zou graag meer leren over DB design . (heb al het SQL leerboek en Leerboek Databases hiervoor aangeschaft, maar boeken zeggen ook niet alles)

Database Systems, C.J. Date

XML/XSL! Ik wil XML gebruiken bij dat project, en waarschijnlijk ook XSLT. Iemand ervaring hiermee? Links? boeken? Gimme!

het topic 'waarom XML?' heeft hier al uitvoerig over gediscusseerd. Ik heb voor m'n eigen CMS besloten dat ik XML alleen gebruik voor externe sources...DWZ, vanuit m'n CMS gebruik ik php+mysql om direct m'n html, wap, i-mode, etc. te genereren. In het CMS kunnen XML files aangemaakt voor export functies. Voor externe sources dus.....

Come on let's make us some professional code here . Tis afgelopen met dat gepeuter .

I'd rather fail with quality than succeed with garbage!

[joostdiepenmaat]

Jongens laten we nou eens een fatsoenlijk software engineerings topic voortzetten! zo'n beetje al dit soort topics worden direct afgekapt. Sta op uit de codeklopperij en ga in hemelsnaam eens op een fatsoenlijke manier software maken (geld niet voor iedereen trouwens.......)

[Verwijderd]

deepman schreef op 05 november 2002 @ 19:36:
Jongens laten we nou eens een fatsoenlijk software engineerings topic voortzetten! zo'n beetje al dit soort topics worden direct afgekapt. Sta op uit de codeklopperij en ga in hemelsnaam eens op een fatsoenlijke manier software maken (geld niet voor iedereen trouwens.......)

Kijk, dat wil ik ook.
In het vorige topic heb ik dan ook mijn manier van werken weergegeven, en ik weet dat daar heus wel dingen beter aan kunnen, maar die structuur vind ik gewoon ideaal werken.

Laten we eerst eens opstellen wat we met dit topic willen bereiken, en laten we een soort stappen plan aflopen.

[Verwijderd]

Ik wou eerst mijn project doen met IAD.... alleen was daar zooo weinig informatie over te vinden dat ik wel met SDM moest want dat heb ik geleerd en mijn stage heeft ook een einde...

Waar ik dus vooral beniewd naar ben zijn de volgende dingen:

• Hoe leg je de huidige situatie vast?
• Hoe leg je de wensen en eisen vast met het oog op een web applicatie?
• Hoe ontwerp je een web applicatie op papier?

Als we echt gaan beginnen dan lijkt het me ook wel makkelijk om eenduidig de begrippen analyseren, ontwerpen en implementeren te omschrijven...

want is ontwerpen nou het op papier maken van een applicatie of is dit de GUI en de code?

[Verwijderd]

analyseren: vaststellen van de informatiebehoefte / systeemeisen (wat)
ontwerpen: welke technieken gebruiken we (mysql of postgre, enz) (hoe)

[Config]

De standaard ontwikkelmethodes zijn denk ik niet geschikt voor webdevelopment. Dit omdat een CMS als die ik moet maken continue moet worden gewijzigd, aangepast, etc. (zie bijv. ook de T.net devtracker).

Misschien zou iemand van T.net, Fok, of een grote online shop wat meer licht op dit onderwerp kunnen laten schijnen? Hoe zit de structuur in elkaar (niet de code die interesseert me niet zo)? Hoe programmeer je dat? Hoe documenteer je het?

Iemand die femme wil mailen?

[Config]

Resource! http://www.webgoeroe.net/item/882

[Verwijderd]

Nog een:
http://misrc.umn.edu/work...pers/2001/0132_100101.pdf

Kijk vooral eens naar het schema 12b.... die techniek bevalt me eigenlijk wel... gestructureerd en webbased....

[Config]

Verwijderd schreef op 06 november 2002 @ 12:00:
Nog een:
http://misrc.umn.edu/work...pers/2001/0132_100101.pdf

Kijk vooral eens naar het schema 12b.... die techniek bevalt me eigenlijk wel... gestructureerd en webbased....

Lijkt wel een boek man, is het wel gratis? .

Anyway, ik ben het aan het lezen