Guggat emol Blog » Weight-Modell backen

Weight-Modell backen

Roland — Tue, 25 Oct 2011 22:53:01 +0000

Nachdem die Personen nun ein Modell (user.php) haben, wollen wir noch die Gewichtsangaben in ein Modell gießen.
Dazu gehst du wieder in das Verzeichnis /app und rufst wieder ../cake/console/cake bake auf.

Welcome to CakePHP v1.3.10 Console

---------------------------------------------------------------

App : app

Path: /home/roland/workspace/weightapplication/app

---------------------------------------------------------------

Interactive Bake Shell

---------------------------------------------------------------

[D]atabase Configuration

[M]odel

[V]iew

[C]ontroller

[P]roject

[F]ixture

[T]est case

[Q]uit

What would you like to Bake? (D/M/V/C/P/F/T/Q) 

> M   

---------------------------------------------------------------

Bake Model

Path: /home/roland/workspace/weightapplication/app/models/

---------------------------------------------------------------

Use Database Config: (default/test) 

[default] > 

Possible Models based on your current database:

1. User

2. Weight

Enter a number from the list above,

type in the name of another model, or 'q' to exit  

[q] > 2

Diesmal bin ich gleich bis zu den Modellen durchgegangen und gebe die 2 für Weight ein.

[q] > 2

A displayField could not be automatically detected

would you like to choose one? (y/n) 

> y

1. id

2. user_id

3. weight

4. created

Choose a field from the options above:  

> 3

Diesmal erkennt Cake Console nicht welche Felder wir später anzeigen lassen wollen. Wir wählen das Gewicht.
Danach generieren wir wieder die Validierungen.

Für id:

> 3

Would you like to supply validation criteria 

for the fields in your model? (y/n) 

[y] > 

Field: id

Type: integer

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[29] >

Für User-ID


[29] > 

Field: user_id

Type: integer

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[20] >

Hier wollen wir keine weiteren Validierungen.
Für unser Gewicht wollen wir notempty verwenden:

[n] > 

Field: weight

Type: float

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[29] > 19

created lassen wir wie es ist:

[n] > 

Field: created

Type: timestamp

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[29] >

Die Relation zur User-Tabelle ist eine BelongsTo-Relation. Die werden wir mit den folgenden Einträgen erstellen:

[29] > 

Would you like to define model associations

(hasMany, hasOne, belongsTo, etc.)? (y/n) 

[y] > 

One moment while the associations are detected.

---------------------------------------------------------------

Please confirm the following associations:

---------------------------------------------------------------

Weight belongsTo User? (y/n) 

[y] >

Weitere Relationen brauchen wir nicht.
Es wird uns nochmal angezeigt wie das Modell wohl aussehen wird.

[y] > 

Would you like to define some additional model associations? (y/n) 

[n] > 

---------------------------------------------------------------

The following Model will be created:

---------------------------------------------------------------

Name:       Weight

DB Table:   `weights`

Validation: Array

(

    [user_id] => Array

        (

            [numeric] => numeric

        )

    [weight] => Array

        (

            [notempty] => notempty

        )

)

Associations:

	Weight belongsTo User

---------------------------------------------------------------

Look okay? (y/n) 

[y] >

Auch die Simpletests können wir vorbereiten lassen und fertig ist die Installation.

[y] > 

Baking model class for Weight...

Creating file /home/roland/workspace/weightapplication/app/models/weight.php

Wrote `/home/roland/workspace/weightapplication/app/models/weight.php`

SimpleTest is not installed. Do you want to bake unit test files anyway? (y/n) 

[y] > 

You can download SimpleTest from http://simpletest.org

Baking test fixture for Weight...

Creating file /home/roland/workspace/weightapplication/app/tests/fixtures/weight_fixture.php

Wrote `/home/roland/workspace/weightapplication/app/tests/fixtures/weight_fixture.php`

Bake is detecting possible fixtures..

Creating file /home/roland/workspace/weightapplication/app/tests/cases/models/weight.test.php

Wrote `/home/roland/workspace/weightapplication/app/tests/cases/models/weight.test.php`

---------------------------------------------------------------

Interactive Bake Shell

---------------------------------------------------------------

[D]atabase Configuration

[M]odel

[V]iew

[C]ontroller

[P]roject

[F]ixture

[T]est case

[Q]uit

What would you like to Bake? (D/M/V/C/P/F/T/Q) 

>

So, jetzt haben wir für die Tabellen users und weights angelegt.

