Organigramm

Chriz · 23.06.2011, 15:17

Hallo,

wir haben bei uns in der Firma ein Organigramm, das die Mitarbeiter- und Teamstruktur, also Hierarchien und Zuständigkeiten abbildet. Wie es ungefähr aussieht (unkenntlich gemacht und s/w) könnt ihr im ZIP sehen. Es ist HTML mit JS, bei Mouseover gibt es Tooltips zu Mitarbeitern, wenn man Teams anklickt öffnet sich ein Popup mit einer Tabelle, die Unterteams, ihre Mitarbeiter und die Gruppierung nach Hierarchie und manchmal auch nach Fachrichtung anzeigt.

Momentan ist es so, dass das Organigramm zwar grundsätzlich aus den Datenbankwerten generiert wird:

Mitarbeiter
Stellung (normaler Mitarbeiter, Lead, PD, ..)
Teamzuordnung
Position (Entwickler, Grafiker, ..)

Aber nun kamen mit der Zeit immer mehr Anforderungen, die aus dem Rahmen gefallen sind. Team A soll nicht wie alle anderen alphabetisch einsortiert werden, sondern am Ende. Team B ist sowieso anders, hier kein Teamleader anzeigen. Mitarbeiter C hat eine Sonderrolle, der ist in 2 Teams. Ach und zukünftige Mitarbeiter und offene Stellen sollen auch noch rein. Ja und Team D hat drei Teamleader, hinter dem letzten Teamleader bitte noch "Projektmanager" einfügen.

Der Quellcode ist leider nicht getrennt nach EVA, sprich die Daten werden ausgelesen, Ausnahmen werden direkt mit if ($user->getAlias() == "Mitarbeiter D") .. eingefügt und es wird sofort als HTML ausgegeben. So wies halt passiert, aber nicht passieren sollte.

Jetzt möchten einige Abteilungen die kompletten Zuordnungen wie im Organigramm dargestellt als XML oder CSV haben. Wer ist wem fachlich bzw. disziplinarisch zugeordnet.

Lange Rede kurzer Sinn, die alte Datenstruktur und Erzeugung des Organigramms ist hinfällig (und übrigens auch nicht von mir), es soll nach Möglichkeit still und leise neu gemacht werden.

Ich möchte das jetzt richtig machen und flexibel genug bleiben, alle kommenden Anforderungen umsetzen zu können. Dazu brauche ich erstmal ein Konstrukt, das die die Daten des Organigramms vorhält, so wie sie aus der Datenbank ausgelesen wurden. Natürlich wäre es toll, wenn alle Wünsche direkt über die Datenbank gesteuert werden könnten (Team B hat keinen Teamleader, ..), aber ich denke nicht, dass das möglich ist.

Also suche ich eine Technik oder ein Entwurfsmuster, dass es mir ermöglicht dieses Konstrukt noch einmal manuell zu bearbeiten. Ich dachte da an Plugins, die man an der Organigrammklasse registrieren kann und die die internen Daten manipulieren kann.

"Bevor Mitarbeiter X im Kontext "Teamleader im JS-Popup anzeigen" ausgegeben wird, füge ein " (Projektmanager)" als Postfix hinzu."
Nur weil bei einer Person so ein Postfix nötig ist, lohnt es sich nicht das über die Mitarbeiterverwaltung in unserem System zu ermöglichen. Ganz abgesehen davon, dass es sehr komplex werden würde und unsere HR, die das übernimmt, da sicherlich verständlicherweise nicht mehr durchblicken würde.

Also gehe ich davon aus, dass es weiterhin programmierte Quickhacks geben wird, die man aber einfach hinzufügen oder entfernen können soll. Da kam mir die Idee mit Plugins. Ist das eine gute Wahl? Gibt es ein Plugin-Entwurfsmuster?

Derzeit sieht meine Klassenstruktur so aus:

Organigram.php
-- Person.php
-- PersonList.php
-- Team.php
-- TeamList.php
-- Renderer
---- Xhtml.php
-- Plugins
---- Default.php
---- MitarbeiterXYhasPostfixName.php
-- Source
---- Xml.php
------ Dom.php (benutze ein Dummy-XML als Quelle statt der DB)
---- Db
------ Mysql.php
(und einige Interfaces)

Source erstellt Organigram aus Datenquelle, bestehend fast nur aus Person/PersonList/Team/TeamList Instanzen und einigen Metadaten.
Am Organigramm registrieren sich Plugins zur gezielten Manipulation
Renderer für XHTML rendert Organigramm über Templates

Das Zusammenspiel Renderer, Organigramm und Plugins ist mir selbst aber nicht hundert Prozent klar (gefährliches Halbwissen

). Wer ruft wen nun auf?

PHP-Code:

  <?php
