Ajoute le positionnement absolu (pos_x/pos_y, réutilise left/top en % déjà en place) et relatif (pos_x_relatif/pos_y_relatif, ajoute un delta à la position actuelle plutôt que de l'écraser) comme nouvelles propriétés de l'action "Modifier un élément". Ajoute une nouvelle source de condition "collision" (aux côtés de "objet"/"variable") : deux éléments (cond_element_a/cond_element_b, ALTER TABLE sans contrainte FK, même patron que block_id/ trigger_custom_event_id) dont on compare les rectangles à l'écran via getBoundingClientRect() côté client (elementsOverlap(), dans conditions.js). Pas d'opérateur/valeur à choisir : le chevauchement EST directement le booléen vrai/faux du nœud — le créateur relie le port "Faux" pour "ne se touchent pas", exactement comme pour n'importe quelle autre condition (design plus simple que réinterpréter égal/différent, qui n'a pas de sens pour superieur/inferieur). delete_element.py et flow_nodes_referencing_element.py nettoient désormais aussi les nœuds de collision référençant un élément supprimé (ou l'un de ses descendants), pour rester cohérents avec le nettoyage déjà en place pour trigger_element_id/target_element_id. Combiné à la Phase 3 (minuteur récurrent) et au déplacement au clavier, ça couvre des jeux type casse-briques/Pong/ramasse-objets sans construire un vrai moteur physique (pas de vélocité/accélération/ gravité continues, cadrage volontairement limité). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
45 lines
2.2 KiB
Python
45 lines
2.2 KiB
Python
import db
|
|
|
|
from ..flow.ensure_flow_schema import ensure_flow_schema
|
|
from .element_descendant_ids import element_descendant_ids
|
|
|
|
|
|
def delete_element(slug, element_id):
|
|
ensure_flow_schema(slug)
|
|
conn = db.connect(slug)
|
|
row = conn.execute("SELECT screen_id FROM _screen_elements WHERE id = ?", (element_id,)).fetchone()
|
|
if not row:
|
|
conn.close()
|
|
return
|
|
ids = element_descendant_ids(conn, row["screen_id"], element_id)
|
|
placeholders = ",".join("?" * len(ids))
|
|
# Un nœud de la Logique de la scène (déclencheur "clic sur cet
|
|
# élément"/action "Modifier cet élément"/condition de collision — voir
|
|
# ci-dessous...) ou une ancienne action du système _actions (conservé
|
|
# pour compatibilité) qui référence l'élément supprimé OU L'UN DE SES
|
|
# DESCENDANTS n'a plus aucun sens une fois l'élément disparu — et ces
|
|
# colonnes (trigger_element_id/target_element_id) n'ont volontairement
|
|
# PAS de ON DELETE CASCADE (un élément ne doit pas pouvoir être
|
|
# supprimé "par erreur" en cascade depuis un nœud de logique qu'on
|
|
# modifie). Sans ce nettoyage préalable, PRAGMA foreign_keys=ON (voir
|
|
# db/connection.py) fait échouer la suppression elle-même avec
|
|
# "FOREIGN KEY constraint failed". Voir element_delete_impact.py pour
|
|
# prévenir l'utilisateur AVANT qu'il confirme, plutôt que de supprimer
|
|
# ces nœuds en silence.
|
|
#
|
|
# cond_element_a/cond_element_b (Phase 5, condition de collision) : ni
|
|
# contrainte FK ni ON DELETE CASCADE (voir ensure_flow_schema.py), mais
|
|
# un nœud qui compare le rectangle de CET élément à un autre n'a pas
|
|
# plus de sens que si c'était trigger_element_id/target_element_id —
|
|
# supprimé ici pour la même raison, pas parce que la base l'exigerait.
|
|
conn.execute(
|
|
f"""DELETE FROM _flow_nodes WHERE trigger_element_id IN ({placeholders})
|
|
OR target_element_id IN ({placeholders})
|
|
OR cond_element_a IN ({placeholders}) OR cond_element_b IN ({placeholders})""",
|
|
ids + ids + ids + ids,
|
|
)
|
|
conn.execute(f"DELETE FROM _actions WHERE target_element_id IN ({placeholders})", ids)
|
|
conn.execute("DELETE FROM _screen_elements WHERE id = ?", (element_id,))
|
|
conn.commit()
|
|
conn.close()
|