-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option zum Auslassen von eingebetteten Listen mit einem Filter für #396 #397
Conversation
Ich glaube hier wäre zusätzlich auch Paper.consultation betroffen. Und guter Einwand zu agendaItem, wobei gerade das eine der "schwergewichtigsten" inneren Listen ist. Wenn man die AgendaItem-Liste für Updates zumindest auf die Reihenfolge reduzieren will, könnte man eine neue Eigenschaft einführen ( |
Wofür benötigt man eine |
Ich fände es hilfreich, wenn Vorschläge wie ‘agendaItemOrder‘ in separaten Issues gemacht würden. |
@akuckartz Ich sehe das schon als eine Diskussion zu diesem konkrenten Vorschlag von @konstin.
@sterni24 Die Idee ist meinem Verständnis nach, dass man alle Objektlisten mit Mal angenommen, zur Tagesordnung eines geplanten Meetings kommt nach der Begrüßung ein neues AgendaItem "Gastrede" hinzu. Bei der Abfrage der geänderten Meetings mit Das ist aber wiederum ungünstig, weil gerade die AgendaItem-Liste in der Regel relativ viele Daten enthält. Darum habe ich darauf hingewiesen, dass man diese Liste doch weglassen könnte, wenn man die darin enthaltene nicht-redundante Information (die Reihenfolge der AgendaItems) auf andere Weise überträgt, wenn die eigentliche agendaItems-Liste weggelassen wird. Das könnte erreicht werden, indem man statt der Liste der AgendaItems eine Liste von AgendaItem-IDs im Meeting-Objekt überträgt (also ein array of url (AgendaItem), wie es in der Spezifikation heißen würde). Um es ganz konkret auszudrücken (angelehnt an die Spezifikationsformulierungen): Der Server soll bei Verwendung von
Der letzte Teil meines Kommentars ging eigentlich schon zu tief ins Detail. Es ging lediglich darum, dass manche es naheliegend finden könnten, die oben genannte Liste der AgendaItem-IDs ebenfalls unter dem Eigenschaften-Namen "agendaItem" zu übertragen. Dann könnte diese Eigenschaft allerdings entweder eine interne Objektliste enthalten (wenn das Meeting-Objekt "normal" ausgegeben wird) oder eine Liste von URLs (wenn der Client Weil es zumindest in unserem Client-Code umständlicher wäre wenn eine Eigenschaft mit dem gleichen Namen manchmal eine interne Objektliste ist und manchmal eine Liste von URLs, gehe ich davon aus, dass auch andere Client-Entwicker (und vielleicht auch Server-Entwickler) es bevorzugen würden, für die Liste von AgendaItem-URLs einen anderen Namen zu verwenden als für die interne Objektliste. Darum hatte ich den Eigenschaftennamen Ich hoffe damit ist mein Kommentar nun verständlicher. Das ganze war nur als kurzer Hinweis auf einen möglichen Lösungsansatz gedacht. |
Da #125 (comment) erwähnt wurde erlaube ich mir eine Randbemerkung: Ja, das war damals die saubere Lösung und basierend u.a. auf #165 wäre auch ein einfacher und nachhaltiger Update-Mechanismus möglich gewesen. Aber OParl wollte danach ja unbedingt schnell eigene Spezial-Lösungen schaffen statt generische zu nutzen (historisch Interessierte finden etwas Hintergrund in #237). |
28e653a
to
3b60c7e
Compare
3b60c7e
to
d5dfc62
Compare
@sterni24 @Medo42 Ich habe mit den Ergebnissen aus der Diskussion in #396 einen Entwurf für einen Parameter
omit_internal
geschrieben.