$source = Organigram_Source_Xml_Abstract::factory(); // DOM oder SimpleXML, was da ist
$source->loadFile("dummy-orga.xml");

$organigram = $source->getOrganigram();
$organigram->registerPlugin(new Organigram_Plugin_Default());

$renderer = new Organigram_Renderer_Xhtml();
$renderer->setTemplate("templates/xhtml/organigram.php");
$renderer->setOrganigram($organigram);
echo $renderer->display();
?>

Mein derzeitiger Entwurf ist, dass der Renderer eben ein Template lädt und darin die Daten vom Organigramm geholt werden. Wenn es etwas greifbares zu rendern gibt (Mitarbeiter, Team) wird ein Context definiert

(im Template, $this = Renderer)
echo $this->_renderPerson($person, "Vorstandsliste")

Beim Kontext soll sich nun das Plugin einschalten können um zu definieren, dass Vorstände immer mit zusätzliche Präfix (CEO, CFO, CBO, ..) ausgegeben werden. Aber der Aufruf geschieht ja eigentlich im Renderer, $person stammt zwar aus dem Organigramm, ist aber nur eine Person-Instanz. Das Plugin ist eigentlich garnicht mehr greifbar.

Versteht ihr etwa mein Problem? Ich will nicht, nur weil ich einen Renderer und Plugins habe einfach losdonnern und wild jeder-ruft-jeden-auf-wenns-ihm passt programmieren, sondern ich würde gern für dieses komplizierte Thema eine korrekte programmatische Lösung finden. Notfalls auch in dem ich mein bisheriges Zeug verwerfe.

tr0y · 24.06.2011, 01:52

Ich persönlich würde das Organigramm per XSLT modular erzeugen, ausgehend von einem 3-Level-System. Wobei das erste und zweite Level zum generellen Manipulieren der XML-Daten zuständig wären und das 3te Level aus dem modular eskalierten XML-Baum den letztendlichen HTML-Content erzeugt. Ich liefer hier Erzeugungs-Code zur Veranschaulichung, aber generell keinen Klassen-Source, da ich denke das du dir darüber lieber selbst deine Gedanken machen möchtest.

Level 1: Bones to the Root-Ebene
Das erste Level ist quasi der Ausgangspunkt der Klasse, die Rohdaten der Datenbank. Die reinkommenden Daten werden auf dieser Stufe ohne Verknüpfungen der Zugehörigkeit von bspw. Teams, ect. in den XML Baum gelegt, als Kindelemente des Root-Elements:

PHP-Code:

  $org = new Organigramm();

 
while ( $data = $resultOfDB->fetch_object() ) {

   $org->import( $data->name, $data->team, $data->position );

}

Code:

<staff>
   <employee team="x" position="y">Mitarbeit1</employee>
   ...
</staff>

Level2: Modular Bone to Duty-Ebene
Das zweite Level dient als Registrierungs-Ebene der Module, die beim finalen Rendern entscheiden was das Organigramm darstellt. Inwieweit man diese Modularität eskalieren lassen möchte, bleibt dir überlassen. Du kannst hier beispielsweise als View-Template eine weitere XML benutzen, die als View-Pattern fungiert und festlegt das bspw. Team A + B dargestellt werden, bei Team A Feld X+Y als Tooltip-Entity im HTML-Source landen, sodas du per jQuery Tooltip Plugin den Title-Source zur Darstellung des Mouseover-Headups nutzen kannst. Team B zwar eine Pattern-Instanz des gleichen Templates wie Team A ist, allerdings dort der Leader nicht dargestellt wird. ( Stichwort: Template Inheritance ). Die einzelnen Module erzeugen aus der Ursprungs XML einen neuen XML Baum der die einzelnen Gruppen-Nodes erzeugt und die jeweiligen Member als Employee-Extensions angliedert:

PHP-Code:

  $org->registerModule( new ogModule_Team_Common ('Team A') ); // Team: Common View: Team A

$org->registerModule( new ogModule_ChiefTechnicalOfficer () ); // CTO

$org->registerModule( new ogModule_ChiefExecutiveOfficer () ); // CEO

$org->registerModule( new ogModule_ChiefFinancicalOfficer () ); // CFO

$org->registerModule( new ogModule_HeadOfCostumerSupport () ); // HoCS

Code:

<staff>
   <group id="commonTeam" team="Team A">
      <developer lead="yes">Mitarbeiter1</developer>
      <developer>Mitarbeiter2</developer>
      <developer>Mitarbeiter3</developer>
      <designer>Mitarbeiter4</developer>
   </group>
   <group id="headQuarter">
      <cto>Mitarbeiter20</cto>
      <ceo>Mitarbeiter1</ceo>
      <cfo>Mitarbeiter293</cfo>
      <hocs>Mitarbeiter5</hocs>
   </group>
</staff>

