Projektfortschritt

So, ich mach dann mal auch gleich mal den Anfang ;)

• Packages besser strukturiert: Die meisten Forms/Actions liegen jetzt in einem jeweiligen Sub-Package in einem passenden Paket.*
• Ansprechen der Catalogs/Stocks geändert: Einige haben - statt eine String-Konstante anzulegen einfach jedes mal bei getCatalog/getStock einen String angegeben!**
• Klasse umbenannt: Die Klasse Layout heißt jetzt BookingSchedule.

* Wenn irgendwelche Dateien in ein "falsches" Package reingerutscht sind, bescheid sagen, dann ändere ich das noch.
** NIEMALS direkt Strings bei sowas verwenden, sondern immer eine Konstante anlegen und damit hantieren! Gilt nicht nur für Java anwendungen ;) Und btw: Ja, ich kann (bzw. muss leider) bestätigen, das die Nicht-Einhaltung dieser Regel die Tore zur Hölle öffnet >:)

So, erstmal nur ein winziges Update, aber ein wichtiges:

Ich habe die Kodierung der MessageResources Datei auf UTF-8 geändert!
Zu meiner Verteidigung:
Wenn es beim `svn update` zu einem Editieren der Datei kommt, kommt Müll raus; bereits erfolgreich getestet ;)

Was sich ändert:
Nix weiter. Nach dem Update auf die neue Revision einfach in Eclipse unter Window -> Preferences -> General -> Content Types den Dateityp Text/Java Properties File anklicken und dann "Default Encoding" auf "UTF-8" ändern und mittels "Update" bestätigen. Alle anderen Dateien sollten bereits UTF-8 kodiert vorliegen.

Kleiner (positiver) Nebeneffekt: Man kann nun die Datei auch mit nem Standard-(Linux-)Texteditor bearbeiten - z.B. wenn man mal gerade keine Lust auf den ganzen Eclipse-Bloat hat ;)

So, wieder mal ich ;)

Ich hab jetzt testhalber mal ne Taglib fertig gemacht. Dazu liegt jetzt unter WEB-INF/tlds/ ne Tag Library Describtion "housemanagement.tld", welche auch schon in der web.xml referenziert wird d.h. sie kann via ...

Ich hab bisher nur (mehr zum Test) einen Tag "ShortUserInfo" implementiert, der via hm:ShortUserInfo eingebunden werden kann und Benutzername und Account-Typ anzeigt (wird in der Sidebar ausgegeben.

@robert:
Solltest du schon was implementiert haben, sag Bescheid, dann fliegt mein Zeugs wieder raus. Das ist nur drinnen, weil ich das zeitnah zum Testen brauch, da ich die User-Liste gleich via Tags ausgeben lassen will.

Sollte es drin bleiben:
Ich hab ne Klasse housemanagement.tags.AbstractSimpleTag eingeführt. Diese kann überschrieben werden, um einfache Tags zu erstellen, die einfach ein paar Infos ausgeben. Dazu einfach erben und die getTagContents() Methode überschreiben. Diese sollte die auszugebenden Inhalte als (X)HTML Code zurückgeben. Den Rest erledigt die AbstractSimpleTag Klasse von alleine.

Erst ma fettes Lob für das ganze Aufräumen.

Eine Sache noch: Ich hab dit ja eh etwas kritisch gesehn mit dem umbenennen der Layout-Klasse, wenn dit ganze Projekt schon so weit vorangeschritten is, hat allerdings doch überraschend gut geklappt ;)
lediglich die statische methode des WebPortals getLayout() müsste dann noch umbenannt werden. Solche Inkonsistenzen verwirren noch mehr als missverständliche Namen...

Moin,

mal ein kleines update von mir (und das vor dem Wochenende 8) ) Und zwar:

• ToDoItems werden nicht mehr über den TED angezeigt, sondern über den eigenen Iterator (mit der Variante 1 (ToDoStock durchsuchen)
• Javadockommentare sind in der ganzen Profil- und ToDoSache vorhanden, soweit nichts übersehen

mfg stefan

Eine Sache noch: Ich hab dit ja eh etwas kritisch gesehn mit dem umbenennen der Layout-Klasse, wenn dit ganze Projekt schon so weit vorangeschritten is, hat allerdings doch überraschend gut geklappt ;)
lediglich die statische methode des WebPortals getLayout() müsste dann noch umbenannt werden. Solche Inkonsistenzen verwirren noch mehr als missverständliche Namen...

Argh... ist mir noch eins durch die Lappen gegangen ^^'
Hab das behoben; die Änderung ist bereits online.

So... ich habe jetzt testweise mal Dojo eingebunden. Mit dem nächsten Update sollte das ganze heruntergeladen und passend eingefügt werden.

Um das ganze in Aktion zu sehen, einfach die Benutzer-Ansicht des Admins aufrufen. Prinzipiell wird dort jetzt eine normale Radio-List angeboten. Bei einem Klick auf den entsprechenden Nutzer gibt es aber noch zusätzliche Infos, die aufklappen.

Was noch gemacht werden muss:
Zum ersten Öffnen muss 2 mal hintereinander auf den Benutzernamen geklickt werden. Danach geht es normal...
Außerdem sollte bestenfalls ne Animation verwendet werden, um die Menüs aufzuklappen. Muss mich dazu dann aber noch genauer in Dojo einarbeiten.

Ich geh jetzt jedenfalls erstmal schlafen ^^

Klasse Sache mit dem Dojo. Ist echt gut fürs Auge. Das mit dem zweimal klicken ist wirklich komisch, ist aber sicherlich zu beheben. Mal ne Fareg an euch alle. Seit dem neusten Update (Rev 49) ist mir Eclipse zweimal abgeschmiert und der Tomcat server braucht ewig um zu starten hatte sogar n paar TimeOuts (45 secs) Kann das jemand bestätigen? Oder liegts mal wieder an meiner Printe? o.O" Kann das mit Dojo zusammenhängen?

So, neues:

• Problem mit dem Aufklappen von Infos in der Useransicht behoben
• Basis-Tag-Klasse für RadioLists:

Zum 2. Punkt siehe auch dieser Blog-Eintrag:
http://www.rpdev.net/home/node/153

