Prototyping einer Trello-ähnlichen App mit der WordPress-REST-API

Wir haben die REST-API von WordPress seit ihrer Ankündigung wiederholt als Schritt in eine neue Ära für die Plattform angepriesen. In diesem Beitrag nutzen wir alles, was wir in den letzten Wochen gelernt haben, anhand eines Beispiels, das zeigt, wie leistungsfähig und vielseitig die WordPress-REST-API sein kann.

Da die Interoperabilität zwischen verschiedenen Sprachen das Herzstück von REST ist, werden wir einen Prototyp einer Trello-ähnlichen Anwendung entwerfen, die gute alte WordPress-Taxonomien und -Posts verwendet, aber mit einem Twist! Auf diese Weise hoffen wir zu zeigen, wie WordPress als Entwicklungsplattform verwendet werden kann.

Trello ist eine erfolgreiche Projektmanagementanwendung, die das Kanban-Paradigma verwendet, das ursprünglich von Toyota in den 1980er Jahren populär gemacht wurde. Projekte werden als Tafeln dargestellt, die Spalten enthalten, die mit Karten gefüllt sind, die Aufgaben entsprechen. Karten bewegen sich von einer Spalte zur nächsten, bis sie den Status Erledigt haben ( z. B. von Todo zu Doing to Done). Dieser Fluss wird als Wertstrom bezeichnet. Die beiden Schlüsselideen hinter Kanban sind a) die Visualisierung Ihrer Arbeit und b) die Begrenzung Ihres aktuellen Work-in-Progress. Bei Trello wird die Arbeit mit grafischen Karten visualisiert. Spalten können auch maximale Kapazitäten haben, was bedeutet, dass Sie eine bestimmte Anzahl von Aufgaben in einer Spalte platzieren können und nicht mehr. Zum Beispiel hat die unten stehende Spalte Doing eine Kapazität von 2.

Anwendungsdesign

Wir werden eine minimale, nackte Knochenversion des Kanban-Paradigmas als Proof-of-Concept entwerfen. Die Hauptfunktionalitäten sind die folgenden:

1. Benutzer können neue Spalten erstellen/aktualisieren/löschen.
2. Benutzer können neue Karten erstellen/aktualisieren/löschen, die sich unter einer bestimmten Spalte befinden.

Die Grundidee, wie all dies implementiert werden soll, ist mit der REST-API denkbar einfach:

• Kanban-Spalten werden als WordPress- Kategorien dargestellt .
• Säulenkapazitäten können als ganze Zahlen in Kategoriebeschreibungen platziert werden .
• Kanban-Karten als Beiträge , die einer Kategorie zugeordnet sind .
• Das Verschieben einer Karte von einer Spalte in eine andere bedeutet einfach, die entsprechende Kategorie des Beitrags zu ändern.

Die im Folgenden vorgestellten Kanban-APIs sind gemäß der Idee des Rapid Prototyping „früh und oft iterieren“ lediglich Entwürfe. Die Funktionen werden aus den beiden zuvor aufgeführten Hauptfunktionalitäten und der WordPress-Asset-Zuordnung von Spalten zu Kategorien und Karten zu Beiträgen extrapoliert. Es besteht kein Zweifel, dass neue und herausfordernde Probleme auftreten werden, sobald die eigentliche Implementierung des Prototyps beginnt, aber die folgenden Entwürfe reichen uns für den Anfang!

Kanban-Spalten-API

Die folgende Liste dokumentiert die Funktionen, die die Kanban-Spalten bearbeiten, zusammen mit ihren Parametertypen. Spalten werden als WordPress-Kategorien dargestellt und ihre Kapazitätsnummer wird in der Kategoriebeschreibung hinzugefügt. Diese Liste dokumentiert keine Rückgabewerte, da für diesen Prototyp das JSON-Response-Objekt von WordPress ausreicht.

Hosten Sie Ihre Website mit Pressidium

60- TÄGIGE GELD-ZURÜCK-GARANTIE

SEHEN SIE UNSERE PLÄNE

Alle Funktionen geben jedoch wahr oder falsch zurück, um anzugeben, ob die Operation erfolgreich abgeschlossen wurde oder ob etwas schief gelaufen ist. Im letzteren Fall kann die wahre Ursache im JSON-Antwortobjekt gefunden werden, aber im Allgemeinen wird keine echte Fehlerkontrolle für den Proof-of-Concept-Prototyp bereitgestellt.

• create_new_col(cname:string, cap:int)
Erstellen Sie eine neue Kanban-Spalte namens cname mit einer ganzzahligen Obergrenze , die die Kapazität darstellt.

WordPress-API-Ressource: Erstellen Sie eine neue Kategorie

Dadurch wird eine neue Kategorie erstellt und die ganzzahlige Kapazitätszahl zur Kategoriebeschreibung hinzugefügt.

• change_col_name(alterName:String, neuerName:String)
Ändern Sie den Namen einer Kanban-Spalte von oldname in newname .

WordPress-API-Ressource: Bearbeiten Sie eine Kategorie

Dadurch wird einfach der Kategoriename geändert.

