phpbattle-work

[Phpbattle-work] Stop: "we NEED rules!?!"

[David D. <go...@gm...>]

Ich hab grade mit Daniel (der leider mit seinem Puretec Account nicht an die 
Mailinglist mailen kann und auch am Sonntag nicht im Chat war) gesprochen und 
er hat mich von einer Sache überzeugt:
Wir brauchen strikte Regeln was den Aufbau der Module angeht...eigentlich den 
Aufbau des ganzen Systems.

Beispiele (was mir so einfällt dazu):
* Ordnerstruktur (1 images Ordner für alles o.ä.)
* Konfiguration (wichtig...wir könnten 
http://www.php.net/manual/de/function.parse-ini-file.php benutzen)
* Aufbau der Module selbst (Variablen, Funktionen, Klassen)
* Klassen? (würde ich für die 1. Module vorschlagen)
* Wie wird entschieden welche Module wo und wie geladen werden? (Damit das 
ganze nicht so ausschaut (von oben nach unten auf der Page): News - Forum - 
Userlogin/logout - Administrationsbereicht....alles auf einer Page. dazu wäre 
evtl. nen neuer Modulstatus gut)
* Versionskontrolle/update (automatisieren? ..bisher total außer acht 
gelassen)
* Was ein Modul alles beeinflussen darf/was nicht...wie es eingeschränkt wird
* Anbindung an die Adminschnittstelle

Zudem sollten unsere offiziellen Module guten Support leisten (Admin, Hilfe, 
Sprachunterstützung...alle, ...)

Also, ich bin auf eire Vorschläge gespennt....auch für jede Verbesserung im 
jetzigen Modules Code bin ich dankbar...auch wenn es das ganze System mal 
wieder umwirft (is ja jetzt am Anfang noch möglich).

Alles andere (also auch Module..am Sonntag besprochen) ist daher erstmal 
NEBENSACHE...bitte die Arbeit daren so lange ruhen lassen, bevor man nochmal 
neu beginnen muss :)

Nacher bekomme ich auch von Daniel nochmal eine Zusammenfassung von seinen 
Ideen, die leite ich an euch weiter.....

David

Re: [Phpbattle-work] Stop: "we NEED rules!?!"

[exit <ex...@cl...>]

Also auch mal n Statement von mir.
Das mit dem parse-ini-file find ich echt gut, ini files kann einfach jeder
leicht bedienen und sie sind gut zu benutzen für Optionen.
Ordnerstruktur wäre eine einheitliche wichtig, also zb alle hauptmodule in
"modules" und die dann untergliedern für andere dinge.
OOP ist nicht so schwer wie sich's anhört. Klassen in PHP sind wirklich
einfach zu verstehn und ich denke nicht das jemand von euch damit Probleme
haben könnte - ich mein ich habs auch gelernt ^^
Wir können uns ja schließlich jederzeit helfen - kein Thema.
Versionen sind auch nicht schlecht, ich würd sagen jedes Script (Modul) von
uns, bekommt ne eigene Versions-Nummer und evtl eine Nummer vom Hauptmodul,
das es benötigt um zu laufen (Kompatibilität).


Grüße, Flo
alias exit

Webmaster
ex...@cl...
www.ClanzWorld.net



----- Original Message -----
From: "David Danier" <go...@gm...>
To: <php...@li...>
Sent: Tuesday, October 15, 2002 3:57 PM
Subject: [Phpbattle-work] Stop: "we NEED rules!?!"


> Ich hab grade mit Daniel (der leider mit seinem Puretec Account nicht an
die
> Mailinglist mailen kann und auch am Sonntag nicht im Chat war) gesprochen
und
> er hat mich von einer Sache überzeugt:
> Wir brauchen strikte Regeln was den Aufbau der Module angeht...eigentlich
den
> Aufbau des ganzen Systems.
>
> Beispiele (was mir so einfällt dazu):
> * Ordnerstruktur (1 images Ordner für alles o.ä.)
> * Konfiguration (wichtig...wir könnten
> http://www.php.net/manual/de/function.parse-ini-file.php benutzen)
> * Aufbau der Module selbst (Variablen, Funktionen, Klassen)
> * Klassen? (würde ich für die 1. Module vorschlagen)
> * Wie wird entschieden welche Module wo und wie geladen werden? (Damit das
> ganze nicht so ausschaut (von oben nach unten auf der Page): News -
Forum -
> Userlogin/logout - Administrationsbereicht....alles auf einer Page. dazu
wäre
> evtl. nen neuer Modulstatus gut)
> * Versionskontrolle/update (automatisieren? ..bisher total außer acht
> gelassen)
> * Was ein Modul alles beeinflussen darf/was nicht...wie es eingeschränkt
wird
> * Anbindung an die Adminschnittstelle
>
> Zudem sollten unsere offiziellen Module guten Support leisten (Admin,
Hilfe,
> Sprachunterstützung...alle, ...)
>
> Also, ich bin auf eire Vorschläge gespennt....auch für jede Verbesserung
im
> jetzigen Modules Code bin ich dankbar...auch wenn es das ganze System mal
> wieder umwirft (is ja jetzt am Anfang noch möglich).
>
> Alles andere (also auch Module..am Sonntag besprochen) ist daher erstmal
> NEBENSACHE...bitte die Arbeit daren so lange ruhen lassen, bevor man
nochmal
> neu beginnen muss :)
>
> Nacher bekomme ich auch von Daniel nochmal eine Zusammenfassung von seinen
> Ideen, die leite ich an euch weiter.....
>
> David
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpbattle-work mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpbattle-work
>