Noch eine kurze Anmerkung:
Nachdem ich heute früh mit Kai etwas über das Konzept diskutiert habe, gibt es nun zwei Resourcendateien, eine zur Übersetzung und eine für die Tag-Grundgerüste. Ist sauberer und führt die Trennung von Inhalt und Layout weiter. Infos auch im oben verlinkten Blog-Eintrag ganz unten ;)

Und noch eine Anmerkung ^^

Die RadioListTag Klasse hat einen kleinen Design-Fehler: Anscheinend wird ein Tag nur einmal instantiiert. D.h.: Die Daten dürfen nicht wie im Blogeintrag beschrieben im Konstruktor initialisiert werden.

Ich habe das bereits gefixt: Die Klasse erfordert nun die Implementation einer Methode "initializeData()". Daten sollten nun in dieser initialisiert werden anstatt im Konstruktor.

Ich fürchte langsam, ich übertreibe es mit meinen Commits, aber einer geht noch ^^'

Es gibt jetzt eine neue Basis-Tag-Klasse!

Diese nennt sich FormListTag und kann benutzt werden, um eine Liste auszugeben, bei der unter jedem Eintrag entsprechende Buttons sind.

Die Benutzung bzw. das Layout sind dem RadioListTag sehr ähnlich:
Jeder Eintrag hat einen Titel, einen Info-Bereich und dann eben die Buttons. Der Info-Bereich wird anfangs ausgeblendet, erst mit einem geziehlten Click im Titelbereich wird die Info aufgeklappt.

Die zugrunde liegende Technik sieht dabei so aus:
Pro Eintrag wird eine eigene Form erzeugt. Pro Eintrag werden wie beim RadioListTag verschiedene Template-Methoden aufgerufen, um die Inhalte abzufragen. Das ist recht flexibel, so ermöglicht es z.B. für verschiedene Einträge der Liste auch verschiedene Formulare zu erzeugen oder auch verschiedene Buttons usw.

Im Info-Bereich können des weiteren auch Eingabefelder platziert werden, um weitere Infos abzufragen oder etwa (mit versteckten Elementen) den entsprechenden Eintrag etwa den User, das Haus, etc. zu merken.

Ich habe des weiteren eine Beispielimplementierung mit hochgeladen: Der AlternativePrintUsers Tag wird momentan verwendet, um den Admin die Liste aller Benutzer zu präsentieren. Allerdings ist das an der Stelle übertrieben, daher werde ich später zur alten Variante zurückkehren.

Noch eine letzte Anmerkung:
Nachdem ich ein paar passende Bildchen hab, wird nicht mehr der komplette Titel als Link zum aufklappen genutzt, sondern nur noch ein entsprechender Button. D.h. im Titel selbst können auch Bilder usw. dargestellt werden, was sich vor allem für die Häuserliste anbietet.

sooo.. jetzt hab ich auch mal nen update gebracht

dit rechnungswesen ist soweit fertig. haben jetzt eine abstracte billing, welche preis und anzahlung und so berechnet. Wie dies konkret aussieht wird durch eine template method in den konkreten klassen geklärt. das sind jetzt AllInclusivePricing und PerPersonPricing

An einem solchen BIlling hängt eine Costs -liste, welche als eigene Klasse verwaltet wird.

Zu Realisierung habe ich mir folgenden Kopfstand ausgedacht:
An jedem Haus hängt bereits ein Billing der aktuellen Konfiguration (ohne Costsliste und booking is nat auch null)
Wenn ein Booking erstellt wird, wird die aktuelle Billing des Hauses geklont und an das Booking gehängt, sodass änderungen am Haus den vertrag nicht mehr beeinflussen.

Kurz zusammengefasst: das haus hält ein BIlling bereit, welches sich die Bookings jeweils kopieren. Vorteil: das Haus kann Funktionen dieses Billings bereits nutzen um seinen Preis anzugeben

die arbeit mit tags kommt dann morgen, genauso wie die Rechnung als PDF

MFG kai

N'Abend,

und zwar ein ganz wichtiges Update:

Die ToDoItems sind nun als CatalogItems verfügbar. Unsere erste Variante diese als StockItems zu benutzen geht schief, da wir so nicht mehr eindeutig referenzieren können, denn der Name referenziert schon ein CatalogItem und diese sind nicht eindeutig. Wir haben dann sozusagen 20 StockItems die zu einem CatalogItem "Cleaning" gehören, wissen aber nicht weiter welches StockItem wir geraden genau behandeln -> Nicht gut!

Daher die Änderung. Dazu kommt dass die ganze Sache - sprich ToDos Anzeigen, Löschen - funktioniert wie gewollt und zwar über Martins wunderbare FormList. Vielen Dank an ihn ;)

Weiteres wurde ich gebeten einige Bemerkungen zu tätigen:

Wer IDs braucht um etwas eindeutig zu machen, solle doch bitte die in der WebPortal vorhandene generateID nehmen und nicht eine eigene anlegen. Könnte man machen, aber dazu besteht kein Bedarf, von daher können wirs auch lassen. Wer sie braucht kann sie über WebPortal.generateID() ansprechen.

Desweiteren, wer einen Namen eindeutig macht mithilfe der generateID braucht sie sich nicht zusätzlich als Klassenattribut merken (etwa als Integer oder so) Das gilt natürlich nicht für StockItems (die brauchen zusätzliche Referenzierungen ...)

So das dürftes erstmal gewesen sein ;)

mfg Stefan

Moin,

bzw Gute Nacht ;) Also noch ein etwas größeres Update:

Es können nun beim Erledigen von ToDos Schäden gemeldet werden. Dazu wird die Checkbox angeklickt und dann die entsprechenden Daten eingegeben. Darauf hin bekommt der Vermieter eine Benachrichtigung. Dieser kann dann dieses Reparaturangebot annehmen oder ablehnen. Falls er es ablehnt wird es lediglich als gelöscht markiert. Falls er es jedoch annimt, wird ein Reparaturauftrag los geschickt, der seinerseits wieder in die ToDoList wandert ;)

Das ist aber nur ne sehr unstable Version. Ich bin nur derzeit sehr müde und daher nicht ganz in der Lage noch nötige Bugfixes vorzunehmen. Aber, gemacht werden muss noch:

• Abfragen der Textfelder beim Schaden melden. Auch wenn Checkbox markiert ist, dürfen die Textfelder nicht leer sein!
• Schöneres Layout ;)
• Ausgabe für Reparaturen ändern, denn die dürfen ja nicht wiederrum neue Schadensangebote erstellen
• Getrennte ToDoListen für Hausmeister und Putzkräfte (Ein Hausmeister darf keinen Schaden melden, Putze darf nicht reparieren usw)
• Die jeweilige Schadensmeldung nur an den Besitzer des Hauses schicken. Ich glaube derzeit wird jedem Vermieter der Schaden gemeldet, auch wenn er das Haus nicht besitzt

Ich bin morgen den ganzen Tag nicht da und auch nicht arbeitsfähig. Bin dann so gegen Sonntag Vormittag/Mittag wieder in DD und werde mich dann an die nötigen Bugfixes setzen und die ausmerzen. Wie gesagt lauffähig ist es schon, aber eben noch nicht stabil/robust. Also beachtet das bitte beim testen ;)

In diesem Sinne wünsche ich nun wirklich eine gute Nacht^^
mfg Stefan

Moin ;)

Hab jetzt die RadioList noch etwas geändert. Im Einzelnen heißt das:
Es wird nun nicht mehr der gesamte Titel als Link zum ein/ausblenden verwendet sondern ein extra Icon dafür genommen.
Im Endeffekt bedeutet das, das man im Titel nun schon schicke Daten ausgeben kann ;) Etwa ein Vorschaubild oder eine kurze Beschreibung etc.

Was leider bislang noch nicht funktioniert: Das Icon soll jeweils geändert werden, sprich:
Ist der Info-Bereich eingeklappt, Pfeil nach unten, ansonsten Pfeil nach oben.

Morgen bzw. heute ist dann auch die FormList dran.

Eine gute Nacht wünsche ich noch.
Ciao~~

So:

Ich habe sowohl den FormListTag als auch den RadioListTag noch bissl angepasst. Das Austauschen des Icons funktioniert nun bei beiden. Außerdem sehen beide sich relativ ähnlich, was dem Aussehen der Seite durchaus einige Konsistenz verschaffen dürfte.

Wenn noch jemand Vorschläge für Funktionalitäten hat, die direkt in die Klassen rein sollten, bitte Bescheid geben. Gilt auch für Vorschläge für ganz neue Tag-Arten.

Ansonsten: Ich würde vorschlagen, das wir uns auf ein paar wenige Basis-Tag-Klassen beschränken und nicht jeder für alles nen eigenen Tag macht. Denn so kann die gesamte Seite relativ leicht konsistent gehalten werden und Änderungen etwa beim Farbschema oder ähnlichem können ohne weiteres global gemacht werden.

Ich möchte des weiteren darauf hinweisen, das jetzt jeweils in den Titeln der beiden Listen-Tags auch umfangreichere Informationen ausgegeben werden können, also etwa Bilder u.Ä.

Ich hab jetzt die pdf-rechnung auch geschaft und bin auf martins formtags umgestiegen.

Was jetzt noch fehlt ist die verwaltung (hochladen und einbinden) der Bilder zu den Häusern

Dazu auch noch ein Update meinerseits:
Ich habe die Hausliste dahingehend angepasst, das die Bilder nun korrekt angezeigt werden.

Sprich: Das erste Bild in der Liste wird im Titelbereich neben dem Hausnamen und der Beschreibung angezeigt. Die restlichen Bilder werden im aufklappbaren Informationbereich dargestellt.

Ich habe dazu auch in der Hausprofil-Klasse zwei neue Methoden imageCount() und imageURL erstellt, die die Anzahl der Bilder bzw. die URI selbst zurückliefert.

un noch ein update:
- Die HäuserNamen sind nun individuell einstellbar.(also nicht mehr Haus 1 bis Haus n) Das ganze geht nur am Anfang, im nachhinein können sie nicht mehr geändert werden. Außerdem darf jeder Name nur einmal genutzt werden.
k... das alles lässt schon vermuten, dass diese Namen weiterhin als identifikator genutzt werden;)
- Es gibt jetzt eine statische methode Billing.format(double). tjoa. die tut das was ihr Name verspricht. double rein und fertig formatierte Zeichenkette (mit Euro zeichen) kommt raus.
format(12.1234) => "12.12€"
- Erweitern der Hausliste um anzeige der Preise.

- Die HäuserNamen sind nun individuell einstellbar.(also nicht mehr Haus 1 bis Haus n) Das ganze geht nur am Anfang, im nachhinein können sie nicht mehr geändert werden. Außerdem darf jeder Name nur einmal genutzt werden.
k... das alles lässt schon vermuten, dass diese Namen weiterhin als identifikator genutzt werden;)

Sorry, aber das ist IMAO not a feature, that's a bug.

Die Bezeichnung "Name" in der Catalog-Klasse ist dahingehen evtl. auch irreführend. "ID" wäre besser gewesen.
Stell dir mal folgendes vor: Elbstätten hat ein kleines Ferienhäuschen "An den Elbwiesen". Nun hat das friedliche Dörfchen Steinhausen aber ebenfalls ein solches. Beide Besitzer wollen ihr Haus einstellen. Der "Verlierer" wird dir auf's Dach steigen.

Das ist im Prinzip wie mit Personennamen. Das Portal wäre nicht lange geschäftsfähig, wenn sich nur ein einziger Peter Müller anmelden könnte. Von daher:

Die ID und der angezeigte Name gehören meiner Meinung nach getrennt. Amen.

nujoa... die frage ist ob es wirklich praktischer wird, wenn es ein und den selben namen 2 mal gibt. Wir regeln bei den Häusern im gegensatz zu den Usern praktisch alles über den Namen, der konkrete Ort steht bloß in den Details. Also besteht hier schon mal verwechslungsgefahr. Viel dramatischer wird das ganze, wenn es 2 häuser mit gleichen namen im gleichen ort gibt, was ja dann zugelassen wäre bzw schwer zu unterbinden. (denn dann steigt wieder jemand aufs dach )

mit eindeutigen Namen gehen wir allem ärger aus dem Weg und es wären dann quasi aufgaben der verwaltung zu sagen: Ihr nennt das jetzt "An den Elbwiesen (Königstein)" und "An den Elbwiesen (Dresden)"

Also rein vom praktischen her versteh ich dein ansatz zwar, würde aber trotzdem bei dem System bleiben.

