Enabling new screens in a component

[Vasanth Kamatgi]

Screen xmls are "typically" defined inside component/mycomponent/screen
folder. In cases where the component has deeply nested url scheme, for e.g.,

/module1/functionA
/module2/submodule1/functionB
e.t.c.

we need to create a similar folder structure in
component/mycomponent/screen. However, just creating the folder structure is
not sufficient. We also need to create a screen xml with the same name as the
folder for moqui to start serving the screens inside this folder.

To me, this - in a way, reduces the elegance of "driven by convention as
opposed to configuration" motto of moqui. I would expect the behaviour to be:

module1.xml should not be needed for the /module1/functionA to be served
by moqui.

Only if the folder has to be given properties (name, auth, authz etc.)
different from parent folder, should module1.xml definition be necessitated.
Otherwise, folder should inherit properties from its parents. This will reduce
developer's work a little while making it more maintainable.

I havent really pondered a lot on any potential issues arising out of
"automatic", folder exposure. But my sense, says there may not be any major
issues.

If there are already reasons for this design decision, I would love to hear
them.

-Thanks

[David E. Jones]

Is the goal to add path elements that are used only to put something in the
URL?

Typically a screen/subscreen is used to organize an application and decorate
the screens underneath, specify a default subscreen if the URL path ends on a
non-leaf screen, and so on.

What is the scenario where you would not want those things? Also, how would
you choose the default subscreen if none is specified in the URL path?

BTW, for content under a screen you can have an arbitrary path without needing
screens at each level, but it is assumed that there is no decoration or
defaults in between the last screen definition and the actual content
location.