Re: [Phpbattle-work] Stop: "we NEED rules!?!"

[David D. <go...@gm...>]

> Versionen sind auch nicht schlecht, ich würd sagen jedes Script (Modul) von
> uns, bekommt ne eigene Versions-Nummer und evtl eine Nummer vom Hauptmodul,
> das es benötigt um zu laufen (Kompatibilität).

Und genau das ist der Punkt weshalb ich nochmal zum Komplettstop aufgerufen 
habe...
Wenn wir Abhängigkeiten auch über Versionsnummern laufen lassen müssen wir 1. 
ein System bauen, was Ausdrücke wie 0.0.3 oder (schwieriger) 0.0.5-r2 richtig 
auseinanderhält (wenn wir bloß auf die Haupfversionnummern (ohne RC) achten 
dürfte das aber kein Problem sein) und 2. muss das Hauptmodul so 
umgeschrieben werden, dass alles damit klappt (Eigentlich wollte ich pro 
$mod_need Eintrag bloß eine Variable speichern, mal sehn was sich machen 
lässt).

David

Re: [Phpbattle-work] Stop: "we NEED rules!?!" --> Versionskontrolle

[David D. <go...@gm...>]

> Und genau das ist der Punkt weshalb ich nochmal zum Komplettstop aufgerufen
> habe...
> Wenn wir Abhängigkeiten auch über Versionsnummern laufen lassen müssen wir
> 1. ein System bauen, was Ausdrücke wie 0.0.3 oder (schwieriger) 0.0.5-r2
> richtig auseinanderhält (wenn wir bloß auf die Haupfversionnummern (ohne
> RC) achten dürfte das aber kein Problem sein) und 2. muss das Hauptmodul so
> umgeschrieben werden, dass alles damit klappt (Eigentlich wollte ich pro
> $mod_need Eintrag bloß eine Variable speichern, mal sehn was sich machen
> lässt).

So, die aktuelle Version MIT Versionskontrolle ist im CVS. Ich denke das kann 
man noch optimieren, aber soweit läuft es :D
(-rcX Versionen können noch nicht verarbeitet werden...schaut euch einfach 
meine Beispiele an)

So bekommt ihr die aktuelle CVS Version geladen:
-----
cvs -d:pserver:ano...@cv...:/cvsroot/phpbattle 
login

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/phpbattle 
co phpbattle
-----

Wie was unter Windows läuft weiß ich leider nicht :(

Falls jemand von euch Probleme mit dem CVS hat, ich habs nochmal hochgeladen 
in den Sourceforge Webspace: 
https://sourceforge.net/project/showfiles.php?group_id=64490
(Version 0.0.2-rc2)

David

Re: [Phpbattle-work] Stop: "we NEED rules!?!"

[David D. <go...@gm...>]

> Beispiele (was mir so einfällt dazu):
> * Ordnerstruktur (1 images Ordner für alles o.ä.)

/images/$modulename/....
/modules/$modulname/..... (load.php, conf.php, ....)
/uploads/$modulename/.... (falls benötigt)
/admin --> Index vom Administrationsbereich
/admin/$modulename (jeweiliger Admin, Index liest den Ordner nur aus um zu 
wissen welche Module administriert werden können)
 ^ admin ok so?

Wem fällt hier noch mehr ein?

> * Konfiguration (wichtig...wir könnten
> http://www.php.net/manual/de/function.parse-ini-file.php benutzen)

4 Arten fallen mir jetzt ein:
1. Simpler Aufbau:
--------
<?
$var = 1;
$var2 = 'toll';
?>
--------
2. INI Files (siehe Link oben)
3. MySQL (dann bräuchte aber jedes Modul auch MySQL)
4. was komplett eigenes (keine Idee was man da machen könnte)

Was meint ihr???

> * Aufbau der Module selbst (Variablen, Funktionen, Klassen)

- Wenn Modul nur aus einer Klasse besteht:
  Klassenname = Modulname
- Variablen kommen immer in einen Array mit Modulnamen
- Funktionen sollten den Modulnamen vorrangestellt haben

--> Am besten sind klassen, weil da alle Funktionen und Variablen IN der 
Klasse definirt sind, es gibt also weniger Probleme

> * Klassen? (würde ich für die 1. Module vorschlagen)

Sinnvoll, z.b. für MySQL --> 2 MySQL Verbindungen

> * Wie wird entschieden welche Module wo und wie geladen werden? (Damit das
> ganze nicht so ausschaut (von oben nach unten auf der Page): News - Forum -
> Userlogin/logout - Administrationsbereicht....alles auf einer Page. dazu
> wäre evtl. nen neuer Modulstatus gut)

Darum kümmert sich am besten nen Modul, oder?

> * Versionskontrolle/update (automatisieren? ..bisher total außer acht
> gelassen)

Siehe Script, eure Meinung dazu?

> * Was ein Modul alles beeinflussen darf/was nicht...wie es eingeschränkt
> wird

Eigentlich darf es alles machen, was die Funktionalität nicht einschränkt...

-->
$modules Variable sollte nicht angerührt werden
Variablen andere Module auch nicht
Es darf sich nicht über das Modulesscript setzen und dieses "abschalten"

> * Anbindung an die Adminschnittstelle

Siehe oben....
Das Aussehen der Modulkonfiguration sollten wir aber anpassen.


Viele Grüße, David
(ich hoff ma wieder auf ne Antwort :D )