...das ganze hat nat. noch den Grund, dass wir überall den Namen(= ID) anzeigen und benutzen. Es wird ein ziemlicher Aufwand das alles umzustellen.... zugegeben ich wollte es auch erst so machen ;)

So, ich hab jetzt endlich mal das Design noch ein bissl angepasst. Dazu gehört die Titlebar, aber auch in der Menubar hab ich bissl was geändert. Muss die allerdings noch irgendwann mal ein bisschen aufpeppen, bisher sieht die schrecklich aus ^^'

Außerdem:
Ich würde vorschlagen, das wir das Projekt im SVN Repo langsam mal in ein anderes Verzeichnis schieben. Bisher liegt es ja noch unter prototype. Würde dazu aber morgen noch nähere Infos geben. Ist zwar nur ein kleiner Kunstgriff, den man da in SVN machen muss, allerdings muss der sauber gemacht werden (sonst heißt es frisch auschecken >:) )

Werd dann auch bald die Newsmeldung auf der Seite rausschieben damit die net so tot aussieht :o

NU das sieht do hübsch aus.

ich würde bei den Links entweder den Trennstrich drunter wieder ziehen, oder die farblich wie de seitenleiste machen, weil die Links zur zeit vor dem großen hintergrund verschwinden oder sich zumindest nicht von ihm abheben

..oder wir lassen es so, wenn die beiden variante doof aussehn ... soweit reicht meine bildliche vorstellung nicht ;)

Du meinst diesen komischen Strich mit dem Farbverlauf? Da müsstest du erst an Robert vorbei ^^'

Ich würde aber erstmal ein bissl probieren. Hab da auch schon ne Idee. Denn so wie die Links derzeit aussehen, würden sie auch mit dem Strich nicht genug ins Auge fallen.

Da ich's auch selbst brauche: Ich werd im Laufe der nächsten Woche ein paar Icons designen - oder es zumindest versuchen. Wenn jemand in dem Zusammenhang nen Wunsch für ein Icon hat, möge er sich bei mir melden ;)

Die Tags sind jetzt soweit implementiert.
Nur in den datein logon.jsp und newbookingdetails.jsp ist noch extra JavaCode vorhanden.
Das hängt damit zusammen das dort Variablen definiert sind, die anschliessend in einem HTML-Tag genutzt werden. Diese Variablen auszulagern und dann IM Tag aufzurufen ist im Moment nicht möglich, da eigens erstellte Tags als Parameter nicht zugelassen sind und es in HTML keine Variablen gibt.

1.
Wenn ein paar wenige Code-Schnipsel verbleiben, macht das nix. Hat Lars auch selber gesagt. Es gibt zwar auch die Möglichkeit (zumindest soweit ich weiß) das man Tags schreiben kann, die dann Variablen definieren, allerdings ist das an der Stelle wohl die Kanonen-Spatzen-Methode.

2.
Erste Grundzüge des Messaging-Systems stehen bereits.
Viel gibts dazu allerdings noch nicht zu sehen. Wer er probieren will: In einer beliebigen Datei den Tag

Was ich noch machen will (kann aber nicht versprechen, das das heute schon den Weg ins Repo finden wird):

• Eigene Seite für die Anzeige des Messages. Evtl. von der Profilseite und auf jedem Fall aus der Sidebar dahin verlinken.
• Der PrivateMessage-Tag muss ausgebaut werden. D.h. es kommen auf jeden Fall noch Buttons für "Als gelesen Markieren" und "Löschen" unter jeden Eintrag.
• Was ich auch gerne mit reinbringen will: Antworten auf Nachrichten. Sollte an und für sich kein Problem sein, da der Sender gespeichert wird (außer bei vom System versendeten Nachrichten)
• Wie bereits angeklungen: Ein Sidebar-Widget, wo eine kurze Zusammenfassung (Nachrichten gesamt, davon ungelesen, ..) angezeigt wird incl. Link auf die Seite

Wie schon gesagt: Interaktion noch nicht so toll. Aber: Wer das System bereits benutzen will, um etwa einen Benutzer über etwas zu informieren, kann das bereits tun. Das Versenden einer Nachricht ist dabei sehr einfach:

"sender" ist ein PortalUser. Hier kann auch null angegeben werden. Dann handelt es sich sozusagen um "System-Nachrichten". Ansonsten (gerade bei Interaktion Mieter/Vermieter) sollte da der entsprechende Benutzer als Sender eingetragen werden. Ermöglicht dann auch direkte Nachfragen.

subject und message_text sind, wofür sie stehen 8) Also Betreff und Nachricht an sich.

Wichtig noch bei der Ausgabe: Derzeit werden Zeilenumbrüche nicht in HTML-Zeilenumbrüche umgewandelt. Wenn man bei längeren Texten also einen Zeilemumbruch erzwingen will, in der MessageResources an den entsprechenden Stellen ein <br /> einfügen.

Pdf-Rechnung wurde jetzt noch mal aufgehübscht

da is jez wat ganz ganz hässliches drinne, hab aber leider noch keinen weg gefunden das zu umgehen: das logo, liegt im src ordner (housemanagement.pricing). im data ordner ging leider nicht, weil man die datei in der Javaklasse braucht. relative Pfade landen im prgramm ordner von eclipse und finden natürlich nix und absolute pfade ermitteln hab ich nur in den src ordnern geschaft.

Ich probier noch bissl, wenn jmd ne lösung kennt bitte melden.

MFG kai

Moin,

ich hab dank Kais Vorarbeit ein weiteres Wunschfeature verwirklicht, was gkaube ich auch nicht im Pflichtenheft steht. Und zwar gehts um die Rechnungsbawicklung zwischen Vermieter und Hausverwaltung.

Sind noch ein paar Haken drin, denn derzeit bekommt der Vermieter generell eine Rechnung auch wenn er das Reparaturangebot nicht angenommen hat. Das kann man so leicht auch nicht umgehen, es sei denn man nimmt eine kleine Umstrukturierung vor. Und da wirds wieder heiß! Wir hatten ja mal sowas wie eine History für Buchungen geplant. Das würde ich demnächst auch mal für Reparaturaufträge in Angriff nehmen. Denn dann können wir ein(e) Extraformular/action verwenden, in der der Vermieter dann durch seine vergangenen Reparaturaufträge scrollen kann und dann dort die Rechnungen durchsieht und evtl als bezahlt markieren kann.

