Reprezentacja VMB w systemie Drupal 7

Page status: 
Needs updating

Przedstawiony tutaj model reprezentacji, może ulegać zmianie wraz z rozwojem aplikacji VMB. Jest to więc wersja rozwojowa specyfikacji, która wymaga dalszego precyzowania, dlatego prosimy o zgłaszanie uwag oraz komentarzy.

W opisie stosowane są angielskie nazwy występujące w drupalu. Alternatywnie odsyłamy do ich odpowiedników w języku polskim.

Entity

Wraz z wersją Drupal 7 wprowadzono pojęcie "Entity". Node znany z Drupal 6, to tylko jeden z możliwych Entity Types w Drupal 7; inne przykłady to: Comments, Taxonomy terms i User profiles.

Entity wprowadza użyteczną abstrakcję i może być bardzo efektywnym narzędziem w odpowiednich projektach. Wraz z pojawieniem się Entity, Drupal nie musi być już więcej ograniczony tylko do roli systemu CMS.

Więcej o pojęciu Entity: An Introduction to Entities.
Na podanej stronie, znajduje się także informacja opisująca Entity, z punktu widzenia programowania obiektowego (niekoniecznie prawdziwy z perspetywy purysty):

  • entity type to base class
  • bundle to extended class
  • field to class member, property, variable lub field instance (w zależności od preferencji nazewnictwa)
  • entity to object lub instance of a base lub extended class

Wszystkie te cztery koncepcje mogą być serializowane (przechowywane - np. w bazie danych lub pliku). Serializacja odbywa się przez Entity API. Więcej o Entity API.

Podstawowe elementy VMB

  • Baza - wraz ze stanem świata zewnętrznego (temperatura, siła wiatru, itp.).
  • Obiekty (urządzenia, przedmioty, itp.).
  • Moduły (pomieszczenia bazy).
  • Użytkownik.
  • Awatar (członek załogi).
  • Interakcja - kontakt użytkownika z symulacją.
  • Zdarzenia (Events) - np. czynności i ich konsekwencje.

Być może Baza, Obiekty i Moduły mogą być sprowadzone do tego samego typu obiektu (bundle). Jest to obecnie ustalane.

Dodatkowe informacje: świat VMB w dokumencie wizji.

Entity w VMB

Podczas planowania reprezentacji elementów VMB, można wzorować się na istniejących modułach, bazujących na Entity: Profile2, Drupal Commerce, Message, Model, Entity API oraz innych zasobów.

Dlaczego nie Entity Type Node?

Domyślnie dostępny w Drupal Entity Type Node, w przypadku obiektów VMB, posiada wiele niepotrzebnych własności, jak np. comment, sticky, promote, revisions, itp. oraz wywoływane funkcje. Obiekty VMB mają zawierać głównie wartości opisujące ich stan, dlatego tworzymy Entity Types specjalnie do tych potrzeb.

Entity na przykładzie tworzenia obiektów VMB

W celu pełniejszego zrozumienia Entity w VMB, zobrazujemy to na przykładzie obiektu śluzy, których może być kilka w jednej bazie. Każda śluza jest oddzielnym obiektem tego samego typu, co oznacza, że wszystkie śluzy posiadają te same parametry, ale mogą różnić się ich wartościami. W pewnych okolicznościach, śluaza A może ulec awarii, ale B, C i D nie.

Korzystając z terminologii Entity, np. na tej stronie, mamy następujące relacje:
Entity type + properties > Bundle + fields > Entities,
która w naszym przykładzie przyjmuje postać:
Entity type VMB > Bundle Object > 4 śluzy (A, B, C, D)
Podczas tworzenia przez użytkownika nowej Bazy (bundle Base), generowane są automatycznie wszystkie przypisane do niej obiekty (bundle Object), między innymi śluzy. Moduł tworzy odpowiednią ich ilość, przy czym każdy obiekt (i tym samym każda śluza) ma inny ID. Dodatkowo śluzy różnią się np. pozycją. Każdy obiekt śluza jest indywidualny, co oznacza, że w czasie trwana symulacji ich stany mogą być różne, np. inne wartości pola szczelność.

Domyślne wartości obiektów tworzone są na podstawie informacji znajdujących się w kodzie aplikacji VMB.

Baza

Entity info

  • Entity type: VMB.
  • Bundle: Base.
  • Pola: zawiera wszystkie niezbędne pola (fields) opisujące świat bazy (symulacji): temperatura, siła i kierunek wiatru, czas powstania bazy, nazwa bazy, itp. Do czasu sprecyzowania pól, ich wartości będą serializowane w jednym polu 'data'.

Tworzenie Bazy i świata symulacji

Przygotowanie symulacji bazy (choć niekoniecznie jej rozpoczęcie), następuje w momencie utworzenia entity Base przez użytkownika. Jedną z kolejnych wymaganych czynności, w celu rozpoczęcia symulacji, jest wprwadzenie przez użytkowników swoich awatarów (członków załogi) do bazy.

Podczas tworzenia każdej nowej bazy (entity Base) przez użytkownika, moduł VMB tworzy automatycznie całą niezbędą kolekcję entities dla tej bazy (jak pomieszczenia, urządzenia, itp.), Entities te zawierają identyfikator tworzącej je bazy. Dzięki temu wiadomo, do jakiej symulacji są one przypisane.

