This ship has sunk

Sinking Ship
Standard

Flattr this!

Originally this blog post was named „This ship has sailed“ but it took me nearly as long to publish the blog post as coming to the decision described below. So, for me this ship has more than sailed, it sunk and I fear there is little hope it will ever be rediscovered and salvaged…

Long story short: Due to various reasons I had little time to rewrite the RSVP-App to make it usable by other users. Now, with the release of Laravel 5 there is even more to do and I have even less time.

Thus, I decided to stop further work on the RSVP app. If you are interested in the code and would like to take a look at it, please contact me.

RSVP Application – current status

Standard

Flattr this!

I finally had some time to work on the RSVP application to get it to a level where it could be open sourced.

User Administration: Integrating Sentry was actually very easy, although I still find checks agains the default user authentication instead of Sentry. Based on the Sentry Integration, I also used more exceptions than before to capture unexpected behavior – some might call it flow control, but that debate is for others.

New Events: Events can now be created by users and the invitee upload works again, so the administration part is nearly done and then I need to do the user/RSVP part which should go rather fast (except custom questions which I will add later).

Hope, to have another update in the coming weeks…

RSVP Application – what it is, what it does…

Standard

Flattr this!

RSVP Login Page

As some people asked about it, here a short explanation how our wedding RSVP system worked (a longer, more detailed version may follow):

The RSVP application was build on top of Laravel (a new, fancy PHP framework) that basically used our invitation list as an input, created for each group of guests (i.e. families, couples…) a random access code as well as an QR-Code. These were printed on the RSVP cards.

Each guest (group) could then login and enter if they were coming or not as well as some other questions (choice of menu, if they were bringing their +1 etc.

The access code became instantly invalid, I got both a push notification to my iPhone (thanks to Pushover) as well as an email and via the backend we could access a report that gave us up-to-date statistics: How many people had answered, how many responses were not missing, how many were (not) coming…

In the end I downloaded the report and we used it for our future planning – so that’s the RSVP application…

You want to use it? Great – and sorry for now 😉

I am planning to release the source code as I will have no use for it in the near future but it might be useful to others. However, there are some things I need to improve first as the application is currently pretty much hardcoded for our wedding… more info soon.

New Laravel Gist: Twitter Bootstrap Forms

Standard

Flattr this!

Working on a Laravel App refactoring (will post more on this soon), I discovered a challenge: Integrating Twitter Bootstrap Form layouts into Laravel Blade templates.

Twitter Bootstrap has a whole lot of design options for forms:

  • Validation states (success/error)
  • Validation marks
  • Error messages

However, using them, requires wrapping each form element in his own div, adding classes based on status etc. Doing this for every single one of them is rather tiring, so I wrote (up to now) two blades, that display password and text fields and wraps them accordingly.

You can find them here on Github.

The Laravel blade assumes that three variables are given:

  • $field:  The name of the field
  • $context: The context, which is basically the name of the appropriate language file
  • $error: The Laravel error messages bag

Further, the language variable should be like this

  • ‚field‘ – Name of the field
  • field_placeholder‘ – Placeholder of the input field.

For example,for the field email I would include this blade by using

While having the following within lang/en/user.php

This drastically reduces the amount of code, I have to write to insert a new field and allows to make central changes to all forms, if required.

Feel free to comment, copy or branch 😀

Validate multi-entry forms with Laravel

Standard

Flattr this!

While working on a new Laravel Application, I needed a solution for multi-entry validation: Users should be able to add one or many persons to an event and the input should still be validated.

Laravels standard validation approach is based on static rules and messages to validate forms and/or to save models

Prerequiste – setting up the form

The dynamic validation requires that the form entries follow the pattern Input[key][field], for instance:

I actually used UUIDs as keys that were dynamically created via Javascript (see Stackoverflow) when a new person was added.

Validation

Before the validation is called, the rules are dynamically defined based on the data array (here using the Laravel dot-Notation):

Bye Bye Joomla

Standard

Flattr this!

Mit der Migration der ORD-Webseite auf WordPress, habe ich die letzte von mir verwaltete Joomla!-Instanz aufgegeben (das konkrete Vorgehen schildere ich bei Gelegenheit ). Ein Schritt der mir nicht leichtfiel, immerhin nutzte ich Joomla! seit knapp acht Jahren, hatte diverse Seiten mit Joomla umgesetzt und an Erweiterungen mitgearbeitet.

Vor etwa vier Jahren kam in der Fachschaft BWL die Diskussion auf, wohin man die existierende Typo3-Webseite migrieren sollte. Typo3 bot zwar viele Funktionen, aber die meisten nutzte die Fachschaft nicht und gleichzeitig war die Wartung und Weiterentwicklung sehr aufwändig. Ich schlug damals Joomla! vor und konnte mich damit gegenüber anderen Vorschlägen (WordPress, Drupal) durchsetzen – retroperspektivisch vielleicht ein Fehler. Soweit ich weiß, steht die Fachschaft möglicherweise vor der nächsten Migration.

Schuld daran ist das aus meiner Sicht inakzeptable Vorgehen bei der Migration von Joomla! 1.5 auf 2.5 bzw. 3.0. Für diese wurde kein Migrationspfad angeboten, der offizielle Weg wäre das Aufsetzen einer neuen Instanz und manuelle Übertragen der Inhalte der alten gewesen. Zusätzlich gab es zwar eine (von der Community entwickelte) Komponente Jupgrade, die aber nur einen Teil der Inhalte migrierte.

Natürlich ist es grundsätzlich sinnvoll, alte Zöpfe irgendwann abzuschneiden, aber nicht indem man die Community so vor den Kopf stößt. Ich hätte für jede, der von mir verantworteten Seiten, zwischen 50 und 500 Artikel manuell übertragen oder darauf hoffen
müssen, dass die von mir genutzten Plugins nach dem automatischen Transfer immer noch funktionieren.

Folglich habe ich mich nun entschieden auf WordPress zu setzen. Zwar musste ich hier auch viel manuell machen, aber ich bin zuversichtlich, dass es hier in Zukunft keine solche Zäsur zwischen zwei Versionen geben wird, bei der alle Erweiterungen auf einmal nicht mehr funktionierten (Erweiterungen für 1.5 mit der 2.5 und umgekehrt).

Ach ja – ich weiß, Joomla! ist OpenSource und wenn einem etwas nicht gefällt kann man es selber machen. Stimmt. Deswegen habe ich damals bei GroupJive mitgearbeitet und auch andere Erweiterungen geschrieben (unter anderen im Rahmen meines Studiums für unser Teamprojekt – leider nicht lauffähig unter 2.5). Aber damit ich für ein System programmiere muss ich mich darauf verlassen, dass APIs relativ stabil bleiben, dass Versionen aufeinander aufbauen und sich organisch entwickeln. Wenn das nicht passiert, vertraue ich dem System nicht, insbesondere wenn ich keinen direkten Vorteil sehe und keine Legacy-Möglichkeit geboten wird (wie z.B. zwischen Joomla! 1.0 und 1.5).

Daher jetzt der Schritt zu WordPress.