Man könnte jez das Spiel noch richtig weit auf die Höhe treiben, in dem man sagt betreffende Partei dürfen sowas wie Mahnungen verschicken. Aber ich glaube das führt n bissl sehr weit 8)

Jedenfalls hab ich noch im ToDoItem die Zeitangabe von Date auf Calendar geändert.

Das wärs ertmal bis hier hin. Schönen Abend noch und bis morgen ;)

So,

noch ein paar Änderungen und wir nähern uns der 100! Jedenfalls hab ich jez die Menubar angepasst. Man findet nun einen Registrierenbutton sowei einen Aufgabenbutton (für die Cleaner und Caretaker unter uns) bzw den "Profil ändern"-button. Alle hässlichen Links sind somit erstmal entfernt.

Desweiteren habe ich der Klasse "Format" noch 2 weitere Funktionen spendiert timeframeOverlaps(). Ich weiß der Name ist nicht grade wunderbar. Man könnte die ja an Anlehnung an Java compareTo() nennen. Jedenfalls:

Man übergibt 4 argumente (enteder alle Calendar oder alle Date). Das erste Argument gibt an, wann die feste Zeitspanne startet, während das zweite Argument das Ende jener Spanne angibt. Das dritte und vierte Argument sind jeweils Anfang und Ende der Zeitspanne auf die getestet werden soll, ob sie mit der ersten Kollidiert.

Ein Beispiel (Pseudocode):

Erste Zeitspanne : 25.05.2009 - 03.06.2009
Zweite Zeitspanne : 01.06.2009 - 24.12. 2009

Der Funktionsaufruf : timeframeOverlaps(25.05.2009, 03.06.2009, 01.06.2009, 24.12.2009)
Der Rückgabewert : in diesem fall true, da die zweite Spanne partiell in der ersten liegt. Ansonsten wäre der Rückgabetyp false.

Das heißt für die Reservierungen : if( !timeframeOverlaps(daten ....)) then reservierungmöglich

Das ganze hab ich noch nicht getestet, da ich mich mit dem ganzen Reservierungskram nicht so auskenne ;) und das auch ne Menge wäre um mal eine Testmöglichkeit zu bauen. Hab die Daten der Doku entnommen, von daher müsten die stimmen. Falls nur Käse rauskommt, bitte bescheid geben, dann setze ich mal fix n normales Javaprojekt auf und teste damit mal. Also wer auch immer das braucht (ich glaube Kai wegen reservierungen oder so): Bescheid geben ;)

EDIT: Hab das ganze doch mal fix in der Konsole getestet. Bis auf einen schon behobenen Bug funktioniert alles wie gewollt. Ist also für den Verkehr freigegeben.

In diesem Sinn: nen feinen Abend noch!

zu dem Registrieren-button: jetzt fehlt die funktionalität, dass man als gast nen Haus sucht, auf reservieren geht und dann statt dem einloggen nen neuen account anlegt... und anschließend wieder automatisch weitergeleitet wird.

MIr fällt aber auch grade keine saubere variante ein, dass zu tun. theoretisch müsst der link dorte wieder hin (ggf als knopf formatiert). allerdings wäre das dann beim normalen einloggen sinnlos.

hmmm...ideen?

hmmm...ideen?

Ja ;)

Einfach unterhalb des Login-Formulars einen kleinen Hinweistext setzen ala:

"Noch kein Mitglied? Jetzt *registrieren* und die Vorteile von Ferien im Wilden Osten genießen!"

Registrieren in diesem Fall als Link auf das Registrieren-Formular machen und fertig. Das wird IIRC auf einigen großen Seiten ebenfalls so gehandelt.

Ansonsten:
@Stefan:
Ich würde den Profil-ändern-Link nicht in die Menubar machen. Denn damit wird die überladen. Guck dir z.B. an, wie das bei Drupal umgesetzt ist. Da hast du auch einen Link "My Account" und darüber kommst du via "Edit" zu nem Formular, wo du deine Einstellungen ändern kannst.
Halte ich meines Erachtens nach für eleganter, eben weil sonst die Menubar unnötig überladen wird.

Moin,

wieder ne kleine Veränderung:

• Ein großer Bug wurde bei den ToDos und Reparaturen behoben. ToDos haben bis vor kurzem nicht auf den eindeutigen Namen der Reparaturen zugegriffen, sondern auf die nicht notwendigerweise eindeutige Beschreibung. Reparaturen mit der gleichen Beschreibung hätte Probleme bereitet
• Es werden die ToDos nun gefiltert ausgegeben. Das heißt Putzkräfte können keine Reparaturen mehr einsehen und Hausmeister können nicht mehr Reinigungen einsehen und auch keinen Schaden melden!
• Wie oben schon angedeutet: Es sind nun auch Reinigungen vorhanden.
• Die Formatklasse ist nun um 2 Funktionen erweitert: isEqual(calendar, Calendar) und isEqual(Date, Date). DIese gibt true zurück, falls die Daten an dem gleichen Tag, Monat und Jahr sind. Jedoch ohne Zeitvergleich!
• Der Rechungsbug wurde behoben und diese dürften nun Ordnungsgemäß angezeigt werden

Man wäre damit fast schon an der Spitze der ToDos angekommen. Es würde nur noch fehlen:

• Bei Reinigungen muss auch eine Rechnung erstellt werden
• Layouting und etwas hübschere Beschreibungen^^'
• Eine Reinungung und eine Schlüsselabnahme müssten doch eiegntlich zusammengefasst werden oder? Denn sonst könnte ja eine die schlüsselabnahme bestätigen und eine andere die Reinigung des Hauses, die nach der Schlüsselabgabe getätigt wird. Ansich nicht so tragisch. Was ist aber wenn eine einen Schaden meldet und die andere nicht. Oder schlimmer noch beide verschiedene Schäden melden? Man könnte jez sagen: Im realen Leben würde eine Schlüsselabnahme und Reinigung zusammen machen. Was sagt ihr dazu?
• Evtl noch n paar Zusatzfeatures: Nachrichten verschicken, Pauschalzahlungen an Hausverwaltung (dann keine Rechnung), Mahnungen usw ....

So ich hoffe das war nicht all zu viel Text ;)