• change_col_cap(newcap:int )
Ändern Sie die Säulenkapazität in Newcap.

WordPress-API-Ressource: Bearbeiten Sie eine Kategorie

Dadurch wird die Beschreibung der entsprechenden Kategorie geändert, um die neue Kapazitätsnummer hinzuzufügen.

• delete_col(Spaltenname:Zeichenfolge)
Löscht die Spalte mit dem Namen colname.

WordPress-API-Ressource: Löschen Sie eine Kategorie

Dadurch wird einfach die der Spalte entsprechende Kategorie gelöscht. Auf diese Weise werden Sie die Karten in dieser Spalte effektiv „verwaisen“. Es liegt an Ihnen zu entscheiden, wie Sie diese Löschung durchführen. Zum Beispiel bedeutet entweder a) das Löschen einer Spalte, dass alles unter dieser Spalte gelöscht wird, oder b) „sanftes“ Löschen, indem Sie vielleicht die Karten darunter in _del_<Kategorie> umbenennen, damit Sie sie in Zukunft wiederherstellen können.

Kanban-Karten-API

Die folgende Liste ist die gleiche, aber für die Kanban-Karten. Karten werden als WordPress-Beiträge dargestellt, wobei der Titel des Beitrags effektiv verwendet wird, um die zu erledigende Aufgabe zu beschreiben. Der Inhalt des Beitrags kann als zusätzlicher Container für Notizen verwendet werden.

• create_new_card(cname:string)

Erstellt eine neue Karte namens cname.

Dadurch wird ein neuer Beitrag ohne Inhalt erstellt, der jedoch zu keiner Kategorie gehört, sollte für den Benutzer nicht sichtbar sein.

• create_new_card(cname:string, c:string)

Erstellen Sie einen neuen Beitrag mit Titel cname und Inhalt c.

Dasselbe wie oben, aber die Karte wird auch mit Inhalt erstellt.

• create_new_card(cname:string, cont:string, colname:string)

Erstellen Sie einen neuen Beitrag mit Titel cname , Inhalt cont , unter der Kategorie colname.

WordPress-API-Ressource: Erstellen Sie einen neuen Beitrag

• add_card_col(cname:string, colname:string)

Fügt eine Karte mit dem Namen cname der Spalte mit dem Namen colname hinzu.

WordPress-API-Ressource: Bearbeiten Sie einen Beitrag

• move_card_col(cname:string, colname:string)

Verschiebt die Karte mit dem Namen cname in die Spalte mit dem Namen colname. Dies sollte die alte Kategorie des Beitrags entfernen, bevor die neue hinzugefügt wird.

WordPress-API-Ressource: Bearbeiten Sie einen Beitrag

• delete_card(cname:string)
Löscht eine Karte mit dem Namen cname.

WordPress-API-Ressource: Einen Beitrag löschen

Dies führt ein destruktives Löschen durch oder nicht, je nachdem, ob Sie den Papierkorb in Ihrem WordPress-Blog aktiviert haben.

Datenintegrität

Nachdem wir unsere Funktionen WordPress-API-Aufrufen und -Assets zugeordnet haben, müssen wir sicherstellen, dass unsere Daten konsistent bleiben. Beispielsweise kann eine Kanban-Spalte mit einer Kapazität von 2 nicht mehr als 2 Karten enthalten. Eine Karte kann nicht gleichzeitig in zwei Spalten sein. Wenn eine Karte in eine andere Spalte verschoben wird, muss sie dort gelöscht werden, wo sie war. WordPress weiß jedoch überhaupt nichts über diese Einschränkungen, sodass unsere Anwendung sie bei jedem Schreibvorgang überprüfen und durchsetzen muss.

Da es sich um einen Prototyp handelt, werden nicht alle Grenzfälle aus der Entwurfsphase ersichtlich sein. Diese werden unweigerlich während der Implementierung jeder Funktion angezeigt.

Weitere Arbeit

Bis jetzt haben wir nur über die APIs gesprochen, die unsere Kanban-Anwendung mit WordPress-Ressourcen auf unterschiedliche Weise steuern werden. Unser Prototyp wäre ernsthaft mangelhaft, wenn er nur aus einer Reihe von Backend-APIs ohne Frontend bestünde, die die Leute tatsächlich verwenden könnten. Auch hier sehen wir die Vielseitigkeit von REST-APIs, da niemand sagt, wie Sie vorgehen sollten. Sie könnten etwas wie Bootstrap verwenden oder eine gute alte GUI in Java schreiben; Es gibt buchstäblich keine Grenzen für das, was Sie verwenden können.

Unser Prototyp unterstützt auch nur ein Kanban-Board, also ein Projekt, das mit Ihrer WordPress-Instanz verknüpft ist. Das ist für einen Proof-of-Concept wahrscheinlich passabel, aber für ein Endprodukt offensichtlich nicht akzeptabel. Eine Lösung wäre, die Kanban-Konzepte der WordPress-Taxonomie auf eine andere, effizientere Weise zuzuordnen, die mehrere Kanban-Boards und noch mehr Funktionen wie Teamzusammenarbeit unterstützt.

Die WordPress-Entwicklung ist wirklich spannend geworden!