Level3: Bone-Collection to HTML-Ebene
Das dritte und letzte Level würde dann aus der Aufbereiteten XML ( ebenfalls wie von Level 1 zu 2 per XSLT ) HTML Source erzeugen. Hierbei könnte wiederum eine View-Pattern dazu genutzt werden zu entscheiden wie und wann sowie wo welche "group" im HTML-Baum erzeugt wird. An dieser Stelle würde die Klasse dann mit einer Template-Engine die mitunter vielleicht in der Anwendung wo dieses Organigramm erzeugt werden soll existiert, bspw. Smarty.

PHP-Code:

  $org->setSmarty( SmartyFactory::factory() );

$org->setTemplate('organigramm.tpl');

 
$body = $org->build();

 
$smarty = SmartyFactory::factory();

$smarty->assign('content', $body);

 
$smarty->display('global_index.html');

Zumindest würde das so in etwa dabei rauskommen, wenn ich mir über so ein Problem Gedanken machen müsste..

Chriz · 26.06.2011, 14:13

Hallo tr0y,

wir hatten uns auch überlegt, XML + XSLT einzusetzen, weil es sich quasi angeboten hat. Die Entitäten, die Entity-Relationships und die Transformation wären ideal für XML + XSLT. Andererseits bin ich kein Fan von XSLT, da selbst kleine Transformationen relativ komplex werden können.

Ich habe das Problem mit Kollegen durchgesprochen und wir sind zu folgendem Ergebnis gekommen:

Das Organigramm enthält zwei offensichtliche Entitäten:

- Mitarbeiter
- Teams

Entity-Relationships:

- Mitarbeiter hat Vorgesetzten
- Team hat übergeordnetes Team (optional)
- Team hat Mitarbeiter (üblicherweise 1:n, gelegentlich n:m)

Die Problematik wer bei welcher Zuordnung wie dargestellt wird, kann man über eine zusätzliche Entität lösen:

- Rollen (vorher angedacht als "Kontext")

Jede Mitarbeiterposition im Organigram wird einer Rolle zugeordnet:

- Teamleiter für Team X
- CEO
- Assistance & Secretary für CBO
- normaler Mitarbeiter im Team Y
- Entwickler im Spartenteam Z
- ..

Das Grundgerüst sieht daher vor, alle verfügbaren Daten aus der Quelle auszulesen (DB, für Testzwecke nur eine Dummy-XML) und Rollen zuzuweisen:

Code:

<?xml .. >
<organigram>
  <meta>
    ..
  </meta>
  <data>
    <personList>
      <person id="P1">
        <firstname>Max</firstname>
        <roleList>
          <role ref-id="R1">
            <template>Chef Nummer 1</template>
          </role>
        </roleList>
        <teamList>
          <team ref-id="T1" />
        </teamList>
     </person>
      <person id="P2">
        <firstname>Peter</firstname>
        <roleList>
          <role ref-id="R2" />
        </roleList>
     </person>
     ..
    </personList>
    <teamList>
      <team id="T1">
        <name>Team Eins</name>
        <teamList>
          <team ref-id="T2" />
        </teamList>
      </team>
      <team id="T2">
        <name>Team Zwei</name>
      </team>
    </teamList>
    <roleList>
      <role id="R1">
        <name>CEO</name>
        <template>CEO %name%</template>
      </role>
      <role id="R2">
        <name>CBO</name>
        <template>CBO %name%</template>
      </role>
      ..
    </roleList>
  </data>
</organigram>

Jede Beziehung (mit "ref-id" Attribut) wird zunächst aufgelöst, kann aber im Einzelnen überschrieben werden (z.B. <template> bei Max für die CEO-Position).

Diese Datenliste wird in ein Organigram-Objekt gelesen, das einzelne Objekte für Team, TeamList, Person, PersonList, Role und RoleList besitzt. Nach dem das Organigram aus der Quelle ausgelesen wurde, kann ich normal auf die Daten zugreifen:
$team = $organigram->getTeamList()->getTeam("T2");
Wenn ich alle Mitarbeiter eines Teams ermitteln möchte, muss ich
$organigram->getTeamUserList($team);
aufrufen.

Letztlich habe ich dann nur einige Arrays, die die Entitäten und die Entity-Relationships speichern. Also einfache, wenig verschachtelte Datenstrukturen (was ich neben der Einführung von Rollen für den wichtigsten Punkt halte). An dieser Stelle nun kann ein Plugin oder ein Customizer die Daten abrufen und seine eigenen Daten einbinden oder existierende bearbeiten. Einen Array bearbeiten wird man ja noch hinbekommen

Zum Beispiel steht in der Datenbank bei uns nirgends, wer Teamleader ist und das soll voraussichtlich auch so bleiben. Es ist vielmehr derjenige mit der höchsten Stelle (Level) im Team. Das ist für mich eine Implikation, also kommt sie in einen eigenen Customizer:

PHP-Code:

  <?php
$roleList = $organigram->getRoleList(); // alle Rollen, Typ: ArrayObject
$roleUserLists = $organigram->getRoleUserLists(); // alle Zuordnungen Rollen zu Mitarbeitern -> verschachtelter Array

foreach ($organigram->getTeamList() as $team) {
  // für jedes Team wird eine eigene Rolle angelegt und dem entsprechenden Mitarbeiter zugewiesen
  $role = new Organigram_Role();
  $role->setId("teamleader-" . $team->getId());
  $role->setName("Team Leader " . $team->getName());
  $roleList[$role->getId()] = $role; // dank ArrayAccess

  $userList = $organigram->getTeamUserList($team);
  $userList->sortLevel()->rewind(); // nach Level sortieren und Arraypointer zurücksetzen
  $boss = $userList->current(); // nur Bsp. Code, könnte ja auch leere Teams geben
  
  $userRoleLists[$role->getId()][$boss->getId()] = array();
  // leerer array() deshalb, weil nichts von der Rolle überschrieben werden soll,
  // beim Beispiel oben ("Chef Nummer 1") müsste ich array("template" => "Chef Nummer 1") schreiben
  // später Auslesen per Fliegengewichtspattern, werden sonst zuviele Objekte
}
?>

Wo ich diesen Code ausführe ist egal, vermutlich in Organigram_Customizer_TeamLeader.php, so dass ich mehrere Customizer über die Daten rennen lassen kann.
Wenn die Daten nun korrekt sind, kann ich sie an den Renderer übergeben. Derzeit gibts nur XHTML, aber XML oder eine sonstige Form ist denkbar.

PHP-Code:

 
<div>
  <?php echo $this->_renderRole("CEO"); // holt sich alle Mitarbeiter mit der Rolle "CEO" und rendert sie anhand <template> ?>
  <?php echo $this->_renderRole("CFO"); ?>
</div>
<div>
<?php
$teamList = $this->_organigram->getTeamList()->filterType(array("Abteilungen", "Sonderabteilungen")); // jedes Team hat einen "type", oben nicht vermerkt
foreach ($teamList as $team) {
  echo $this->_renderTeam($team);
  echo $this->_renderRole("teamleader-" . $team->getId());
}
?>

So sieht das Generieren dann in etwa aus:

PHP-Code:

  <?php
$source = Organigram_Source_Xml_Abstract::factory(); // Dummy-XML mit DOM/XPath auslesen
$source->loadFile("./organigram-dummy.xml");

$organigram = new Organigram();
$organigram->load($source);

$customizer = new Organigram_Customizer_TeamLeader();
$customizer->customize($organigram);

$renderer = new Organigram_Renderer_Xhtml();
$renderer->setOrganigram($organigram);

echo $renderer->render("./templates/xhtml/organigram/layout.php");
?>

Jetzt sollte eigentlich alles bisherige damit möglich sein. Wenn ich das Laden der Customizer noch über eine Konfig löse, sogar ohne Codeänderung am eigentlichen Generator-Skript.

tr0y · 26.06.2011, 14:23

Okay, ist ja prinzipiell "das selbe in Grün", wobei ihr das Rendering nicht in Klasse vornimmt und die Klasse selbst auch nicht die XML zusammenbaut um sie zu modifizieren. Schlussendlich kann man bei meinem "Design" allerdings darauf verzichten etwaigen PHP-Code zusammenzuschrauben um entsprechende Costumizer zu erzeugen, das sind dann die einzelnen XSL-Templates.

anyway, danke für die Info, wir laufen beide in die selbe Richtung ^^

Chriz · 26.06.2011, 14:33

Ja, ist grundsätzlich das gleiche, ich denke eine andere sinnvolle Lösung gibt es auch nicht, als eine Schicht einzuklemmen, die die Manipulation erlaubt.

Nutzt du denn viel XSLT? Wir haben das bei uns im alten Intranet (XP-Framework), ganz schrecklich und ich befürchte, dass man dafür wiederum eine Extension braucht, die das umwandelt, denn clientseitig möchte ich das nicht lösen.

tr0y · 26.06.2011, 14:51