Das mit dem profil ändere ich auch gleich noch. Kommen wieder Buttons hin und der Link Profil ändern kommt raus. Sah erlich gesagt auch doof aus, als der mit dabei stand =P

In diesem Sinne einen schönen Samstag noch

@ martin: jo, so wäre es das logischste, aba da haben wir dann dit registeren quasi doppelt. fänd i aba ni so schlimm, könn mer so machen (mach ich)

@ stefan. ich würde es getrennt lassen, weil:
- auch hausmeister dürfen nen schlüssel zurücknehemn, aber nicht putzen.
- im wahren leben ist es doch durchaus denkbr, das irgendjemand den schlüssel abholt und jemand anderes paar tage(oder stnden) später putzt...
- zu den schäden: ich seh da auch keine konflikte, da es durchaussein kann, das zwischendurch noch das haus abbrennt o.ä. und somit einer nen schaden meldet udn nen anderer nicht. der vermieter sieht doch eh nur die schäden, egal, bei was sie festgestellt wurden... und dann hat er zu einem haus eben 2 schadensmeldungen... hart aber fair^^

OK, dann von mir ebenfalls mal ein statusbericht:

Die FormListTags sind nun schachtelbar. Das ganze ist dabei recht leicht lösbar:

In der abgeleiteten klasse einfach die Methode stackable() überschreiben. Diese sollte je nachdem, ob man in einem Item-Body noch eine Form einfügen möchte, true oder eben false zurückliefern.

Bei stackable = true wird nur um die Buttons herum ein Form erzeugt. Damit kann dann aber im Body kein Input-Element mehr platziert werden.

Andernfalls verhält sich der FLT genauso wie vorher.

Ebenfalls neu ist die Möglichkeit, einzelne Items bereits aufgeklappt darzustellen. Dazu gibt es eine neue Templatemethode currentHideOnShow(). Diese gibt in der Standard-implementierung bereits true zurück, womit Einträge beim Anzeigen ausgeblendet werden. D.h.: Für das Standardverhalten muss die methode also nicht überschrieben werden.
Ansonsten wie erwartet: Die Methode wird für jedes Item aufgerufen und gibt sie false zurück, das javaScript, das den Body beim laden der Seite versteckt, ausgelassen.

Ansonsten: Das Entwicklungsarchiv wurde nun in ein anderes Verzeichnis im repo verschoben!

Um diese Änderung bei euch wirksam zu machen:
In der Konsole wechselt ihr in euer Projektwurzelverzeichnis (.../workspace/ferienhausverwaltung).
Dort dann folgendes eingeben:

An Stefan: Du musst bei dir entsprechend ins WebContent Verzeichnis wechseln und dort dann den selben Befehl eingeben, allerdings ans Ende ebenfalls das WebContent anhängen.
Dieser Hinweis gilt ebenfalls für alle, bei denen die ausgabe von `svn status` im Projektverzeichnis (z.b. "Ferienhausverwaltung") ausgaben ala "Verzeichnis ist keine Arbeitskopie" liefert.

Wichtiger Hinweis:
Vorher ne Sicherungskopie des Projektes anlegen! Nicht, das ich nachher der Böse bin (... nun ja... wobei... >:) )

In diesem Sinne: Schönes wochenende und Happy Codding ^^

Edit:
Hab mal versucht, alle normalen Info-Messages in einem DIV zusammenzufassen. Funzt soweit auch, ABER:
der DIV ist jetzt immer da, auch, wenn keine nachrichten da sind. Muss das noch mal genauer betrachten, im schlimmsten fall halt vorher durch die Info-messages iterieren und daran "merken", das was auszugeben ist.