User-Modell für den Datenbankzugriff in CakePHP backen

Roland — Sun, 23 Oct 2011 22:49:40 +0000

In CakePHP gibt es Konsoleapplikationen mit denen du ohne großen Aufwand Modelle, Controller und Views erstellen kannst.
Für unsere Gewichtsapplikation werden wir zuerst die Modelle erstellen.

Wechsle in das Verzeichnis /app der Gewichtsapplikation.
Dort rufst du mit ../cake/console/cake bake die Bäckerei auf.
Wie du sehen kannst, sind die Konsoleanwendungen von Cake im Verzeichnis /cake/console hinterlegt. Schau einfach mal rein.
Wenn du den Aufruf durchgeführt hast, erscheint folgende Auswahl:

Welcome to CakePHP v1.3.10 Console

---------------------------------------------------------------

App : app

Path: /home/roland/workspace/weightapplication/app

---------------------------------------------------------------

Interactive Bake Shell

---------------------------------------------------------------

[D]atabase Configuration

[M]odel

[V]iew

[C]ontroller

[P]roject

[F]ixture

[T]est case

[Q]uit

What would you like to Bake? (D/M/V/C/P/F/T/Q) 

>

Hier kannst du auswählen was du backen willst.
Wir wollen zuerst unsere Modelle backen, also geben wir M ein.
Die nächste Frage lautet ob wir unsere Modelle anhand der Definitionen der Default-Database-Connection oder der Test-Connection erstellen wollen.

> M       

---------------------------------------------------------------

Bake Model

Path: /home/roland/workspace/weightapplication/app/models/

---------------------------------------------------------------

Use Database Config: (default/test) 

[default] >

Hier kannst du return drücken, da wir die default-Konfiguration nehmen wollen.
Als nächstes werden die Tabellen, die derzeitig in der Datenbank definiert sind, angezeigt:

[default] > 

Possible Models based on your current database:

1. User

2. Weight

Enter a number from the list above,

type in the name of another model, or 'q' to exit  

[q] >

Jetzt lassen wir die Modelle erstellen. Du gibst hierfür die 1 und 2 ein.
Fangen wir also mit 1 an:

[q] > 1   

Would you like to supply validation criteria 

for the fields in your model? (y/n) 

[y] >

Die Modell-Attribute können mit Standard-Validierungen überprüft werden.
Wir wollen das der Name und die E-Mail Adresse korrekt eingegeben werden.
Also sagen wir ja (return)
Das erste Feld ist die id.
Hier werden folgende Optionen angeboten:

[y] > 

Field: id

Type: integer

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[29] >

Mit 29 (also return) geben wir an, dass wir keine besondere Überprüfung für dieses Feld durchführen wollen.

Als nächstes wird das Feld name angezeigt.

[29] > 

Field: name

Type: string

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[19] >

Die Cake Console ist ziemlich clever und schlägt und notempty vor. Also machen wir das so.
Als nächstes fragt Die Cake Console uns ob wir weitere Überprüfungen durchführen wollen. Hier können wir vorerst mit Return (also nein) weitergehen.

[n] > 

Field: email

Type: string

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[10] >

Das nächste Feld ist die E-Mail Adresse. Hier erkennt Cake Console dass wir eine valide E-Mail Adresse eingeben wollen (also irgendwas mit BLA@BLUB.LULL).
Wir akzeptieren die 10.
Die Frage, ob wir noch weitere Validierungen angeben wollen, beantworten wir diesmal mit y.
Jetzt geben wir noch isUnique als Validierungsregel an. Damit wird erreicht, dass jede E-Mail Adresse im System einmalig ist.

[10] > isUnique

Would you like to add another validation rule? (y/n) 

[n] >

Jetzt können wir wieder return drücken.

Das letzte Feld, mit zu überprüfenden Eigenschaften, ist das Passwort.
Hier können wir z.B. eine Minimallänge vorgeben.

[19] > 16

Would you like to add another validation rule? (y/n) 

[n] >

Die Beschreibung lassen wir optional.

[n] > 

Field: description

Type: text

---------------------------------------------------------------

Please select one of the following validation options:

---------------------------------------------------------------

1 - alphanumeric

2 - between

3 - blank

4 - boolean

5 - cc

6 - comparison

7 - custom

8 - date

9 - decimal

10 - email

11 - equalto

12 - extension

13 - inlist

14 - ip

15 - maxlength

16 - minlength

17 - money

18 - multiple

19 - notempty

20 - numeric

21 - phone

