Aller au contenu principal

In Regeln auf Projekt-ID oder Projektname prüfen

Commentaires

2 commentaires

  • Michael Bergmann

    Hi Fabian,

    in den Regeln selbst gibt es keine passende <PROPERTY> für den Projektnamen oder die ID. Wichtig: das #global in den Regeln hat ja nichts mit dem #global z.B: im Ausgabekanal zu tun, insbesondere ist es ja kein "Objekt".

    Aber deine Anforderung sollte über einen "ValueService" lösbar sein. Den kann man entweder im Rahmen eines Moduls implementieren oder seit einiger Zeit auch über ein Script (das dann über den inzwischen mitgelieferten ScriptValueService" genutzt wird). 

    Entsprechende Doku-Seiten hierzu:

    • Allgemeiner Mechanismus (SCHEDULE)
    • Konkrete Infos auf der Unterseite (dort die Teile zum "ScriptValueService)

    Hier gab es mal eine "ähnliche" Frage in einem anderen Zusammenhang - da ging es um Absatz-Namen. Wobei ich denke dass dein Fall eher noch einfacher wäre.

    Wobei es dann für deinen Fall im Detail natürlich diverse Varianten gäbe, an welcher Stelle man dann "tatsächlich" die Info hinterlegen wollen würde (worauf dieses Script oder auch der "echte" ValueService dann zugreift):

    • Direkte Angabe als Parameter (z.B. kommagetrennte Liste von Projekten) in der jeweiligen Regel - also als Parameter wie "visibleForProjects". Ließe sich dann natürlich extrem feingranular kontrollieren, aber potenziell entsprechender Aufwand (insb. bei Änderungen). Und ich bin persönlich kein Fan davon, Dinge an Projektnamen oder Projekt-IDs zu hängen.
    • Wenn es bei euch eher nur sagen wir mal 2-3 "Typen" von Projekten gibt, wo sich das "pro Typ" immer "gleich verhält", fände ich eine Art "Einstellung" in den Projekteinstellungen sinnvoller (auf die das Script / ValueService dann zugreift). Also z.B. diesen "Projekttyp". Dann würde man in der Regel (=im Parameter) nur sagen für welche dieser "Typen" ein Feld sichtbar sein soll.
    • ... oder irgendwie anders :-) 

    Welche Variante davon für euch sinnvoll ist, "kommt drauf an"...

    Zum Thema ScriptValueService vs. "richtiger" ValueService (damit meine ich die Implementierung eines ValueService als PUBLIC-Komponente im Rahmen eines eigenen Moduls): Generell würde ich sagen: Je "komplexer" das wird, desto eher die Tendenz, das nicht über den ScriptValueService (und damit über ein Beanshell-Script) zu machen, sondern über einen eigenen "richtigen" ValueService.

    Viele Grüße
    Michael

    1
  • Fabian König

    Hi Michael,

    vielen Dank für deine ausführlichen Erklärungen.

    Ich habe die Anforderung jetzt tatsächlich mit einem ScriptValueService umgesetzt.

    Für alle, die etwas ähnliches umsetzen wollen, teile ich hier mal meine Lösung:

    In den Regeln der Vorlage:

    <RULE>
     <SCHEDULE delay="0" id="E" service="ScriptValueService">
     <PARAM name="script">
     <TEXT>checkproject</TEXT>
     </PARAM>
     <PARAM name="visibleForProject">
    <TEXT>PROJEKTNAME</TEXT>
     </PARAM>
     </SCHEDULE>
     <DO>
     <PROPERTY name="VISIBLE" source="st_test1"/>
     </DO>
    </RULE>

    Und das Skript checkproject

    import de.espirit.firstspirit.agency.ProjectAgent;
    projectAgent  = context.requestSpecialist(ProjectAgent.TYPE);
    return projectAgent.getName().equals(visibleForProject);

    Viele Grüße
    Fabian

    1

Vous devez vous connecter pour laisser un commentaire.