annsonsten:
Wegen Gesamtpreis beim Buchen per Java berechnen: Funzt derzeit leider noch nicht. Zu testzwecken ist ein Link drinn, wird natürlich noch umgestellt, das bei Eingabe automatisch berechnet wird.
Schön wäre es, wenn ich bissl in der Billingklasse was ersetzen und hinzufügen könnte. außerdem wäre es Klasse, wenn dort mal die Javadoc dazu käme... die Methodennamen sind irgendwie verwirrend (alternativ könnte es auch sein, das bei mir heut der Confused-Flag gesetzt ist, wobei ich das egoistischerweise nicht hoffe ^^')

k... wie gesagt, ich kann derzeot leider nicht ins repo guggn, aba i verute, dass du bei dem Preisberechnungszeug folgende methoden brauchst. (jo da waren jez noch paar änderungen zwecks dem Berechnen für mehrere tage, wodurch doku noch nicht vorhanden und wie ich gesehen hab tw. sogar falsch ist...sry):

-calcPrice() gibt den gesamtpreis unter Berücksichtigung der Urlaubsdauer zurück
- getTotalCosts() gibt den mietpreis (calPrice()) zuzüglich den zusatzkosten zurück...also das was der Urlauber tatsächlich insgesamt zu zahlen hat...
-getTotalPrepayment() gibt die tatsächlich zuzahlende Anzahlung aus

um also z.B. den austehen betrag einer buchung zu berechnen tut man folgendes: getTotalCosts()-getTotalPrepayment()
..., da die anzahung bei einer buchung ja bereits getätigt wurde...

i werde die Doku am MO sofort updaten

OK, Sonntagsupdatemeldung:

• Bei FormListTags sind die Bodies nun wieder aufklappbar. War ein kleiner Tippfehler ^^
• Beim Anlegen und Löschen von Benutzern sowie dem passwortrücksetzen werden nun ebenfalls Erfolgsmeldungen ausgegeben
• Die InfoMessages werden nun ordentlich ausgegeben, sprich: der kasten auch nur dann erzeugt, wenn überhaupt was auszugeben ist.
• Sidebar-Widget-Tag fertig. Das Ding ist ebenfalls auf/zuklappbar, der status wird evtl. irgenwann einmal in einem Cookie abgelegt.
• Sidebar-Contexthelp-Tag fertig. Benutzung ist sehr leicht: Einfach tag platzieren und einen Context angeben. d.h. Einen Key in der Message Resources. An den Context wird je nachdem noch ein ".title" bzw ".body" angehangen. D.h. gibt man contexthelp.admin an, muss in der Messageresources ein key contexthelp.admin.title und contexthelp.admin.body angelegt werden. Der Tag ließt die beiden aus und erzeugt daraus das Widget.

k, hoffe, ich habe soweit nix vergessen. Euch allen noch einen schönen Sonntag abend, wenn heute auch leider ohne tatort :/
Ciao~~

Jetzt sind die ARbeiten des Wochenendes auch hochgeladen:
- die such/filter-funktion wurde um tags erweitert. diese können bei der Hauserstellung/ - bearbeitung ebenfalls angegeben werden.
welche Tags es gibt kann in der housemanagement.bookings.tags.housedetailstags.java angepasst werden.

- die Rechnung kann nun deutlich komfortabler um weitere kostenpunkte erweitert werden. und diese können auch bearbietet werden.

folgende Bitten an den Bezwinger des javascripts (Martin):
- entweder nen paar hinweise geben wie man solche klappmenüs am besten realisiert
- oder folgende Formulare an den entsprechenden Stellen aufhübschen:
-> tiles/renter/housedetailsform,jps: die Zahlungsmodalitäten und die dazugehörigen konkreten Einstellmöglichkeiten
-> tiles/tourist/newbooking: die Filter oben in unterpunkte verpacken
-> ggf beim reservieren (tiles/tourist/newbookingdetails) Kalender einfügen statt textueller Eingabe

MFG kai

@JS:

Diese Klappmenüs sind recht einfach, ABER: Das ganze sollte recht zentral verwaltet werden (damit man bspw. statt dem einfachen Show/Hide ein Ein/Ausblenden nutzen kann.

Um dann nicht zu viel Arbeit zu haben, isses günstig, wenn man das ganze in wenigen Schritten anpassen kann.

Dazu wird definitiv noch ein allgemeiner Tag kommen, mit dem man Inhalte aufklappbar markieren kann. ich denke mal, morgen werd ich mich endlich mal daran setzen.

Neues zum Nachrichtensystem:

• Nachrichtenklasse selbst leicht angepasst (nach außen aber keine Veränderungen!)
• Nachrichten-Tag+Action+Form implementiert. Messages können bereits als gelesen markiert und gelöscht werden. Was noch fehlt ist das Antworten (etwa wenn eine Nachricht durch die Bestätigung einer Reservierung durch den Vermieter geschickt wird.
• Kleines Sidebar-Widget für die Nachrichten (einfache Ausgabe ungelesene/gesamte Nachrichten). Darüber gelangt man auch zur Nachrichtenansicht.

Ich würde an der Stelle im Übrigen keinen Menüeintrag für das Nachrichtensystem machen. Wie schon gesagt: Man gelangt via dem Sidebarwidget hin, und noch einen zusätzlichen Menüeintrag macht sich gerade bei Vermietern nicht gut, da die ja eh schon viele Einträge haben.

Des weiteren werden dem Admin jetzt initial nur noch ungelöschte Benutzer angezeigt. Er kann aber weiterhin auch gelöschte Benutzer anzeigen, indem er den Filter umstellt.

Außerdem wurde der "webtest" Ordner nach "WebContent" verschoben. Denn dadrin liegen keine Quelldateien, und damit hat der nix im Source-Path verloren.

Der Ordner webtest/housemanagement/results wurde des weiteren aus der Versionskontrolle entfernt, da er durch einen Durchlauf von WebTest generiert wird.

• showTouristProfile gefixed
• Hausname wird korrekt angezeigt (hab aber noch nicht alle möglickeiten getestet)

Falls also jmd einen falschen Hausnamen bemerkt oder selbst einen benutzen will, dann bitte folgendes beachten:

• House.getName() liefert die ID und ist somit nur für interne Zwecke zu verwenden.
• House.getDatails().getName() liefert den vom Vermieter vergebenen Hausnamen zurück. Dieser Name sollte nur für die Anzeigen verwendet werden.

Moin,

hab auch grade committed:

• Der Link changeProfile wurde aus der Menubar entfernt. Es ist nur noch möglich via "Profil ansehen" und dann über den Button Profil ändern
• Für ToDoItems wurden Standardzeiten vergeben (Schlüsselübergabe = 14:00 uhr, Schlüsselabnahme, Reinigung = 10:00 uhr, Reparatur hat keine Zeit
• Die ToDoItems werden zudem zeitlich sortiert ausgegeben gemäß earliest deadline first. Zudem hatte ich noch vor n kleines Sidebarwidget zu nutzen, das evtl anzeigt welche ToDoItems genau heute zu machen sind. Alternativ könnte man darauf auch verzichten, da heute zu tätigende Aufgaben meistens oben stehen werden, außer natürlich die Leute haben noch ca. 100 Aufgaben von Vortagen nachzuholen ;) Falls es sowas in der Tat geben sollte, werden diese demnächst farbig dargestellt. Ampelprinzip.
  Rot -> Versäumt
  Gelb -> Heute
  Grün -> Demnächst
  Man könnte jez noch überlegen nur nen kleinen Ausschnitt der Aufgaben darzustellen. Sprich alle die, die im Datum +-3 Tage von heute ausgesehen liegen.

So, noch ein fixes abendliches Update:

Ich habe mich mit der Kalenderdarstellung beschäftigt; erste Ergebnisse können zumindest in Form einer Beispiel-HTML begutachtet werden. Diese ist bereits im Repo, zu finden im WebContent/templates Ordner (test.html).

Der Kalender selbst liegt als JavaScript Klasse vor. Nach dem Erstellen zeigt er den aktuellen Monat an, es kann aber auch frei vor und zurück geblättert werden. Dabei läuft alles Clientseitig ab, d.h. beim Umschalten wird der Server nicht erneut kontaktiert.

Des weiteren enthält die Klasse einige Events, die man mit eigenen Funktionen verknüpfen kann und die ich dann dazu verwenden werde, in einem Array für einen bestimmten Tag nachzuschauen, ob denn etwa das entsprechende Haus frei ist oder nicht. Wenn ich es hinkriege würde ich auch so etwas integrieren, das man direkt aus dem Kalender heraus Termine in die "von" und "bis" Felder eintragen kann.

Der Kalender ist im übrigen schön abstrakt gehalten, sprich: Wir können den auch noch an anderen Stellen einfügen (bzw. kann man den auch ganz außerhalb des Praktikums verwenden ;) )

Sollte noch jemand Vorschläge zu Design etc. haben wäre ich an der Stelle froh, wenn die zeitnah kommen, damit ich das noch mit einplanen kann.

Ansonsten wünsche ich noch nen schönen Abend ;)

Update:

Ich hoffe, es hat sich die Nacht bzw. heute Vormittag keiner kaputt gesucht. Wenn doch: Verzeihung ^^'
Die Kalenderklasse und entsprechende CSS waren zwar schon online, aber nicht die Test-HTML Datei. Hab die jetzt noch nachgereicht, zusammen mit einigen Verbesserungen am Kalender.
In der Test-HTML ist im übrigen schon zu sehen, wie man mit dem Kalender einfach Start- und Enddatum für seinen Urlaub in ein Formular eintragen kann ;) Was noch fehlt ist also die Anbindung an das Projekt, was aber durchaus machbar sein dürfte.
Ich denke mal, mit etwas Glück dürfte die Integration heute Nachmittag/Abend stehen.

