[MAGNOLIA-5935] Extra Ops for NodeBuilder Created: 29/Sep/14  Updated: 08/Oct/14  Resolved: 02/Oct/14

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 5.3.4

Type: Improvement Priority: Neutral
Reporter: Jan Haderka Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: quickwin
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File Ops$1.class     File Ops$10.class     File Ops$11.class     File Ops$12.class     File Ops$13.class     File Ops$14.class     File Ops$2.class     File Ops$3.class     File Ops$4.class     File Ops$5.class     File Ops$6.class     File Ops$7.class     File Ops$8.class     File Ops$9.class     File Ops$AbstractOp.class     File Ops.class     Text File ops.patch    
Issue Links:
dependency
is depended upon by MGNLGROOVY-122 Sample script to register app dynamic... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

When using NodeBuilder to create more complex structures some extra ops come handy

  • getOrAddNode(String boolean) - optionally creates new node(s) if they do not exist. Helps to create more flexible script in uncertain parent structure.
  • IfTrue(boolean flag) - executes operations specified in .then(...) only if provided parameter is true. Helps to add "optional" subtasks based on externally defined flags.
  • conditional(Predicate predicate, Op true, Op false) - ops delivering "parent" to nodes in .then(...) only when predicate evaluates current node as true or false.
  • onEachChild(Predicate predicate) - ops in .then(...) will be executed on each child that is evaluated true by the predicate. Allows to build subtasks that need to be executed on uncertain number of subnodes of current node.


 Comments   
Comment by Magnolia International [ 29/Sep/14 ]

conditional and ifTrue are redundant, and both break the indentation. conditional without the false Op might be the only that doesn't break it.

All first 3 imo create opportunity to have more fragile code; we made the same mistake with tasks, and I'd like to avoid repeating that.

onChildNodes existed in info.magnolia.nodebuilder.Ops, no idea why it's been removed.

It's always been the intention (again, just like with Tasks) that one provides their own Ops. So perhaps instead of generic "getOrAdd", "ifs" and "conditionals" that end cluttering the readability one's node builder code, you can come with local, more specific ops ("addOptionalFolderSupport"). It's not forbidden to generate ops instances and add those to collections, etc. (e.g. don't try to shoe-horn everything into ops, but build collections of ops with regular code)

Comment by Jan Haderka [ 29/Sep/14 ]

conditional and ifTrue are redundant, and both break the indentation. conditional without the false Op might be the only that doesn't break it.

Yes they are redundant. In the linked issue - MGNLGROOVY-122 - I ended up using ifTrue only. The reason it was more convenient was that I could use all the ops specified in the .then(...) and it was not breaking indentation. Either it executes (if condition is true) or it acts as noop if condition is false. Breaking up single op in multiple ones and executing them separately just to be able to insert if() statement in the middle breaks indentation much more and breaks also atomicity of execution of whole chain of operations.

It's not forbidden to generate ops instances and add those to collections, etc. (e.g. don't try to shoe-horn everything into ops, but build collections of ops with regular code)

True again, but again that doesn't help readability of the code. In so many cases you don't know if certain path exists or not and all you need is to add something to that path. I found it much easier to read longer operation chain with getOrAdd rather then having explicitly code checks for existence outside and then inserting different ops based on those external checks. The power of the API is in fact that you can write and read code just like long sentence of semi-broken-english w/o having to jump away to check some conditions.

Generated at Mon Feb 12 04:09:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.