22 - postal

23 - range

24 - ssn

25 - time

26 - url

27 - userdefined

28 - uuid

29 - Do not do any validation on this field.

... or enter in a valid regex validation string.

[29] >

Als nächstes werden wir gefragt ob wir Verknüpfungen zu anderen Modellen haben wollen.
Hier sagen wir ja, denn wir wollen unsere Personen mit vielen Gewichtsangaben versehen.

[29] > 

Would you like to define model associations

(hasMany, hasOne, belongsTo, etc.)? (y/n) 

[y] >

Wenn du return drückst wird die weights Tabelle angezeigt. Diese beinhaltet eine user_id und kann daher eine Relation zu unserer users-Tabelle haben.

[y] > 

One moment while the associations are detected.

---------------------------------------------------------------

Please confirm the following associations:

---------------------------------------------------------------

User hasMany Weight? (y/n) 

[y] >

Wir sagen bei dieser Frage ja (return)

[y] > 

Would you like to define some additional model associations? (y/n) 

[n] >

Hier bleiben wir bei nein.
Als letztes wird uns angezeigt was wir da so zusammenkonfiguriert haben:

[n] > 

---------------------------------------------------------------

The following Model will be created:

---------------------------------------------------------------

Name:       User

DB Table:   `users`

Validation: Array

(

    [name] => Array

        (

            [notempty] => notempty

        )

    [email] => Array

        (

            [email] => email

            [isUnique] => isUnique

        )

    [password] => Array

        (

            [minlength] => minlength

        )

)

Associations:

	User hasMany Weight

---------------------------------------------------------------

Look okay? (y/n) 

[y] >

Das sieht gut aus! Also sagen wir ja.

[y] > 

Baking model class for User...

Creating file /home/roland/workspace/weightapplication/app/models/user.php

Wrote `/home/roland/workspace/weightapplication/app/models/user.php`

SimpleTest is not installed. Do you want to bake unit test files anyway? (y/n) 

[y] >

Wie du sehen kannst, wird das Modell user.php in das Verzeichnis /app/models/users.php geschrieben.
Die Frage ob wir die Unit-Tests für unser Modell erstellen wollen, können wir mit ja beantworten. Dann können wir später mit SimpleTest alles durchtesten.

Jetzt wird alles fertiggestellt und wir kommen wieder zur Startseite.

[y] > 

You can download SimpleTest from http://simpletest.org

Baking test fixture for User...

Creating file /home/roland/workspace/weightapplication/app/tests/fixtures/user_fixture.php

Wrote `/home/roland/workspace/weightapplication/app/tests/fixtures/user_fixture.php`

Bake is detecting possible fixtures..

Creating file /home/roland/workspace/weightapplication/app/tests/cases/models/user.test.php

Wrote `/home/roland/workspace/weightapplication/app/tests/cases/models/user.test.php`

---------------------------------------------------------------

Interactive Bake Shell

---------------------------------------------------------------

[D]atabase Configuration

[M]odel

[V]iew

[C]ontroller

[P]roject

[F]ixture

[T]est case

[Q]uit

What would you like to Bake? (D/M/V/C/P/F/T/Q) 

>

