Re: Proposed: #indent directive

Bear Giles <[email protected]>
Newsgroups gmane.comp.jakarta.velocity.devel
Message-ID <CALBNtw6XgKsko=nX7HPuipKQfwTUb_Xzm4cJ2=buS8-7zjsgHA@mail.gmail.com>
It's easiest to show examples

The not-yet-PR for the maven-dependency-plugin uses these templates:

https://github.com/coyotesong/maven-dependency-plugin/tree/convert-tree-dot-to-velocity/src/main/resources/templates

and more importantly the format-specific content in the 'macros' directory.

It uses the two new Directives I'm proposing. (The other proposal still
needs a lot of work.)

- indent:
https://github.com/coyotesong/maven-dependency-plugin/blob/convert-tree-dot-to-velocity/src/main/java/org/apache/maven/plugins/dependency/utils/velocity/runtime/directive/Indent.java

- collapse:
https://github.com/coyotesong/maven-dependency-plugin/blob/convert-tree-dot-to-velocity/src/main/java/org/apache/maven/plugins/dependency/utils/velocity/runtime/directive/Collapse.java

REAL WORLD EXAMPLES (maven-dependency-plugin PR):

YAML

#macro (showChildDependencies $parent)
#for ($child in $parent.children index $idx)
  #indent
    #showNestingDependencies($child, $idx, $parent.children.size)
  #end
#end
#end

#macro (showNestingDependencies $dependency)
#set ($artifact = $dependency.artifact)
#indent
- groupId: $artifact.groupId
  artifactId: $artifact.artifactId
  version: $artifact.version
  type: $artifact.type
#if ($dependency.hasScope)
  scope: $artifact.scope
#end
#if ($artifact.hasClassifier)
  classifier: $artifact.classifier
#end
  optional: $dependency.optional
#if ($dependency.hasChildren)
  children:
  #showChildDependencies($dependency)
#end
#end
#end


The double indentation isn't required - it's proper YAML if either one is
dropped, but I feel the double indentation is
a little easier to read. Since that's the primary reason I use YAML (vs.
JSON, etc.) that's a big win.

JSON is similar but a bit more gnarly since it requires '[', ']', and
commas on everything but the final item and that
means a lot of extra *#if* directives.


GRAPHML

#**
 * This is expanded for clarity
 *#
#macro (showSimpleDependency $dependency)
#collapse
    <node id="$dependency.id">
      <data key="d0">
        <y:ShapeNode>
          <y:NodeLabel>$dependency.nodeString</y:NodeLabel>
        </y:ShapeNode>
      </data>
    </node>
#end
#end

#**
 * This is expanded for clarity
 *#
#macro (showSimpleEdge $parent $child)
#collapse
    <edge source="$parent.id" target="$child.id">
      <data key="d1">
        <y:PolyLineEdge>
          <y:EdgeLabel>$child.artifact.scope</y:EdgeLabel>
        </y:PolyLineEdge>
      </data>
    </edge>
#end
#end

In this case the format don't *require* what *#collapse* does, but it makes
it much easier for the developer
since they can use the open format shown above yet have it collapsed to a
single line in the final document.
This can substantially reduce the size of the document.

The user can still use the single-line version if they want... but I
suspect most people would prefer the
latter since it makes it easy to have one variable (mostly) per line.

I will probably combine these examples with a POC. JSON doesn't care about
whitespace and it's not
common to have everything but any children on a single line. Proper
indentation is still useful since
it gives the user information about the level of nesting. It will require
tweaking the current *#if directives*
*used to handle the lack of a final comma and the addition of the [ ]
delimiters for the children.*



Bear

On Mon, Apr 7, 2025 at 1:28 AM Claude Brisson <[email protected]>
wrote:

> The use case you give is also not clear to me.
>
> What does `writeNodeAsJson()` do on arrays or maps if you still have to
> call `walktree()` on children? Where is the final ']' or '}' written?
>
> Usually, I do solve such problems of displaying a tree using an extra
> `$indentation` argument which is just passed to the recursive macro with
> additional spaces and it's sufficient (and frankly, this is most easily
> done in Java rather in VTL where it's not exactly pertinent...).
>
>
> On 07/04/2025 00:58, Nathan Bubna wrote:
> > A PR to look over would be good.
> >
> > On Sun, Apr 6, 2025 at 9:41 AM Bear Giles <[email protected]> wrote:
> >
> >> I've been working on a contribution to maven-dependency-plugin and
> spent a
> >> fair amount of time trying to figure out how to cleanly implement proper
> >> indentation when converting the dependency tree to json, yaml, etc.
> >>
> >> After a bit of pain, okay a lot of pain, I have finally implemented a
> new
> >> Directive - 'indent' - which extends Block and prepends a 'padding'
> value
> >> on render(). This works since render() is also called recursively.
> >>
> >> (I know there's a TreeContext but I have no idea how to use it, whether
> it
> >> can be used within the existing plugin, or even if it would help solve
> this
> >> problem.)
> >>
> >> An example of how it is used is:
> >>
> >> #macro (writeNodeAsJson $node)
> >> // do the json magic
> >> #end
> >>
> >> #macro (walktree $node)
> >> #indent
> >>     #writeNodeAsJson($node)
> >>     #foreach ($child in $node.children)
> >>        #walktree ($node)
> >>     #end
> >> #end
> >> #end
> >>
> >> (I don't have that code on this system so there may be a slight error in
> >> it.)
> >>
> >> At the moment the directive doesn't take any parameter but I do plan to
> add
> >> an optional one, ideally either a string literal or a reference, but I
> >> haven't coded it yet. In theory it could even be a reference to a
> different
> >> macro, e.g., so you could have 'I", "II",... then 'a','b'..., then
> >> '1','2'... since the macro could be provided the current indentation
> depth
> >> but I'll leave that for another day.
> >>
> >> I think I have JIRA access and if so I'll create an issue and submit a
> PR.
> >>
> >> Bear Giles
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.