Thanks all. I got it to work, but yes, I'm going to rethink the design
anyway.
For those who are interested in how it can be done:
Asset::Container::KDU1 Response1 Response::Summary1
Del-> Asset::Container::KDU2 (6) Response2 (5) Response::Summary2 (4)
Asset::Container::KDU3 (3) Response3 (2) Response::Summary3 (1)
Cascading a delete from (1) to (6) with a delete method on (6) works with:
- A 'before delete' in Asset::Container, that iterates through it's
direct children in the lineage.
- A 'before delete' in Asset, that iterates through it's own Responses.
- And finally a 'before delete' in Response that iterates through the
Summaries.
But true, this is too complex. And so would Inner and Augment be. Not
transparent enough.
Thanks for the feedback!
Kind regards,
Arjan.
On 26/04/18 13:52, Thomas Klausner wrote:
Hi!
On Thu, Apr 26, 2018 at 07:45:58AM -0400, Chris Prather wrote:
Thanks for your reply. Discussion on what containers might be, is not what I'm
looking for. The question is about Moose and how it could and could be used.
Formulated less open than before: is there an option for an execution order
that is the inverse of Method modifiers?
Your final advise might be sound though, if the answer is no.
Look at augment/inner but experience says that if you’re reaching for this you
need to rethink your design because you’re over coupling something somewhere.
And while it might be possible to coerce Moose to do what you want
automagically, I think it makes for much better / easier to
understand code if you "just" create some methods that explictly do what
you need. That way your future self can just read what's happening
without having to hunt through several layers of Moose magic...
Greetings,
domm
