Cadres de travail pour Django

y a-t-il d'autres options qui valent la peine d'être considérées et qui pourraient être mieux ou mieux soutenues?

Oui.

Python.

vous n'avez pas besoin d'un produit de flux de travail pour automatiser les transitions d'état, permissioning, et peut-être quelques extras comme la journalisation d'audit et les notifications.

il y a une raison pour laquelle il n'y a pas beaucoup de projets qui font cela.

• le État modèle de conception est assez facile à mettre en œuvre.

• les règles D'autorisation ("permissioning") sont déjà une première classe une partie de Django.

• la journalisation est déjà une partie de première classe de Python (et a été ajouté à Django). Utiliser ceci pour l'enregistrement de l'audit est soit un audit table ou un autre logger (ou les deux).

• le message framework ("notifications") fait déjà partie de Django.

que vous faut-il de plus? Vous l'avez déjà tous.

utilisant les définitions de classe pour le État motif de conception, et les décorateurs pour l'autorisation et la journalisation fonctionne si bien que vous n'avez pas besoin de quoi que ce soit au-delà de ce que vous avez déjà.

lisez cette question connexe: implémenter un "moteur de règles" en Python

un paquet écrit par un de mes associés, django-fsm , semble fonctionner--il est à la fois assez léger et suffisamment caractéristique pour être utile.

c'est drôle parce que j'aurais été d'accord avec S. Lott sur L'utilisation de Python comme moteur de règles. J'ai une perspective complètement différente maintenant que je l'ai fait.

si vous voulez un moteur complet, il a besoin de plusieurs pièces mobiles. Nous avons construit un moteur de règles Python/Django complet et vous seriez surpris de ce qui doit être construit pour obtenir un grand moteur de règles en marche. Je vais expliquer plus loin, mais d'abord le site web est http://nebrios.com .

d'Un moteur de règles devrait au moins avoir:

• "Acess Control Lists - voulez-vous que tout le monde voit tout?
• key/Value pair API - KVP stocke l'état, et toutes les règles réagissent aux états modifiés.
• Debug mode - être capable de voir chaque état modifié, ce qui l'a changé et pourquoi. Primordial.
• Interaction par formulaires web et e-mail - être en mesure de script rapidement un formulaire web est un énorme plus, avec l'analyse des e-mails entrants systématiquement.
• Process ID's - ceux-ci tracent un" fil " de la valeur d'entreprise. Autrement, les processus se chevaucheraient continuellement.
• Sooo beaucoup plus!

donc essayer Nebri, ou les autres je liste ci-dessous pour voir si elles répondent à vos besoins.

voici le mode de débogage

un formulaire généré automatiquement

Un exemple de règle de workflow:

class task_sender(NebriOS):
# send a task to the person it got assigned to
listens_to = ['created_date']

def check(self):
    return (self.created_date is not None) and (self.creator_status != "complete") and (self.assigned is not None)

def action(self):
    send_email (self.assigned,"""
        The ""{{task_title}}"" task was just sent your way!

        Once you finish, send this email back to log the following in the system:

        i_am_finished := true

        It will get assigned back to the task creator to look over.

        Thank you!! - The Nebbs
        """, subject="""{{task_title}}""")

donc, non, il n'est pas simple de construire un moteur de flux de travail basé sur des règles et des événements en Python seulement. Nous avons été à elle pendant une année! Je vous conseille d'utiliser des outils comme

• http://nebrios.com
• http://pyke.sourceforge.net (C'est aussi Python!)
• http://decisions.com
• http://clipsrules.sourceforge.net

je peux ajouter une bibliothèque de plus qui prend en charge à la volée les changements sur les composants de flux de travail contrairement à ses équivalents.

Regardez django-rivière

ActivFlow : un moteur Générique, léger et extensible de flux de travail pour le développement agile et l'automatisation des opérations complexes de processus D'Affaires.

vous pouvez avoir un workflow entier modélisé en un rien de temps!

Étape 1: Enregistrement De L'Application De Flux De Travail

WORKFLOW_APPS = ['leave_request']

Étape 2: Configuration De L'Activité

from activflow.core.models import AbstractActivity, AbstractInitialActivity
from activflow.leave_request.validators import validate_initial_cap

class RequestInitiation(AbstractInitialActivity):
    """Leave request details"""
    employee_name = CharField(
        "Employee", max_length=200, validators=[validate_initial_cap])
    from = DateField("From Date")
    to = DateField("To Date")
    reason = TextField("Purpose of Leave", blank=True)

    def clean(self):
        """Custom validation logic should go here"""
        pass

class ManagementApproval(AbstractActivity):
    """Management approval"""
    approval_status = CharField(verbose_name="Status", max_length=3, choices=(
        ('APP', 'Approved'), ('REJ', 'Rejected')))
    remarks = TextField("Remarks")

    def clean(self):
        """Custom validation logic should go here"""
        pass

Étape 3: Définition Du Flux

FLOW = {
'initiate_request': {
    'name': 'Leave Request Initiation',
    'model': RequestInitiation,
    'role': 'Submitter',
    'transitions': {
        'management_approval': validate_request,
    }
},
'management_approval': {
    'name': 'Management Approval',
    'model': ManagementApproval,
    'role': 'Approver',
    'transitions': None
    }
}

Étape 4: Règles D'Affaires

def validate_request(self):
    return self.reason == 'Emergency'

je migrer django-goflow de django 1.X-python 2.X pour s'adapter à django 2.X-python 3.x, le projet est à django2-goflow