Future Repository Layout

[uxkjaer]

I was hoping I could create a pull request to include the onelogin middleware, however the current app doesn't use any odata services that require authentication. I was planning on creating a dummy user for the es5 system and have that in a .env file to show the setup, then maybe implement a new app with a test that logs in. I don't think it's a good idea to declare a new model in the ui5-app package.

What do you think?

[petermuessig]

Hi @uxkjaer ,

I was first thinking about restructuring the mono-repo in a way that we have multiple app projects, per scenario. But maybe, for now, we stick to this one application and add additional views per middleware/task to it. We can also add an additional view or even a reuse component which uses such a datasource and when navigating to it, the data is loaded. Regarding credentials: maybe it is more to explain how you can get a dummy user to authenticate agains the ES5 system and explain how to put it into the .env file? What do you think?

Best regards,
Peter

[vobu]

i'm also pro bolting in the additional auth scenario into the existing app 👍

[uxkjaer]

Happy to do that.
How about maybe having an example folder in each middleware or a seperate samples folder similar to the official sap samples?

[petermuessig]

One thing I also had in mind is that every middleware and task has it's own test which is called by lerna in each project. Something to rework in general. This would allow to separate the projects also if needed.

What is the granularity you would expect per sample? An application? What I currently do not like so much in the application project is, that we have so many ui5.yaml variants which requires to start the application or run the build with different commands. But I also understand that for some tasks (like pwa) it would be also nasty to create an own example.

What would you suggest?

To have one central application showing everything which could be combined in one place and for each middleware/task a test/ui5-app folder which includes an application to use for testing purposes?

[uxkjaer]

Well I use the showcase to get inspired and see what other middleware are out there and examples on how to use them. In particular the stringreplacer and flatten library was found and used because of the showcase. I think it would be great to just have a place to go to and find all possible middlewares out there with one or more examples on how to use them. I don't think we need a single app to show it all. It gets too big and complex.

[uxkjaer]

Well I use the showcase to get inspired and see what other middleware are out there and examples on how to use them. In particular the stringreplacer and flatten library was found and used because of the showcase. I think it would be great to just have a place to go to and find all possible middlewares out there with one or more examples on how to use them. I don't think we need a single app to show it all. It gets too big and complex.

[petermuessig]

So, best would be to put the things we can together into the ui5-app and everything else goes into a special test folder of the individual tasks and middlewares? Or better a samples folder? If we add them we need to take care to ignore them in the .npmignore for each task/middleware.

[uxkjaer]

That to me sounds like a great idea. But I would be keen for more people to voice their opinion. Should we change the ticket name to future structure of the showcase or something similar?

[petermuessig]

Yes, why not, e.g.: "Future Repository Layout". I can also add my suggestion a bit later today.

[petermuessig]

Possible Repository Layout:

packages
\_ ui5-app
    \_ webapp
    \_ ui5.yaml
\_ ui5-middleware-xxx
    \_ samples
        \_ ui5-app
            \_ webapp
            \_ ui5.yaml
    \_ src
    \_ test
    \_ ui5.yaml
\_ ui5-task-yyy
    \_ samples
        \_ ui5-app
            \_ webapp
            \_ ui5.yaml
    \_ src
    \_ test
    \_ ui5.yaml
\_ ui5-tooling-zzz
    \_ samples
        \_ ui5-app
            \_ webapp
            \_ ui5.yaml
    \_ src
    \_ test
    \_ ui5.yaml

Every middleware, task or tooling extension project can also have multiple samples if needed. Also every project should have its own tests and individually testable.

My first drop of my thoughts...

[uxkjaer]

Looks good. What's the purpose of the ui5-app if you have one or more samples for each middleware. Do the middleware have their own repos to raise issues and be maintained independently? I can't find anything on the existing ones. But if I integrate the ones I've created I think it would be better to add them as a sub module and then have a separate repo for maintenance.

[vobu]

hmmm - having 1..n ui5 apps for each task, middleware and/or module will most likely blow up the repo...plus foster a very...heterogeneous...variety of sample apps, probably not all tending towards best practices 😬
is there a way other than git submodules for a monorepo to clone the same ui5 app per task, middleware and module? so that it can be updated centrally w/o further ado? that way we could have the best of both worlds: 1 sample app w/ best practices, n clones per task/middleware/module.

[uxkjaer]

As part of our ci at a client we are updating source code on occasions. I've used it to migrate yaml and also package.json files. If we reference the ui5-app and have a local yaml file for each to showcase the middleware then the source code will always be the best practice ui5-app. For my own middlewares I could use this setup for the onogin, data-test-tag and code coverage. I have one for handling the component preload file for custom tile as well, that would need a whole other app.

[uxkjaer]

hmmm - having 1..n ui5 apps for each task, middleware and/or module will most likely blow up the repo...plus foster a very...heterogeneous...variety of sample apps, probably not all tending towards best practices grimacing is there a way other than git submodules for a monorepo to clone the same ui5 app per task, middleware and module? so that it can be updated centrally w/o further ado? that way we could have the best of both worlds: 1 sample app w/ best practices, n clones per task/middleware/module.

we could in the sample folder of each middleware just have a package.json and a ui5.yaml file. The yaml file would contain a resource mapping similar to this
resources: configuration: paths: webapp: ../com.myorg.myapp/webapp
then when we serve, it's from the central app component and it's just the middlewares that are different depending on the package.json and ui5.yaml from the sample folder.

[vobu]

hmmm - having 1..n ui5 apps for each task, middleware and/or module will most likely blow up the repo...plus foster a very...heterogeneous...variety of sample apps, probably not all tending towards best practices grimacing is there a way other than git submodules for a monorepo to clone the same ui5 app per task, middleware and module? so that it can be updated centrally w/o further ado? that way we could have the best of both worlds: 1 sample app w/ best practices, n clones per task/middleware/module.

we could in the sample folder of each middleware just have a package.json and a ui5.yaml file. The yaml file would contain a resource mapping similar to this resources: configuration: paths: webapp: ../com.myorg.myapp/webapp then when we serve, it's from the central app component and it's just the middlewares that are different depending on the package.json and ui5.yaml from the sample folder.

me likez - that way, we don't clutter the proj w/ multiple ui5 apps, but re-use the default one 👍
@petermuessig - you call the shot(s).

[petermuessig]

Sorry for being late to the party again...

I had the same idea. The only reason why I was a bit conservative yet is, whether there also needs to be some adoptions of the UI parts to showcase the middleware/task related features. Otherwise this would mean that some parts of the app might be just useful for one or the other use-case. What would we do with this stuff then?

Regarding the git submodules, I had not so good experiences with this in the past. I would in this case prefer that we maybe more add the external custom tasks or middlewares to the sample application and add them in the listed tasks and middlewares. I would also prefer to have more dynamic solution for the GH page which lists tasks and middlewares more generically and not hard-coded. But this is another story.

[uxkjaer]

Sounds good. I was thinking on my case where I would need an odata model to create a seperate view in the ui5-app and create the ui5 model in the init method. I know it's not best practice, but it was to avoid adding it to the manifest where no matter the middleware it would request the metadata.
What do you think?

[petermuessig]

I converted this issue into a discussion as I recently introduced a new project structure having packages and showcases. WDYT about this?

[petermuessig]

The current structure looks quite good to me, closing the discussion