Na tak przygotowanej strukturze bazy, możemy rozpocząć symulację poprzez:

  • Cyklicznie wywołanie CRON, w celu wykonania odpowiednich algorytmów przliczających wartości świata bazy i wszystkich powiązanych z nią obiektów. W przypadku dużej liczby baz, można je kolejkować za pomocą Drupl Queue (patrz też prezentacja).
  • Interakcja użytkownika (awatara) na obiektach, przez interfejs użytkownika (UI). Na przykład przestawianie kontrolek urządzenia, zmiena parametrów, itp. Jednym z narzędzi pomocnych w projektowaniu elementów interfejsu jest jQuery UI (patrz też prezentacja).

Obiekty (urządzenia, przedmioty, itp.)

Entity info

  • Entity type: VMB.
  • Bundle: Object.
  • Pola:
    • Część pól jest identyczna dla wszystkich obiektów (np. nazwa, rozmiar, waga, referencja do innego obiektu, itp.).
    • Niektóre obiekty mogą zawierać indywidualny zestaw pól (np. objętość wody w zbiorniku, szczelność okna, stan baterii w urządzeniu, itp.). Pola indywidualne serializowane są w polu 'data' obiektów.
    • Obiekty posiadają także informacje niezmienne w czasie, które są identyczne dla każdej kopii obiektu (te same obiekty, ale występujące w innych symulacjach). Na przykład: opis obiektu, zdjęcie lub inne media, itp. Informacje te nie są przechowywane w każdym obiekcie w bazie danych, lecz w plikach aplikacji (np. w object.inc). Informacje te są pobierane i wyświetlane na podstawie porównania nazw obiektów (z bazy danych i kodu). Nie ma sensu powielania tych informacji w każdym obiektem w bazie danych.

Lista obiektów

Aktualna lista obiektów.

Moduły (pomieszczenia i inne przestrzenie)

Entity info

Reprezentacja modułu nie jest jeszcze ustalona i wymaga ustalenia.
Obecnie są dwie wersje:

  • Entity type: VMB.
  • Bundle: Module lub Object (zwykły obiekt z przestrzenią wewnętrzną).

Module info

  • Moduły posiadają przestrzeń wewnętrzną, w której mogą znajdować się inne obiekty.
  • Niektóre moduły posiadają przegrody oddzielające (przykład 1, przykład 2). To czy wydzielone przestrzenie stanowią oddzielne moduły wymaga ustalenia.

Użytkownik

Użytkownik jest domyśnie dostępny w systemie Drupal, który tworzony jest w procesie rejestracji. Użytkownicy tworzą Bazy i Awatary (członków załogi), którymi następnie zarządzają. Patrz też uczestnik VMB w Dokumencie Wizji VMB.

Do podstawowego zestawu pól użytkownika, można dodać kolejne, jak wiek, języki, itp.

Awatar (członek załogi)

Entity info

Reprezentacja awatara nie jest jeszcze ustalona.
Obecne propozycje:

  • Entity type: VMB lub Profile (z modułu Profile2)
  • Bundle: Avatar (zdefiniowany przez VMB) lub Profile (zdefiniowany przez moduł Profile2 i rozbudowany przez VMB).

Avatar info

  • Obecnie ustalamy, że użytkownik może posiadać więcej niż jednego awatara.
  • Przykładowe pola: nazwa, aktualna pozycja, zmęczenie fizyczne, itp. (więcej pól w dyskusji dotyczącej pól awatara). Na początek wystarczy tylko pozycja.
  • Dodatkowo, awatar może wyświetlać informacje użytkonika, takie jak znajomość języków.
  • Przemieszczanie się awatara - sposób poruszania się i sterowania oraz to czy w ogóle ma się poruszać po plannszy, nie jest obecnie ustalone. Z pewnością zagadnienie to będzie się klarować w miarę postępów nad aplikacją VMB. Na początkowym etapie projektowania, ruch awatara można zaniedbać, czyli będzie to zwykłe przechodzenie między stronami. Najważniejsze to lokalizacja awatara względem innych obiektów i przeprowadzanie interakcji z nimi oraz symulacja jego wartości (np. zmęczenie, itp.).

Interakcja

Interakcja nie potrzebuje reprezentacji, jest to stan utrzymania symulacji w kontakcie z użytkownikiem, który ma wpływ na wyświetlane informacje i przebieg symulacji.

Interakcja jest zapewniona m.in. przez interfejsy użytkownika dostarczone z Drupalem. Konsekwencją interakcji użytkownika z symulacją mogą być zdarzenia.

Zdarzenie (Event)

Reprezentacja tego elementu VMB wymaga ustalenia.

Więcej o zdarzeniach programowych na wikipedii.

Zdarzenie następuje np. w momencie próby otwarcia śluzy przez awatara.

Zdrzenia powiązane są z funkcjami/algorytmami w kodzie VMB. Obiekty mogłyby posiadać do nich referencje i dzięki temu wyświetlić listę akcji w zależności od sytuacji.

W celu przygotowania reprezentacji zdarzeń, należy opracować najbardziej ogólny dla nich model i być może sprowadzenie do odpowiedniego entity lub innego radzaju elementów.

Jedną z możliwości implementacji zdarzeń w VMB, jest zastosowanie Entity API i Rules:

  • The entity API introduces a unique place for metadata about entity relationships and entity properties: hook_entity_property_info(). This information about entity properties contains the data type and callbacks for how to get and set the data of a property. Modules may rely on this information in order to support any entity property, e.g. Rules and the Search API build upon that.
  • For entity types implemented based upon the provided CRUD API the API is providing additional module integration too, i.e. Rules events are provided for all CRUD-related hooks, some basic entity property information for hook_entity_property_info() is provided and exportable entities are automatically integrated with the Features module.
    These module integrations are implemented in separate controller classes, which may be separately overridden or enabled/deactivated.