-
Notifications
You must be signed in to change notification settings - Fork 61
camp prototype model #1031
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
camp prototype model #1031
Conversation
Ich habe es wie folgt implementiert: Category und Activity leiten von AbstractContentNodeOwner ab. Die Zeiger von ContentNode auf AbstractContentNodeOwner benötige ich, um das Interface BelongsToCamp implementieren zu können. Sprich, damit ich herausfinden kann, zu welchem Camp ein ContentNode gehört. Mögliche Alternative: |
Für was habt ihr euch entschieden? |
Für die zweite Option, da dann der ContentNode-Baum unabhängiger vom jeweiligen Owner ist. Er ist immer noch nicht ganz unabhängig, da es für den Berechtigungs-Check nötig ist, vom ContentNode aus zum Camp zu finden. Also wird (noch) nix mit komplett unabhängigen, wiederverwendbaren ContentNode-Bäumen. Wir haben noch kurz eine dritte, noch "extremere", noch stärker normalisierte Variante besprochen, nämlich gar keinen Ich bin der Meinung dass die gewählte Option im Moment ausreicht, und trotzdem noch flexibel zu migrieren ist, falls wir uns umentscheiden sollten. |
PR is ready to merge. Enthalten:
Nicht enthalten:
Bevorzugte ContentTypes pro Category ist ein neues Feature -> eigener PR. Temporärer Effekt: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Ein paar Anmerkungen (wie immer), aber hoffentlich keine fundamentalen Änderungen mehr diesmal ;)
backend/module/eCampCore/data/prod/MaterialListPrototypeData.php
Outdated
Show resolved
Hide resolved
backend/module/eCampCore/src/ContentType/BaseContentTypeService.php
Outdated
Show resolved
Hide resolved
if (is_subclass_of($this->entityClass, BaseContentTypeEntity::class)) { | ||
$q->join('row.contentNode', 'cn'); | ||
$q->join('cn.activity', 'a'); | ||
$q->andWhere($this->createFilter($q, Camp::class, 'a', 'camp')); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woher hat dieser Filter vormals gewusst, um welche Activity es gerade geht? Wo ist/war der Filter definiert?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ContentNode hat auf Activity gezeigt.
Activity auf Camp.
Camp-Filter schränkt die Sicht von User ein.
Durch diese Joins wurden die möglichen sichtbaren ContentTypes eingeschränkt.
fa7500a
to
c176938
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super, danke! Ich mach mich dannmal dran, dass man wieder mehrere ContentNodes in einer Activity haben kann :)
Super, jetzt können sich auch andere einen Teil des Kuchens schnappen und loslegen. Habe es getestet, was nicht funktioniert:
Das sollte man später noch fixen. Die Logs vom Print:
|
MaterialList & Print habe ich geflickt. |
Isseu: #834
Edit