• "GastBug" wurde behoben, d.h. wenn ein uneingeloggter User ein Haus reservieren will, wird er auf die Anmelden-Seite geschmissen. Wenn er sich anschliessend als Vermieter/Putzkraft/Admin/Hausmeister einloggt bekommt er ne nette Nachricht und wird auf seine Startseite gelinkt. Der normale Tourist hingegen direkt auf das Haus.

Im Moment gibt es noch ein Problem mit den Startseiten. Diese lassen sich zur Zeit nicht flexibel ändern, d.h. man muss Änderungen ausserhalb der loggedin.jsp vornehmen. Ich schau mal wie tiefgehend die Änderungen für eine flexible Startseite wären.

So, der Kalender ist jetzt ins Projekt integriert, d.h.:

Auf der NewBookingsDetail bekommt der Urlauber jetzt einen Kalender angezeigt. Ebenfalls gibt es bereits einen Tag, der sozusagen den Buchungsplan für ein Haus in eine JS-Datenbank überführt.

Diese wird dann genutzt um herauszufinden, wann ein Haus frei ist und wann nicht. Allerdings funktioniert bei der Abfrage noch etwas nicht so ganz. Darum werden bislang alle Tage als "OK" dargestellt.

Was ebenfalls noch fehlt: Die aufpoppenden Links zum direkten Eintragen der Start/Enddaten. Die sollten allerdings kein Problem werden.

Update
Der Kalender ist jetzt soweit funktionsfähig, d.h.:

• Beim Reservieren werden Buchungen und Reservierungen angezeigt. Für die Reservierungen brauche ich noch ein anderes Symbol, bisweilen wird einfch gleichzeitig das Rote und Grüne Symbol angezeigt.
• Beim Hovern werden jetzt Links eingeblendet mit denen man direkt Start und Enddatum eintragen kann.

Der Kalender kann im übrigen sehr einfach auch anderswo eingesetzt werden. Das einzige, was man braucht, ist eine andere onPutCell-Funktion. So könnte man bspw. dem Vermieter den Belegungsplan so präsentieren und in den einzelnen Tagen direkt auf die Benutzer verlinken.

Moin,

kleines aber unwichtiges update ;)

• Reparaturaufträge für ein Haus sind nur noch für den Vermieter sichtbar, der auch das Haus besitzt
• Vermieter besitzt nun Kontodaten (Kontonummer und Bankleitzahl). Diesen können über das Profiländernzeugs verändert werden. Zudem werden sie bei Buchungen und Reservierungen angezeigt.
• Die PrintHouse.hasNext() hatte einen kleinen Fehler. Man hat dort mit dem else-Zweig einer if-Abfrage wieder auf it.next() verwiesen ohne vorher mit it.hasNext() zu prüfen. Reslutat war eine böse Exception. Hab daher erst mal den else-Zweig rausgenommen (auskommentiert). Falss das nicht im Sinne das Entwicklers ist, so möge er an mich herantreten und oder es anpassen x)
• Zudem hab ihc grade mal die Initialisierungsdaten etwas aufgehübscht. Das heißt alle derzeitigen Konten haben ausgefüllte Profile. Die Namen sind abgeleitet von der Stammmannschaft von Borussia Dortmund aus dem Jahre 1997 ;). Zudem existiert nun ein zweites Haus, für vllt weitere Testzwecke.

hab junit tests für das pricing geschrieben und hochgeladen.

werde heute oder demnächst noch tests für den hausfilter und Bookings erstellen.

wie sieht das mit den tests bei euch aus?
- jeder seine funktionen mit junit und webtest so wie mer die verteilung in dr analyse hatten, oder?

Bis morgen

Moin!

Noch ein paar frische Änderungen:

• Der Gesamtpreis wir beim Reservieren jetzt angezeigt. Allerdings wird bislang nur der Pro-Person-Modus berücksichtigt.
• Die Kontexthilfe bissl ausgebaut.
• Message-Widget sowie User-Info wird jetzt immer angezeigt.

OK, nochmal ein fixes Update von mir ;)

• Man kann nun Schriftfarben (bspw. in den Titelleisten der FLTs) verwenden. Dazu einfach den entsprechenden Textbereich mit einem SPAN-HTML-Tag umgeben und als Klasse die entsprechende Farbe wählen. Bislang sind das Rot, Grün, Gelb, Blau sowie Grau.
• Die Fehler- und Infonachrichten verwenden jetzt nicht mehr die Standardlistenpunkte, sondern je nachdem das rote oder grüne Ampelmännchen.
• Man kann nun auf Nachrichten antworten, sofern es sich nicht um eine vom System (Absender

  null) versandte Nachricht handelt.

Moin,

auch mal wieder was von mir:

• ToDos werden nun über eine eigene Klasse gefiltert (nach Personen, Datumsangaben usw...)
• @Kai:die Klasse ToDoFilter besitzt eine Methode getFilteredContent(), die dir die jeweiligen Aufgaben für die todo-pdf anzeigt, da brauchste dich nicht so rum zu quälen ;). Ich konnte die Methode leider nicht statisch machen. Daher: einfach Instanz erzeugen und initializeRequest(HttpServletRequest) aufrufen. Ansonsten gibts ne böse Exception =(. Alternativ könnte man auch den Request als parameter übergeben und die funktion dann doch statisch machen. Da kannst du selbst entscheiden, wie dus lieber hättest ;) Kannst also ändern auf Bedarf^^