Hier brechen wir mit Q ab und schauen uns zuerst unser Modell an.
Gehe zur Validierung des Passworts und ändere die Validierung so ab, dass wir eine Minimallänge von sechs Zeichen vorsehen:

		'password' => array(

			'minlength' => array(

				'rule' => array('minlength', 6),

				//'message' => 'Your custom message here',

				//'allowEmpty' => false,

				//'required' => false,

				//'last' => false, // Stop validation after this rule

				//'on' => 'create', // Limit validation to 'create' or              'update' operations

			),

Alle anderen vorgefertigten Definitionen lassen wir vorerst einfach mal so stehen.
Das Modell ist jetzt erst einmal ausreichend konfiguriert.

Namensänderungen im Newssystem Modell

Roland — Wed, 17 Jun 2009 04:03:55 +0000

Ich bin dabei mir ein paar Gedanken zu den Modellen des Newssystems zu machen.
Da ich diesmal CakePHP einsetzen will, habe ich ein paar Fragestellungenzu den Modellnamen zu beantworten.
Beispiel:
Bisher habe ich das Modell, welches die einzelnen News beinhaltet, sinnvollerweise NewsModell getauft.
Nun, in CakePHP gilt die Namenskonvention, dass Modelle im Singular und Controller im Plural definiert werden sollen.
Supi!
News ist zwar eigentlich ein Singular, aber ich habe da ein New und ein “s”.
Also wird das kluge CakePHP mir wohl sagen, dass ich hier einen Plural verwende.

Was habe ich getan?

Bevor ich mit dem CakePHP beim Backen ärger bekomme, habe ich mich entschieden die NewsModel Geschichte einfach umzubenennen.
Im Prinzip ist ja jede News ein Artikel.
Also heist das NewsModel ab sofort ArticleModel.

Was muss jetzt geschehen?

Da wir zur Zeit noch in der Konzeption sind, muss nicht viel umgewandelt werden.
Wir müssen lediglich kurz durch alle Artikel durch, in denen das NewsModel vorkommt.
Dank der Volltextsuche sollte das ja wirklich kein Problem darstellen
Dann ersetzen wir in den Artikeln NewsModel in ArticleModel und schon sind wir auf alle Fälle CakePHP konform.

Blogsoftware verwenden hat Vorteile bei der Dokumentation

Die wirkliche Erkenntnis, die ich dank dieser Aktion erhalten habe, ist das es sich wirklich lohnt ein Content Management System, wie beispielsweise einen Blog, für die Dokumentation zu verwenden.
Da alle Dokumente miteinander verlinkt sind, ist die Suche und das Abändern der einzelnen Artikel kein Problem.
Mit der Kommentarfunktion kann man die Änderungen noch protokollieren und so ist die ganze Dokumentation richtig rund!

Fazit

Diese Aktion hat mir gezeigt, dass ein integriertes Tool für die ganze Dokumentation durchaus seinen Reiz hat.
Wir sollten entsprechend über unsere Anforderungsdokumentation nachdenken.
Wenn wir hier ein anderes Werkzeug einsetzen, werden wir sehr schnell inkonsistente Bezeichnungen erhalten.
Die Inflation bei den Blogeinträgen ist zwar nicht unbedingt schön, aber dann haben wir den ganzen Brei auf einem System.
Wir könnten ja noch über die Anforderungsclusterung nachdenken.
Wir können z.B. alle Anforderungen zu einer bestimmten Komponente, oder zu einem bestimmten Thema, in jeweils einen Artikel schreiben.
Damit werden wir deutlich weniger Artikel erhalten und dennoch alle Anforderungen im Blog ablegen können.
Oder wir freuen uns über die vielen Anforderungsartikel.
Eigentlich macht es ja nichts aus, wenn man in einem Blog ein paar hundert Artikel hat. Man kann über die Cloud, oder über die Serie sehr einfach filtern.

Habt ihr hierzu eine Meinung?

UserModelFactory

Roland — Fri, 01 May 2009 10:54:44 +0000

Im System werden diverse Typen von Anwendern verwaltet. Jeder Anwendertyp erhält eine speziell ausgebildete Klasse.
Damit übergeordnete Klassen sich nicht mit dem Suchen der passenden Klasse herumschlagen müssen, werden wir hierfür eine Factory Klasse einführen.

Diese Factory Klasse definiert die im System bekannten Anwendertypen mit WEBUSER, EDITOR, MASTER_EDITOR und SYSADMIN.
Falls ein Anwendermodell benötigt wird, ruft man die statische Methode getUserModel(userType) auf und initialisiert so die richtige Klasse.

UserModel Beschreibung

Roland — Thu, 30 Apr 2009 17:46:06 +0000

Unser UserModel dient als Basisklasse für alle Anwendertypen.
Wir designen es als Bean in dem die entsprechenden Attribute verwaltet werden.

Attribute des UserModels

Alle Attribute, die für jeden Anwender gespeichert werden müssen, sind hier abgelegt.

name

Der Name des Anwenders. Dieser Name muss mindestens ein Zeichen beinhalten und darf maximal 200 Zeichen lang sein.
Falls kein Name eingegeben wurde, soll mit der Information “Bitte einen Namen eingeben” abgebrochen werden.
Falls der Name zu lange ist, soll mit der Information “Der Name beinhaltet zu viele Zeichen. Bitte korrigieren.” abgebrochen werden.
Zum Setzen des Namens wird setName(name) verwendet.
Zum Auslesen des Namens wird getName() verwendet.

surname

Der Vorname des Anwenders. Dieser Vorname muss mindestens ein Zeichen beinhalten und darf maximal 200 Zeichen lang sein.
Falls kein Vorname eingegeben wurde, soll mit der Information “Bitte einen Vornamen eingeben” abgebrochen werden.
Falls der Vorname zu lange ist, soll mit der Information “Der Vorname beinhaltet zu viele Zeichen. Bitte korrigieren.” abgebrochen werden.
Zum Setzen des Nachnamens wird setSurname(surname) verwendet.
Zum Auslesen des Nachnamens wird getSurname() verwendet.

email

Die E-Mail Adresse muss zumindest einen gültigen Aufbau haben.
Also aaa.bbb@ccc.ddd
oder bbb@ccc.ddd
Falls eine falsch aufgebaute Adresse übergeben wird, muss mit einer Information “Dies ist keine gültige E-Mail Adresse” abgebrochen werden.
Zum Setzen der E-Mail Adresse wird setEmail(email) verwendet.
Zum Auslesen der E-Mail Adresse wird getEmail() verwendet.

loginName

Mit diesem Namen wird sich der Anwender am System anmelden. Der LoginName darf in der gesamten Newssysteminstanz nur einmal vorkommen.
Der LoginName muss mindestens ein Zeichen haben und darf maximal 20 Zeichen beinhalten.
Ein LoginName, wie bienchen87, ist zugelassen.
Falls kein loginName eingegeben wird, soll mit der Information “Bitte geben Sie einen Loginnamen” abgebrochen werden.
Falls der loginName länger als 20 Zeichen ist, soll mit der Information “Bitte einen kürzeren Loginnamen eingeben” abgebrochen werden.
Falls der loginName im System schon vorhanden ist, wird mit der Information “Dieser Loginname ist im System nicht verfügbar, bitte einen anderen wählen.” abgebrochen.
Zum Setzen des login-Namens wird setLoginName(loginName) verwendet.
Zum Auslesen des Login-Namens wird getLoginName() verwendet.

password

Das Passwort wird verschlüsselt abgespeichert.
Das Passwort wird mittels JavaScript auf dem Client verschlüsselt.
Falls ein Webuser angelegt wird, wird kein Passwort angelegt. Der Webuser benötigt kein Passwort um sich am System anzumelden.
Sonst müsste ja jeder Webseitenbesucher sich erst anmelden. Das wäre ziemlich doof
Für das DefaultPassword werden wir ein PropertyModel erstellen, von dem das DefaultPassword zur Laufzeit gezogen werden kann.
Ein Anwender muss sein Passwort nach einer im System hinterlegten Password Change Time wechseln.
Im Fall des UserModels wird der Passwortwechsel nie vorkommen. Das UserModel hat die Berechtigungen eines WEBUSER.
Wenn das Passwort neu gesetzt wird, darf es nicht mit dem aktuellen oder dem zuvor verwendeten Passwort übereinstimmen. Deshalb wird das neue Passwort mit dem oldPassword verglichen.
Hier habe ich die Überprüfung von alten Passwörtern nur auf das aktuelle und das letzte Passwort eingegrenzt. Falls weitere alte Passwörter berücksichtigt werden müssen, muss dies in der abgeleiteten Klasse entsprechend auscodiert werden. Meine Erfahrung sagt jedoch, dass die meisten Kunden gar keine höhere Sicherheit als zwei Passwörter verwenden wollen.
Falls beim Setzen des Passworts kein Passwort eingegeben wurde, wird mit der Informationsmeldung “Bitte Passwort eingeben” abgebrochen.
Falls beim Setzen des Passworts ein bereits verwendetes Passwort eingegeben wurde, wird mit der Informationsmeldung “Passwort schon in Gebrauch, bitte ein anderes verwenden.” abgebrochen.
Je nach Anwendertyp muss dass Passwort eine bestimmte Länge aufweisen. Falls ein zu kurzes Passwort eingegeben wurde, wird mit der Informationsmelung “Bitte längeres Passwort verwenden.” abgebrochen.
Je nach Anwendertyp muss das Passwort einen bestimmten Aufbau (benutzung von Sonderzeichen usw.) aufweisen. Ein Systemadministrator darf also nicht aaaaaaaa als sein Passwort verwenden. Falls ein nicht stark genuges Passwort verwendet wurde, wird mit der Informationsmeldung “Dieses Passwort ist nicht sicher genug, bitte verwenden Sie auch Sonderzeichen.” abgebrochen.
Die Passwortüberprüfung wird pro UserType festgelegt Das bedeutet, dass das UserModel mit WEBUSER Rechten arbeitet. Es wird somit kein User-Passwort überprüft und jeder Anwender erhält Zugriff auf das System.
Beim Einloggen wird mit der Methode checkPassword(loginName, password) geprüft, ob das Passwort vom User korrekt übergeben wurde.
Zum Setzen eines neuen Passworts wird setPassword(password, repeatPassword) verwendet. Hierbei wird auch der Test, ob das Passwort sicher genug ist und nicht mit dem vorigen Passwort übereinstimmt durchgeführt.
Beim Setzen des Passworts muss das neue Passwort zweimal eingegeben werden. Dies wird mit dem Parameter repeatPassword übergeben.
Mit der Methode getPasswordLength() wird die Länge zurückgeliefert, die ein Passwort mindestens haben muss.

passwordAge

Angabe wie alt das aktuelle Passwort ist.
Falls passwordAge älter ist, als das für den jeweiligen User definierte Passwortalter, wird der Anwender aufgefordert sein Passwort zu ändern.

currentLoginTryCount

Falls ein böser Mensch unser System angreifen will, wird er vermutlich mehrmals eine User-Passwort Kombination verwenden. Hier wäre es gut, wenn nach z.B. fünf Versuchen der Account gesperrt wird.
Dann sollte eine entsprechende Mail an den betroffenen User und den Systemadministrator geschickt werden.
Falls ein User sich nach z.B. zwei Versuchen erfolgreich angemeldet hat, wird der Zähler currentLoginTryCount wieder zurückgesetzt.
Bei jedem nicht erfolgreichen Loginversuch wird er um eins erhöht.
Dieser Zähler wird in der Methode checkPassword() verwendet.

Aufgabe

Liebe Ute, lieber Jozo. Dieses UserModel verarbeitet Passwörter in der Basisklasse selbst. Bei unseren bisherigen hirachischen Userverwaltungen haben wir dies außerhalb der User Klasse gehandhabt.
Ich finde die Modellierung in dieser Klasse relativ elegant. Wir brauchen deutlich weniger Verwaltungsklassen.
Komplexe Passwortüberprüfungen, wie in früheren Versionen unseres miradlo Frameworks, können wir durch Programmierung der Klassen abbilden.
Bitte lest euch diese Beschreibung hier genau durch und versucht nachzuvollziehen ob wir hiermit eine saubere Lösung erhalten.
Was für Nachteile hat dieses Vorgehen?
Wie sollen wir bei einem Angriff vorgehen? Ist mein Vorschlag ok oder sollten wir den noch nachbessern?

ImageModel Beschreibung

Roland — Fri, 10 Apr 2009 12:41:41 +0000

Mit diesem Modell werden die Informationen zu einem bestimmten Bild verwaltet.
Jedes Bild wird durch eine ID, einen Namen, einen alternativ darzustellenden Text, einer Beschreibung und dem Typ des Bildes (jpeg, png, gif usw.) beschrieben.

Die Setter und Getter Methoden werden für den Zugriff auf die einzelnen Attribute verwendet. Mit den Setter Methoden wird erreicht, dass kein Mist in das Modell eingeschrieben wird. Folgende Regeln müssen wir beachten:

id

Um die ID zu generieren, wird über die Binärdaten des Bildes ein MD5 Hash Wert erzeugt. Zu diesem Wert wird der aktuelle Timestamp hinzugefügt. Damit wird sichergestellt, dass die ID des Bildes immer eindeutig ist.

name

Ein für den Menschen sprechender Name. Hier können mehrere Bilder den gleichen Namen beinhalten. Der Name darf leer sein.

altText

Ein Text der im HTML dargestellt werden soll, falls z.B. mit Links auf das Dokument zugegriffen wird. Falls kein Bild dargestellt werden kann, soll wenigstens ein alternativer Text angezeigt werden.

type

Angabe um welchen Typ von Bild es sich handelt. Wir sollten hier Konstanten einführe, also gif, jpeg, png und was weiss ich. Es können nicht unendlich viele Grafikformate verarbeitet werden. Der Typ muss einem der vordefinierten Werten genügen.

description

Eine Beschreibung zum Bild. Dieser Text darf leer sein. Mehr als 1000 Zeichen sollte er nicht beinhalten. Eine Beschreibung kann zum Beispiel “Herbert, nachdem er die Katze vom Baum gerettet hat und sich dabei leider viele Schrammen zugezogen hat. Die Katze überlebte unverletzt. Der Baum ist leider gestorben.”

Aufgabe

Häufig fällt bei der Modellierung einer Klasse auf, dass die Anwendungsfälle andere Attribute beschreiben. Damit alles rund wird, muss deshalb nochmals auf den Anwendungsfall zurückgegriffen werden und dieser angepasst werden.
Die Beschreibung des Modells passt nicht mehr mit der Beschreibung der Image-Anwendungsfälle überein. Bitte schau dir die Image-Anwendungsfälle an und lass uns die dortigen Texte korrigieren.

Geschäftsmodelle erkennen

Roland — Wed, 08 Apr 2009 11:14:07 +0000

Wir müssen die Daten für die Newseinträge, den Editor und die Kategorien schlussendlich irgendwie auf dem Server speichern. Damit wir die Datensätze mehr- oder weniger sinnvoll zusammenführen können, müssen wir die bisherigen Beschreibungen analysieren und entsprechend als Strukturen beschreiben.
Diese Strukturierung führt dazu, dass wir die notwendigen Daten in Geschäftsmodelle (Businessmodels) zusammenführen.
Für die Verwaltung der Geschäftsdaten werden wir entsprechende Methoden beschreiben und somit die Daten vor unsinnigen Zugriff schützen.
Und schubs, wir haben ein wohldefiniertes Geschäftsmodell mit allen Abhängigkeiten zu den umliegenen Geschäftsmodellen.
Easy oder?
Wenn du die Anwendungsfälle durchgehst, wirst du feststellen dass bestimmte Komponenten irgendwie zusammengehören.
Bei meinen Businessmodellen schreibe ich in den Namen des jeweiligen Modells und füge als Postfix “Model” hinzu. Dann weiss ich immer, dass es sich bei dieser Klasse um ein Modell handelt.
Ich habe mal einen Versuch gestartet und folgende Datengruppen gefunden:

CategoryModel: Beinhaltet alle Daten die zur Beschreibung einer Kategorie und der dazugehörigen Editoren gehört.
EditorModel: Speichert alle Elemente, die einen Editor umfassend beschreibt.
MasterEditorModel: Hat alle Eigenschaften eines Editor, darf darüber hinaus jedoch noch tollere Sachen mit dem System machen. Die Beschreibung der tolleren Sachen legen wir im MasterEditor ab. Das MasterEditorModel leiten wir vom EditorModel ab.
SysAdminModel: Der Systemadministrator hat wiederum andere Eigenschaften als der Editor. Es bietet sich daher an, ihm ein eigenes Modell zu gönnen.
WebUserModel: Der Webuser hat zwar keine speziellen Daten, die wir abspeichern müssen, jedoch ergibt es Sinn seine Eigenschaften in einer Modellklasse zu kapseln. Wenn wir für dieses Modell keine Daten abspeichern müssen, macht das im Prinzip ja nichts aus. Hauptsache wir können auf ein wohldefiniertes Modell zugreifen.
UserModel: Wir haben einen Editor, einen MasterEditor und einen SysAdmin im System. Von jedem dieser Akteure wollen wir den Vor- und Nachnamen, ein Passwort und einen Loginnamen. Die e-Mailadresse wäre auch noch schick, sonst wird die Kommunikation mit dem Anwender etwas schwierig Aus diesem Grund habe ich die Eigenschaften, die bei jedem UserModell identisch sind, in eine eigene Klasse verbannt. Dann müssen wir das nur einmal programmieren.
NewsListModel: Wir werden (hoffentlich) ganz viele News im System haben. Wenn wir beim Suchen immer durch alle Newseinträge einzeln durchscrollen müssen, werden wir vermutlich Performanceprobleme bekommen. Bei diesem Modell stelle ich mir eine Liste vor, in der die jeweiligen NewsModelle verlinkt werden.
NewsModel: Hier werden die einzelnen Newseinträge abgelegt und verwaltet. Jede News erhält ein solches Modell.
ImageModel: Verwaltet die einzelnen Datensätze eines Bildes. Ein Bild ist ein relativ komplexes Gebilde bei dem der Link zum Bild, der alternative Text und ein Titel abgespeichert werden sollen. Da ist ein Modell sicherlich sinnvoll.
ImageListModel: Einzelne Bilder werden in verschiedenen Newseinträgen vorkommen. Irgendwie habe ich das Gefühl, dass es sinnvoll wäre wenn wir uns die Information, wo ein Bild verwendet wird, irgendwie zugreifbar verwalten. Bei Löschen eines Bildes können wir so darauf hinweisen, dass dieses Bild eigentlich noch benötigt wird. Weiterhin können wir Bilder darstellen, die in keinem Newseintrag verwendet werden. (Hups! ein neuer Anwendungsfall )

Newssytem Daten Modellieren

Roland — Mon, 06 Apr 2009 20:48:49 +0000

Ich bin der Meinung wir können so allmählich mal mit der Datenmodellierung anfangen. Falls sich dann während der Beschreibung unserer technischen Anwendungsfälle noch was ändert, wissen wir ja wo der “Edit” Button ist

Wie gehe ich beim Datenmodellieren vor?

Ich bin da ziemlich einfach strukturiert. Ich nehme die beschriebenen Anwendungsfälle und schau mir an welche Objekte ich mir im System vorstelle.
Diese Objekte stelle ich grafisch, z.B. mit Visio, oder Enterprise Architect, dar. Dann schaue ich mit die Relationen zwischen den Objekten an und sammle aus den Anwendungsfällen heraus die bekannten Attribute.
Kurz gesagt: Ich sichte die bisherigen Definitionen und sammle die zu speichernden Elemente.

Wo fangen wir an?

Ich habe die Beschreibung des Newssystems als Serie gestaltet. Wir können also einfach die Serie aufrufen und den Roman von Anfang an durchlesen.
Wenn du das machst, wirst du über den Artikel Anwendungsfall Add Category stolpern.
Ja wirklich! Ich will das bisher geschriebene wirklich nochmal lesen und anwenden

Was können wir aus der Anwendungsfallbechreibung herausholen?

In dem Anwendungsfall habe ich viele Attribute beschrieben, die wir zum Verwalten haben.

Kategorie ID
Eine eindeutige ID mit der diese Kategorie später in den jeweiligen Seiten aufgerufen werden kann. Wenn diese ID angelegt wurde, kann sie nicht mehr verändert werden. Erst wenn die Kategorie gelöscht wird, wird auch diese eindeutige ID aus dem System entfernt.
Kategorie Bezeichnung
Kurze Bezeichnung anhand derer diese Kategorie wiedergefunden werden kann. Diese Bezeichnung soll nicht länger als 100 Zeichen beinhalten.
Kategorie Beschreibung
Ein freier Text mit dem die Kategorie genauer beschrieben wird. Die Beschreibung soll nicht länger als 1000 Zeichen lang sein.
Editoren der Kategorie
Die einzelnen Editoren, die zu einer Kategorie Texte schreiben dürfen, werden hier aufgelistet. Vom jeweiligen Editor werden die Editor ID hier abgelegt.
Archivsuche
Angabe, ob News die in dieser Kategorie eingetragen wurden, als Archiveinträge dargestellt werden dürfen oder nicht. Falls dieses Attribut gesetzt ist, können News mit den Anwendungsfällen “Navigate Archive News Shortentries” und “Show Archive Newsentry” dargestellt werden. Nicht mehr aktive Newseinträge können ansonsten nur von den Anwendungsfällen “Editor Use Case” eingesehen werden.
Bildgröße
Angabe wie groß ein Bild für diese Kategorie sein soll. Diese Angabe ist eine Breiten und Höhenangabe.

Diese Attribute geben schon einmal Anhaltspunkte was für Daten wir zu speichern haben.
Bevor wir jedoch ganz tief in die Attributebene eintauchen, gehen wir zuerst einmal in den Anwendungsfällen weiter und schauen welche Attribute und Objekte wir sonst noch so haben.
Ich nehme mir die einzelnen Objekte heraus und versuche eine erste Modellierung.

Guggat emol Blog » Weight-Modell backen

Weight-Modell backen

Ähnliche Beiträge

User-Modell für den Datenbankzugriff in CakePHP backen

Ähnliche Beiträge

Namensänderungen im Newssystem Modell

Was habe ich getan?

Was muss jetzt geschehen?

Blogsoftware verwenden hat Vorteile bei der Dokumentation

Fazit

Ähnliche Beiträge

UserModelFactory

Ähnliche Beiträge

UserModel Beschreibung

Attribute des UserModels

name

surname

email

loginName

password

passwordAge

currentLoginTryCount

Aufgabe

Ähnliche Beiträge

ImageModel Beschreibung

id

name

altText

type

description

Aufgabe

Ähnliche Beiträge

Geschäftsmodelle erkennen

Ähnliche Beiträge

Newssytem Daten Modellieren

Wie gehe ich beim Datenmodellieren vor?

Wo fangen wir an?

Was können wir aus der Anwendungsfallbechreibung herausholen?

Ähnliche Beiträge