Zum Inhalt springen

Tommy

Team
  • Gesamte Inhalte

    2.362
  • Benutzer seit

  • Tagessiege

    13

Beiträge erstellt von Tommy

  1. Eine Sache ist mir bei meiner App-Programmierung aufgefallen. Die kannst Du auch gut nachstellen. Wenn ich bei "Parks" auf beide Kategorien filtere, wird immer nur die letzte berücksichtigt, die mitgegeben wird. Wenn man beide Kategorien als Filter auswählt, sollten aber alle Ergebnisse logischerweise enthalten sein. Sonst sieht alles soweit gut aus. Und die API ist (bisher) auch wirklich sehr performant.

     

    Was noch schöne wäre: bei den Parks ein Integer-Feld mitgeben, dass die Anzahl der dem Park zugeordneten Attraktionen zurück gibt.

  2. vor 1 Stunde schrieb migo315:
    vor 2 Stunden schrieb Tommy:

    Wenn man die Attraktionen abfragt, bekommt man auch das Attribut park zurück:

    Interessanter Punkt, bei dem ich selbst schon in ein Konflikt kam. Eigentlich will ich in der Attraction Resource keine Park Sachen, weil das zuviel frisst. Wenn ich mir 96 Attraktionen ausgeben lassen ist das ein overhead für jede Attraktion nochmal den Park nachzuladen. Eine Zeitlang gab es sogar Attribut "park" auch nicht. Zum Filtern von Attraktionen nach Parks war dann zumindest die ID aber irgenwann notwendig. Und daraus entstand, dass ich zumindest ein paar wenige Daten zum Park ausgebe.

     

    Ich hätte es lieber, dass einer explizit die Park Resource anfragt wenn er was vom Park wissen möchte. Damit es vielleicht ein wenig klarar Strukturiert ist, kann ich mir vorstellen den Park Attribut wirklich nur auf die ID und ggfs. ein Link zur Park Resource zu beschränken. Was meinst du?

     

    Am Ende wäre das eine weitere Abfrage von Deiner Seite aus. Wenn die Ressource angehangen wird, dann vollständig. Sonst bitte weglassen, weil man das nicht standardisieren kann bei einer Abfrage und selbst ohne Ende Requests feuern müsste. Ich würde es begrüßen, den Park weiter dort zu finden, weil es schon Sinn macht diesen dort als Relation zu haben.

     

    vor 1 Stunde schrieb migo315:
    vor 2 Stunden schrieb Tommy:

    Des Weiteren gibst Du häufiger Werte als Objekte zurück (zum Beispiel attributes), die wenn sie leer sind, aber ein leeres Array zurückgeben. Diese Werte sollen besser generell ein Array sein:

    Ich verstehe was du meinst. Allerdings kennt JSON kein Array mit Keys. Es gibt nur die array Syntax ["foo", "bar"] oder die objekt Syntax {"field1": "foo", "field2": "bar"}. Diese Syntax ist invalide: [field1: 'foo', field2: 'bar']. Man könnte die Keys aus den Attributen entfernen, was allerdings dazuführt, dass man durch alle Attribute iterieren muss um an ein gesuchtes Attribut zu kommen. Aber hier ein array anstatt ein objekt zurück zu geben hört sich dennoch richtiger an - trotz des Handicap. Werd das dann anpassen. Auch an diversen anderen Stelle. Danke für den Hinweis, wäre mir gar nicht aufgefallen ?

     

    Das ist definitiv valides Json:

    [
      {
      	"foo": "bar"
      },
      {
      	"foo": "bar"
      },
      {
      	"foo": "bar"
      }
    ]

    Bitte so zurückgeben. Wenn jemand in einem Attribut suchen möchte, gibt es ausreichend Möglichkeiten in der Programmierung einen Wert via value zu finden. Die API sollte aber sauber sein, und da sieht diese Objektstruktur einfach komisch aus.

     

    vor 1 Stunde schrieb migo315:
    vor 2 Stunden schrieb Tommy:

    Bilder sollten außerdem eine Url (oder ein Objekt aus mehreren Urls) zurückgeben:

    Das ist aktuell tatsächlich by design. Weil die Bilder nicht unter der CC Lizenz stehen und somit von niemanden verwendet werden dürfen, wird keine konkrete URL ausgegeben. Das überhaupt ein paar Informationen zu den Bilder ausgegeben werden, liegt nur schlicht daran, weil wir uns selbst an die API bedienen und diese Information brauchen. Ggfs. kann aber bald jeder Benutzer für sich selbst entscheiden, ob er seine Bilder unter die CC Lizenz stellt (siehe letzte Beiträge hier) - dann wird auch eine URL ausgegeben

     

    Na ja, ob ich mir die Urls jetzt selbst herleite oder sie bereits enthalten sind, macht keinen Unterschied. Bilder klauen kann man so oder so. Wenn der Inhaber dagegen ist, soll er seine Bilder entfernen. Aber ohne Urls in den Bilddaten ist dieser Bereich sinnfrei. Daher angeben oder die Bilder bis zur Klärung komplett rausschmeißen - was noch weniger Sinn macht.

  3. Wenn man die Attraktionen abfragt, bekommt man auch das Attribut park zurück:

    "park": {
      "id": "a5fb81f1-cc4e-4a7e-8419-98cc523487e3",
      "name": "Movie Park Germany",
      "slug": "movie-park-germany"
    },

    das Element sollte so aufgebaut sein, wie wenn man einen Park abfragt, also alle Daten beinhalten. Des Weiteren gibst Du häufiger Werte als Objekte zurück (zum Beispiel attributes), die wenn sie leer sind, aber ein leeres Array zurückgeben. Diese Werte sollen besser generell ein Array sein:

     

    Vorher

    "attributes":{  
      "section":{  
        "name":"section",
        "type":"string",
        "unit":null,
        "translation":{  
          "de":"Themenbereich"
        },
        "value":"Wunderwald"
      },
      "quick_pass":{  
        "name":"quick_pass",
        "type":"boolean",
        "unit":null,
        "translation":{  
          "de":"FastPass Zugang"
        },
        "value":false
      },
      "single_rider":{  
        "name":"single_rider",
        "type":"boolean",
        "unit":null,
        "translation":{  
          "de":"Single Rider Zugang"
        },
        "value":false
      },
      "pre_show":{  
        "name":"pre_show",
        "type":"boolean",
        "unit":null,
        "translation":{  
          "de":"Mit Pre-Show"
        },
        "value":false
      }
    },

    Nachher (besser und einfacher zu benutzen):

    "attributes":[  
      {  
        "name":"section",
        "type":"string",
        "unit":null,
        "translation":{  
          "de":"Themenbereich"
        },
        "value":"Wunderwald"
      },
      {  
        "name":"quick_pass",
        "type":"boolean",
        "unit":null,
        "translation":{  
          "de":"FastPass Zugang"
        },
        "value":false
      },
      {  
        "name":"single_rider",
        "type":"boolean",
        "unit":null,
        "translation":{  
          "de":"Single Rider Zugang"
        },
        "value":false
      },
      {  
        "name":"pre_show",
        "type":"boolean",
        "unit":null,
        "translation":{  
          "de":"Mit Pre-Show"
        },
        "value":false
      }
    ],

    Bilder sollten außerdem eine Url (oder ein Objekt aus mehreren Urls) zurückgeben:

    {
      "id": "3471920c-c348-407d-95e4-c0e2a4cdf173",
      "contributor": {
        "id": "7268d2d6-50dc-4c49-970d-95206cef2f01",
        "username": "airtimeaddicted"
      },
      "name": "prod/t3eym3p4bkiqgrmjock0",
      "votes": 0
      "url": "https://pfad-zur-datei.jpg"
    },
    
    {
      "id": "3471920c-c348-407d-95e4-c0e2a4cdf173",
      "contributor": {
        "id": "7268d2d6-50dc-4c49-970d-95206cef2f01",
        "username": "airtimeaddicted"
      },
      "name": "prod/t3eym3p4bkiqgrmjock0",
      "votes": 0
      "urls": {
        "small": "https://pfad-zur-datei.jpg",
        "middle": "https://pfad-zur-datei.jpg",
    	"big": "https://pfad-zur-datei.jpg",
      }
    },

    So viel von meiner Seite aus :) 

  4. Die Api funktioniert nicht richtig. Wenn ich https://coaster-platform.org/api/attractions?page=1&itemsPerPage=1 auswähle werden dennoch alle Ergebnisse zurückgegeben und nicht nur eins. Außerdem sollte als Rückgabewert ebenfalls zurückgegeben werden, wie viele maximalen Seiten es gibt und auch, wie viele maximale Ergebnisse. Also  eine Art Meta-Objekt, zum Beispiel:

    {
      "meta": {
        "pagination": {
          "total": 50,
          "count": 10,
          "itemsPerPage": 1,
          "page": 1,
          "totalPages": 5,
          "links": {
            "next": " https://coaster-platform.org/api/attractions?page=2&itemsPerPage=1"
          }
        }
      }
    }

     

  5. vor 7 Minuten schrieb Sebi581:

    Danke.

    Und weiß jemand, was es mit diesen 48 Stunden im Voraus auf sich hat? Also die Tickets werden ja zu Hause gedruckt, wozu diese Regel und wie genau wird das kontrolliert?

     

     

    Der Zeitraum wird dazu dienen, eine bessere Kontrolle darüber zu haben, wie viele Personen das Angebot an einem bestimmten Tag nutzen möchten und gegebenenfalls die Anzahl der zu verkaufenden Tickets zu reduzieren, damit der Park nicht zu voll wird. Kontrolliert wird dies über den Barcode am Eingang. Dieser wird wohl auf ein festes Datum hinterlegt sein. Auf dem Ticket wird auch drauf stehen, dass das Ticket nur am Tag x gültig ist. Gehst Du an einem anderen Datum in den Park außer des hinterlegten, kommst Du nicht rein. Das Ticket wird als ungültig erkannt.

  6. vor 25 Minuten schrieb Thrillfreak:

    Warum gibt es keine Parkflat mit der man auf dem Parkplätz am Haupteingang parken kann? Kann mir das einer erklären?


    Du spielst sicher auf die Parkfläche gegenüber vom Eingang Berlin an: die Parkpläche ist für Mitarbeiter gedacht und reicht für diese schon kaum aus. Gibt man die Fläche frei für EP-Inhaber, suchen sich die Mitarbeiter morgens eine Wolf.

  7. Zurzeit versuche ich alle 2 Wochen eine neue Testversion zu veröffentlichen. Alle die die App installiert haben bekommen diese neuen Versionen automatisch. Generell hat sich viel getan und die Entwicklung ist in vollem Gange.

     

    Hin und wieder stockt alles leider ein wenig da auf Anpassungen der Forensoftware gewartet werden muss.

     

    Dieser Beitrag wurde übrigens über die App verfasst ?

  8. vor 14 Minuten schrieb LuPi:

    Das ist sowas von arm

    man sollte den Techniker fristlos kündigen und jemand einstellen der den Aufzug repartieren kann 

     

    Ohne Dich angehen zu wollen, aber sowas sollte man sich doch bitte verkneifen. Ohne zu wissen, warum der Aufzug außer Betrieb ist, die technischen Fähigkeiten der Angestellten eines Unternehmens (die sicher entsprechend ihrer Fachrichtung dort beschäftigt sind) derart anzugehen, finde ich geht ein wenig zu weit. Ich verstehe den Unmut, dass der Aufzug defekt ist und die Wartezeiten die daraus resultieren. Aber das hier geht definitiv zu weit. Am Ende liegt es einfach an einem Ersatzteil oder hat andere Gründe, die hier nicht festgestellt werden können.

  9. vor 13 Minuten schrieb PasXal:

    Da kann nur @Tommy was zu sagen, allerdings muss man auch beachten das man sich dadurch ggf. ins PHL einloggt obwohl man in einem anderen Freizeitpark ist.

    Kann implementiert werden, wenn von der Mehrheit erwünscht. Könnte auch so erweitert werden, dass jeder User selbst entscheiden kann, welcher Park vorausgewählt ist. Es würde dann eine Einstellung im Profil geben. Damit wäre dann jedem geholfen, oder?

  10. vor 36 Minuten schrieb unravel:

    Wenn man sich einmal in einem Park anmeldet, dann wieder aus dem Park abmeldet und erneut anmelden möchte, wird sich in den vorherigen Park wieder eingeloggt. Man kann also keinen neuen auswählen. Das ist schlecht, sobald man sich verklickt oder für den unwahrscheinlichen Fall, das man zwei Parks an einem Tag machen würde. :D

     

    Das Verhalten ist vollkommen korrekt und eine reine Sicherheitsfunktion. In der Regel besucht man einen Park pro Tag. Wenn man sich verklickt kann das Team auf Anfrage den falschen Besuch löschen und einen anderen eintragen. 

     

    Zum Thema counten auch hier noch einmal der Hinweis, dass die Funktion dafür nicht gedacht ist und dies auf anderen Plattformen gemacht werden kann. Die Funktion wurde nur dafür entwickelt um zu sehen ob sich vielleicht zum Zeitpunkt eines Besuches andere im selben Park befinden um ggfs ein Treffen zu vereinbaren.

×
×
  • Neu erstellen...