Nunja, ich nutze XSLT wo es sinnvoll ist. Wenn ich größere oder unbestimmt große XML-Bäume neu arangieren muss greif ich eher auf XSLT zurück als es per SimpleXML oder anderen nativen PHP-Modulen zu lösen. Angewendet werden die XSL-Templates serverseitig per DOMDocument + XSLTProcessor ( http://de.php.net/manual/de/class.xsltprocessor.php ).

XSLT ist bei der Manipulation am flexibelsten ( meiner Meinung nach ) und ich benötige bspw. in deinem Fall zum entwickeln der Costumizer keine Entwicklungsumgebung auf der die Software läuft ( für Tests ), sondern lediglich einen aktuellen Browser und die Ursprungs-XML.

Allerdings stimme ich dir in Sachen Source-Volumina der einzelnen Templates zu, einige "Geschichten" eskalieren in deutlich mehr Quellcode als es sein Equivalent in PHP benötigen würde, was mir wiederum die Entscheidung vorhält wann für ein Projekt XSLT sinnvoll wäre und wann nicht.

nikosch · 27.06.2011, 23:08

Zitat:

Jede Mitarbeiterposition im Organigram wird einer Rolle zugeordnet:

Leg das am besten auch gleich m:n an

Chef == Teamleiter == Projektleiter == Entwickler - der ganz normale Wahnsinn

[edit]

Zitat:

Organigramm.zip

Aua, ist das in 3D? Augenschmerz lass nach, ich glaub ich muss mal zum Optiker...

Chriz · 27.06.2011, 23:54

LOL, schlag das nicht unserer HR vor.
Ne musste es unkenntlich machen. Ist doch gelungen oder?

Chriz · 29.06.2011, 19:49

Wenn ich fertig bin werde ich mal meine komplette Umsetzung posten. Ich stuetz mich jetzt ganz auf Rollen. Im Prinzip ist das gesamte Organigramm ein Rollenbaum, dessen Blaetter User oder Teams sind.

Das Aussehen jeder Kombination User/Rolle und Team/Rolle kann angepasst werden.

z.B.
Rolle Organigramm besteht aus:
Rolle Vorstand
Rolle TeamUebersicht

Rolle Vorstand besteht aus:
Rolle CEO
Rolle CFO

Rolle CEO besteht aus:
User 1

Rolle CFO besteht aus:
User 2

..

Ich kann jetzt festlegen, wie ein Vorstand-User gerendert wird, aber auch noch einmal speziell, wie ein CEO-User gerendert wird. Dabei leg ich nur Texttemplates fest.

Als HTML kommt dann ein div/ul/li Konstrukt raus

Code:

<ul class="role-Vorstand">
  <li class="role-type-Role">
    <ul class="role-CEO">
      <li class="role-type-User">
        <div class="user user-1">
          CEO <div class="template template-name">User 1</div>
        </div>
      </li>
    </ul>
  </li>
  <li class="role-type-Role">
    <ul class="role-CFO">..</ul>
  </li>
  ..
</ul>

Bei Listen, z.B. Teammitgliedern kann eine Rolle noch einer Rollenfamilie angehoeren (role-family-TeamMember), dass sich dann im Rendering fuer XHTML als weitere CSS-Klasse wiederfindet. Damit kann ich im CSS alles ansprechen was ich will. Einziges Problem bei den Listen ist, dass komma-separierte Listen nicht funktionieren. Evtl. fuege ich dann bei allen Elementen noch ein "glue" (wie bei implode) ein, dass pro Rolle definiert werden kann.

Der Rollenbaum ergibt sich dann durch eine einfache Eltern-Kind-Beziehung in der Datenbank

User 1 hat Rolle CEO
User 1 hat Rolle TeamLeader-123
User 2 hat Rolle CFO
..

Ich hoffe dass ich damit dann wirklich die Probleme groesstenteils loese.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Organigramm generieren		PHP-Fortgeschrittene	1	28.07.2004 10:51
Organigramm generieren		PHP Tipps 2004	1	28.07.2004 10:50


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

24.06.2011, 01:52
tr0y Erfahrener Benutzer Registriert seit: 26.07.2010 Beiträge: 4.874 PHP-Kenntnisse: Fortgeschritten	Ich persönlich würde das Organigramm per XSLT modular erzeugen, ausgehend von einem 3-Level-System. Wobei das erste und zweite Level zum generellen Manipulieren der XML-Daten zuständig wären und das 3te Level aus dem modular eskalierten XML-Baum den letztendlichen HTML-Content erzeugt. Ich liefer hier Erzeugungs-Code zur Veranschaulichung, aber generell keinen Klassen-Source, da ich denke das du dir darüber lieber selbst deine Gedanken machen möchtest. Level 1: Bones to the Root-Ebene Das erste Level ist quasi der Ausgangspunkt der Klasse, die Rohdaten der Datenbank. Die reinkommenden Daten werden auf dieser Stufe ohne Verknüpfungen der Zugehörigkeit von bspw. Teams, ect. in den XML Baum gelegt, als Kindelemente des Root-Elements: PHP-Code: `$org = new Organigramm(); while ( $data = $resultOfDB->fetch_object() ) { $org->import( $data->name, $data->team, $data->position ); }` Code: <staff> <employee team="x" position="y">Mitarbeit1</employee> ... </staff> Level2: Modular Bone to Duty-Ebene Das zweite Level dient als Registrierungs-Ebene der Module, die beim finalen Rendern entscheiden was das Organigramm darstellt. Inwieweit man diese Modularität eskalieren lassen möchte, bleibt dir überlassen. Du kannst hier beispielsweise als View-Template eine weitere XML benutzen, die als View-Pattern fungiert und festlegt das bspw. Team A + B dargestellt werden, bei Team A Feld X+Y als Tooltip-Entity im HTML-Source landen, sodas du per jQuery Tooltip Plugin den Title-Source zur Darstellung des Mouseover-Headups nutzen kannst. Team B zwar eine Pattern-Instanz des gleichen Templates wie Team A ist, allerdings dort der Leader nicht dargestellt wird. ( Stichwort: Template Inheritance ). Die einzelnen Module erzeugen aus der Ursprungs XML einen neuen XML Baum der die einzelnen Gruppen-Nodes erzeugt und die jeweiligen Member als Employee-Extensions angliedert: PHP-Code: `$org->registerModule( new ogModule_Team_Common ('Team A') ); // Team: Common View: Team A $org->registerModule( new ogModule_ChiefTechnicalOfficer () ); // CTO $org->registerModule( new ogModule_ChiefExecutiveOfficer () ); // CEO $org->registerModule( new ogModule_ChiefFinancicalOfficer () ); // CFO $org->registerModule( new ogModule_HeadOfCostumerSupport () ); // HoCS` Code: <staff> <group id="commonTeam" team="Team A"> <developer lead="yes">Mitarbeiter1</developer> <developer>Mitarbeiter2</developer> <developer>Mitarbeiter3</developer> <designer>Mitarbeiter4</developer> </group> <group id="headQuarter"> <cto>Mitarbeiter20</cto> <ceo>Mitarbeiter1</ceo> <cfo>Mitarbeiter293</cfo> <hocs>Mitarbeiter5</hocs> </group> </staff> Level3: Bone-Collection to HTML-Ebene Das dritte und letzte Level würde dann aus der Aufbereiteten XML ( ebenfalls wie von Level 1 zu 2 per XSLT ) HTML Source erzeugen. Hierbei könnte wiederum eine View-Pattern dazu genutzt werden zu entscheiden wie und wann sowie wo welche "group" im HTML-Baum erzeugt wird. An dieser Stelle würde die Klasse dann mit einer Template-Engine die mitunter vielleicht in der Anwendung wo dieses Organigramm erzeugt werden soll existiert, bspw. Smarty. PHP-Code: `$org->setSmarty( SmartyFactory::factory() ); $org->setTemplate('organigramm.tpl'); $body = $org->build(); $smarty = SmartyFactory::factory(); $smarty->assign('content', $body); $smarty->display('global_index.html');` Zumindest würde das so in etwa dabei rauskommen, wenn ich mir über so ein Problem Gedanken machen müsste.. __________________ Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

26.06.2011, 14:13
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.269	Hallo tr0y, wir hatten uns auch überlegt, XML + XSLT einzusetzen, weil es sich quasi angeboten hat. Die Entitäten, die Entity-Relationships und die Transformation wären ideal für XML + XSLT. Andererseits bin ich kein Fan von XSLT, da selbst kleine Transformationen relativ komplex werden können. Ich habe das Problem mit Kollegen durchgesprochen und wir sind zu folgendem Ergebnis gekommen: Das Organigramm enthält zwei offensichtliche Entitäten: - Mitarbeiter - Teams Entity-Relationships: - Mitarbeiter hat Vorgesetzten - Team hat übergeordnetes Team (optional) - Team hat Mitarbeiter (üblicherweise 1:n, gelegentlich n:m) Die Problematik wer bei welcher Zuordnung wie dargestellt wird, kann man über eine zusätzliche Entität lösen: - Rollen (vorher angedacht als "Kontext") Jede Mitarbeiterposition im Organigram wird einer Rolle zugeordnet: - Teamleiter für Team X - CEO - Assistance & Secretary für CBO - normaler Mitarbeiter im Team Y - Entwickler im Spartenteam Z - .. Das Grundgerüst sieht daher vor, alle verfügbaren Daten aus der Quelle auszulesen (DB, für Testzwecke nur eine Dummy-XML) und Rollen zuzuweisen: Code: <?xml .. > <organigram> <meta> .. </meta> <data> <personList> <person id="P1"> <firstname>Max</firstname> <roleList> <role ref-id="R1"> <template>Chef Nummer 1</template> </role> </roleList> <teamList> <team ref-id="T1" /> </teamList> </person> <person id="P2"> <firstname>Peter</firstname> <roleList> <role ref-id="R2" /> </roleList> </person> .. </personList> <teamList> <team id="T1"> <name>Team Eins</name> <teamList> <team ref-id="T2" /> </teamList> </team> <team id="T2"> <name>Team Zwei</name> </team> </teamList> <roleList> <role id="R1"> <name>CEO</name> <template>CEO %name%</template> </role> <role id="R2"> <name>CBO</name> <template>CBO %name%</template> </role> .. </roleList> </data> </organigram> Jede Beziehung (mit "ref-id" Attribut) wird zunächst aufgelöst, kann aber im Einzelnen überschrieben werden (z.B. <template> bei Max für die CEO-Position). Diese Datenliste wird in ein Organigram-Objekt gelesen, das einzelne Objekte für Team, TeamList, Person, PersonList, Role und RoleList besitzt. Nach dem das Organigram aus der Quelle ausgelesen wurde, kann ich normal auf die Daten zugreifen: $team = $organigram->getTeamList()->getTeam("T2"); Wenn ich alle Mitarbeiter eines Teams ermitteln möchte, muss ich $organigram->getTeamUserList($team); aufrufen. Letztlich habe ich dann nur einige Arrays, die die Entitäten und die Entity-Relationships speichern. Also einfache, wenig verschachtelte Datenstrukturen (was ich neben der Einführung von Rollen für den wichtigsten Punkt halte). An dieser Stelle nun kann ein Plugin oder ein Customizer die Daten abrufen und seine eigenen Daten einbinden oder existierende bearbeiten. Einen Array bearbeiten wird man ja noch hinbekommen Zum Beispiel steht in der Datenbank bei uns nirgends, wer Teamleader ist und das soll voraussichtlich auch so bleiben. Es ist vielmehr derjenige mit der höchsten Stelle (Level) im Team. Das ist für mich eine Implikation, also kommt sie in einen eigenen Customizer: PHP-Code: <?php $roleList = $organigram->getRoleList(); // alle Rollen, Typ: ArrayObject $roleUserLists = $organigram->getRoleUserLists(); // alle Zuordnungen Rollen zu Mitarbeitern -> verschachtelter Array foreach ($organigram->getTeamList() as $team) { // für jedes Team wird eine eigene Rolle angelegt und dem entsprechenden Mitarbeiter zugewiesen $role = new Organigram_Role(); $role->setId("teamleader-" . $team->getId()); $role->setName("Team Leader " . $team->getName()); $roleList[$role->getId()] = $role; // dank ArrayAccess $userList = $organigram->getTeamUserList($team); $userList->sortLevel()->rewind(); // nach Level sortieren und Arraypointer zurücksetzen $boss = $userList->current(); // nur Bsp. Code, könnte ja auch leere Teams geben $userRoleLists[$role->getId()][$boss->getId()] = array(); // leerer array() deshalb, weil nichts von der Rolle überschrieben werden soll, // beim Beispiel oben ("Chef Nummer 1") müsste ich array("template" => "Chef Nummer 1") schreiben // später Auslesen per Fliegengewichtspattern, werden sonst zuviele Objekte } ?> Wo ich diesen Code ausführe ist egal, vermutlich in Organigram_Customizer_TeamLeader.php, so dass ich mehrere Customizer über die Daten rennen lassen kann. Wenn die Daten nun korrekt sind, kann ich sie an den Renderer übergeben. Derzeit gibts nur XHTML, aber XML oder eine sonstige Form ist denkbar. PHP-Code: <div> <?php echo $this->_renderRole("CEO"); // holt sich alle Mitarbeiter mit der Rolle "CEO" und rendert sie anhand <template> ?> <?php echo $this->_renderRole("CFO"); ?> </div> <div> <?php $teamList = $this->_organigram->getTeamList()->filterType(array("Abteilungen", "Sonderabteilungen")); // jedes Team hat einen "type", oben nicht vermerkt foreach ($teamList as $team) { echo $this->_renderTeam($team); echo $this->_renderRole("teamleader-" . $team->getId()); } ?> So sieht das Generieren dann in etwa aus: PHP-Code: `<?php $source = Organigram_Source_Xml_Abstract::factory(); // Dummy-XML mit DOM/XPath auslesen $source->loadFile("./organigram-dummy.xml"); $organigram = new Organigram(); $organigram->load($source); $customizer = new Organigram_Customizer_TeamLeader(); $customizer->customize($organigram); $renderer = new Organigram_Renderer_Xhtml(); $renderer->setOrganigram($organigram); echo $renderer->render("./templates/xhtml/organigram/layout.php"); ?>` Jetzt sollte eigentlich alles bisherige damit möglich sein. Wenn ich das Laden der Customizer noch über eine Konfig löse, sogar ohne Codeänderung am eigentlichen Generator-Skript. __________________ "Nuschel ich?" - "Was?"

26.06.2011, 14:23
tr0y Erfahrener Benutzer Registriert seit: 26.07.2010 Beiträge: 4.874 PHP-Kenntnisse: Fortgeschritten	Okay, ist ja prinzipiell "das selbe in Grün", wobei ihr das Rendering nicht in Klasse vornimmt und die Klasse selbst auch nicht die XML zusammenbaut um sie zu modifizieren. Schlussendlich kann man bei meinem "Design" allerdings darauf verzichten etwaigen PHP-Code zusammenzuschrauben um entsprechende Costumizer zu erzeugen, das sind dann die einzelnen XSL-Templates. anyway, danke für die Info, wir laufen beide in die selbe Richtung ^^ __________________ Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

26.06.2011, 14:33
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.269	Ja, ist grundsätzlich das gleiche, ich denke eine andere sinnvolle Lösung gibt es auch nicht, als eine Schicht einzuklemmen, die die Manipulation erlaubt. Nutzt du denn viel XSLT? Wir haben das bei uns im alten Intranet (XP-Framework), ganz schrecklich und ich befürchte, dass man dafür wiederum eine Extension braucht, die das umwandelt, denn clientseitig möchte ich das nicht lösen. __________________ "Nuschel ich?" - "Was?"

26.06.2011, 14:51
tr0y Erfahrener Benutzer Registriert seit: 26.07.2010 Beiträge: 4.874 PHP-Kenntnisse: Fortgeschritten	Nunja, ich nutze XSLT wo es sinnvoll ist. Wenn ich größere oder unbestimmt große XML-Bäume neu arangieren muss greif ich eher auf XSLT zurück als es per SimpleXML oder anderen nativen PHP-Modulen zu lösen. Angewendet werden die XSL-Templates serverseitig per DOMDocument + XSLTProcessor ( http://de.php.net/manual/de/class.xsltprocessor.php ). XSLT ist bei der Manipulation am flexibelsten ( meiner Meinung nach ) und ich benötige bspw. in deinem Fall zum entwickeln der Costumizer keine Entwicklungsumgebung auf der die Software läuft ( für Tests ), sondern lediglich einen aktuellen Browser und die Ursprungs-XML. Allerdings stimme ich dir in Sachen Source-Volumina der einzelnen Templates zu, einige "Geschichten" eskalieren in deutlich mehr Quellcode als es sein Equivalent in PHP benötigen würde, was mir wiederum die Entscheidung vorhält wann für ein Projekt XSLT sinnvoll wäre und wann nicht. __________________ Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

27.06.2011, 23:54
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.269	LOL, schlag das nicht unserer HR vor. Ne musste es unkenntlich machen. Ist doch gelungen oder? __________________ "Nuschel ich?" - "Was?"

29.06.2011, 19:49
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.269	Wenn ich fertig bin werde ich mal meine komplette Umsetzung posten. Ich stuetz mich jetzt ganz auf Rollen. Im Prinzip ist das gesamte Organigramm ein Rollenbaum, dessen Blaetter User oder Teams sind. Das Aussehen jeder Kombination User/Rolle und Team/Rolle kann angepasst werden. z.B. Rolle Organigramm besteht aus: Rolle Vorstand Rolle TeamUebersicht Rolle Vorstand besteht aus: Rolle CEO Rolle CFO Rolle CEO besteht aus: User 1 Rolle CFO besteht aus: User 2 .. Ich kann jetzt festlegen, wie ein Vorstand-User gerendert wird, aber auch noch einmal speziell, wie ein CEO-User gerendert wird. Dabei leg ich nur Texttemplates fest. Als HTML kommt dann ein div/ul/li Konstrukt raus Code: <ul class="role-Vorstand"> <li class="role-type-Role"> <ul class="role-CEO"> <li class="role-type-User"> <div class="user user-1"> CEO <div class="template template-name">User 1</div> </div> </li> </ul> </li> <li class="role-type-Role"> <ul class="role-CFO">..</ul> </li> .. </ul> Bei Listen, z.B. Teammitgliedern kann eine Rolle noch einer Rollenfamilie angehoeren (role-family-TeamMember), dass sich dann im Rendering fuer XHTML als weitere CSS-Klasse wiederfindet. Damit kann ich im CSS alles ansprechen was ich will. Einziges Problem bei den Listen ist, dass komma-separierte Listen nicht funktionieren. Evtl. fuege ich dann bei allen Elementen noch ein "glue" (wie bei implode) ein, dass pro Rolle definiert werden kann. Der Rollenbaum ergibt sich dann durch eine einfache Eltern-Kind-Beziehung in der Datenbank User 1 hat Rolle CEO User 1 hat Rolle TeamLeader-123 User 2 hat Rolle CFO .. Ich hoffe dass ich damit dann wirklich die Probleme groesstenteils loese. __________________ "Nuschel ich?" - "Was?"