saschakiefer / generator-openui5

yeoman generator for OpenUI5 applications and assets
Other
64 stars 17 forks source link

Sub Generators do not respect a given namespace of the application #47

Closed saschakiefer closed 10 years ago

saschakiefer commented 10 years ago

The Fiori templates have a namespace, which is not recognized an appreciated by the sub generators.

Note: Add Namespace to the Classical Application Template as well.

js1972 commented 10 years ago

This one deserves a high priority. However we're gonna do that.  ;-)Maybe add it to the next milestone and put a date on that milestone....

On Fri, Feb 7, 2014 at 8:50 PM, saschakiefer notifications@github.com wrote:

The Fiori templates have a namespace, which is not recognized an appreciated by the sub generators.

Note: Add Namespace to the Classical Application Template as well.

Reply to this email directly or view it on GitHub: https://github.com/saschakiefer/generator-openui5/issues/47

js1972 commented 10 years ago

Re: Component sub-generators:

Note: If you enter the namespace as part of the component name it generates just fine. i.e. instead of typing "MyComponent", enter "namespace.to.MyComponent". The prompt actually suggests this already: "What is the name of the component you want to generate (e.g. foo.bar.myComponent)".

Is that what you mean?

Or do you mean that if you scaffold a NEW component inside an app which already has a namespace that it should respect that namespace? I'm not 100% convinced thats necessary when its easy just to enter the namespace with the name.

?

saschakiefer commented 10 years ago

I think you can't just solve it by adding the path to the name. I stumbled over it in the following example: I created a Firoi Split App with the namespace sap.ui.demo Then I created a faceless component with the name util.Share. The component name in the coding is set to util.Share which should be sap.ui.demo.util.Share. When I enter sap.ui.demo.util.Share, then the component name in the coding would be correct, but the component would be created in the sub directory ApplicationRoot/sap/ui/demo/util/Share which I don't want.

I also recognized, that this applies to the views.

I plan to provide a global method, which tries to figure out the current namespace of the app and puts it into a global variable, which can be used in the templates.

This is basically the same as #2 where I already had the feeling that we need that and now it comes back...

js1972 commented 10 years ago

That example makes sense... In my testing I created components with the same namespace.

On 20 February 2014 16:59, saschakiefer notifications@github.com wrote:

I think you can't just solve it by adding the path to the name. I stumbled over it in the following example: I created a Firoi Split App with the namespace sap.ui.demo Then I created a faceless component with the name util.Share. The component name in the coding is set to util.Share which should be sap.ui.demo.util.Share. When I enter sap.ui.demo.util.Share, then the component name in the coding would be correct, but the component would be created in the sub directory ApplicationRoot/sap/ui/demo/util/Share which I don't want.

I also recognized, that this applies to the views.

I plan to provide a global method, which tries to figure out the current namespace of the app and puts it into a global variable, which can be used in the templates.

Reply to this email directly or view it on GitHubhttps://github.com/saschakiefer/generator-openui5/issues/47#issuecomment-35600211 .

js1972 commented 10 years ago

Just thinking about this some more... A Component is supposed to be a re-usable chunk of code. Therefore when you create a component you want to give it a good namespace like my.great.NewComponent. Why would you want to add your apps namespace into that like: sap.ui.demo.app.my.great.NewComponent. Its now coupled to your apps namespace.

Another solution taking the above into account would be to simply add a new resource root: my.great in the UI5 bootstrap. This way the app can see the component just like the LocalResources() method in the classical Application.js architecture.

What do you think?

I'll dummy something up in a new branch to test this theory.

js1972 commented 10 years ago

I've just done some testing with a generated fiori tiles app (with namespace sap.ui.demo). I generated a new component called foo.bar.MyComponent. I added it to the detail view of my fiori tiles app. I also added: "foo.bar.MyComponent": "./foo/bar/MyComponent" as a resource root in the UI5 bootstrap so that my app could find the component. Note: I could also have made it easier to reference my component by using this resource root declaration: "MyComponent": "./foo/bar/MyComponent" - then I could reference my component in views using MyComponent instead of foo.bar.MyComponent (whatever you think looks better).

It worked fine. With no need to prefix the component name with the fiori tiles app namespace (sap.ui.demo).

So unless I'm completely missing something (and I'm doing so many things at once here I could well be) this is not a bug but actually a great way of having the generators work...

This issue is also linked to issue #54 - fixing #54 depends on this. Once this is mocked up I'll post a github branch for you to checkout with both the generators and an app that was generated and uses a component from the uiComponent sub:generator.

saschakiefer commented 10 years ago

That's an interesting approach. I started yesterday with a solution, that reads the application namespace and add's it. But you made a very good point towards coupling. That completely removes the possibility of reusing a component in another project without having the complete namespace. On the other hand, if you put in in util/myComponent, you might not want to have util either when reusing.... I also don't like the idea of swamping the bootstrap with tons of component references, that's the nice thing I like about the root, you don't need references to overy sub-namespace. I'll do some tests later as well, do explore this further.

Nevertheless, we have a function now in the base-script to get the namespace of the app (assuming there is only one I the bootstrap) ;-)

js1972 commented 10 years ago

Just on your point of putting it in util but not wanting util in another project.... You can put it anywhere and use the resourceroots definition to point to it.

js1972 commented 10 years ago

Hmm.... I can't see your function to get the app namespace? IS it not pushed up to "develop" yet?

So by the sounds of it we will leave the namespacing as-is for now and therefore keep any sub-generated components more reusable.

Just on this comment you made: " I also don't like the idea of swamping the bootstrap with tons of component references, that's the nice thing I like about the root, you don't need references to overy sub-namespace."

We still need to add namespaces of each sub-Component to the index.html. Its just done in the resourceroots section of the UI5 bootstrap instead of a LocalResource() call.

i.e. if your bootstrap looks like this:

<script id="sap-ui-bootstrap"
            src="https://openui5.netweaver.ondemand.com/resources/sap-ui-core.js"
            data-sap-ui-theme="sap_bluecrystal"
            data-sap-ui-libs="sap.m, sap.ui.layout"
            data-sap-ui-xx-bindingSyntax="complex"
            data-sap-ui-resourceroots='{
                "sap.ui.demo": "./",
            }'
    </script>

and you added a sub-generated component it would now look like this:

<script id="sap-ui-bootstrap"
            src="https://openui5.netweaver.ondemand.com/resources/sap-ui-core.js"
            data-sap-ui-theme="sap_bluecrystal"
            data-sap-ui-libs="sap.m, sap.ui.layout"
            data-sap-ui-xx-bindingSyntax="complex"
            data-sap-ui-resourceroots='{
                "sap.ui.demo": "./",
                "foo.bar.MyComponent": "./foo/bar/MyComponent"
            }' >
    </script>
js1972 commented 10 years ago

The components definition states that you must have a separate folder for each component - therefore I can't see how you could get around adding a line for each component into the resourceroot... Or LocalResource(), etc. Also - you can get fancy and dynamically write the data-sap-ui-resourceroots section pretty easily so that it doesn't look clogged up with lots of components. I kind of like it though as its a nice reference to every component (or custom module) your app will use.

js1972 commented 10 years ago

ok I have a branch working that will update the resourceroots instead of add LocalResources into the index.html. have a little more work to do to get the index.html formatted right as I have to put a damn comma on the previous line. Once that's done early next week I'll send so you can have a look. I've got components working in xml views as well which is really cool (simple now that I know). ;-)

saschakiefer commented 10 years ago

OK, I'll check it out. From a quick check it looks similar to my implementation. So we have to see how to merge that. I guess we should try to align better in the future, since we basically implemented the same function during the last two days... Should we managed that based on the "Assigned to?". Then it's clear when someone is already working on a task, and we can better align.

js1972 commented 10 years ago

If your implementation does the same then just ignore mine. I won't finish it off and raise a pull request.

My fault. I've ignored any assignees as I assumed you were too busy at the moment. Plus I've been keen on learning more about components so enjoyed playing around with them...

So go with what you think and let me know if and where I can help out?

I learnt quite a few things playing around with XML views and using components.

I only just pushed my "components" Branch up to my repo a couple hours ago if that's what you've been looking at.

saschakiefer commented 10 years ago

I can think about the following use cases:

Did I miss sth?

saschakiefer commented 10 years ago

I hope I catched all cases and all bugs. @js1972 it would be great if you could do a test and see how the approach feels (from a prompting perspective)

js1972 commented 10 years ago

These use-cases look good. I'm not sure that the last one is a requirement. If the point of components is re-usability then your unlikely to want to out your apps namespace on them. But hey... If it's an option there is no harm done.  ;-)I'll test out these scenarios on Monday.

On Sat, Feb 22, 2014 at 1:35 AM, saschakiefer notifications@github.com wrote:

I hope I catched all cases and all bugs. @js1972 it would be great if you could do a test and see how the approach feels (from a prompting perspective)

Reply to this email directly or view it on GitHub: https://github.com/saschakiefer/generator-openui5/issues/47#issuecomment-35753402

js1972 commented 10 years ago

Just had a quick play with generating sub-Components into an app. The rewrite method that adds the resource root is getting confused as the index.html has mixed spaces and tabs which is not good. In fact I'm surprised that the linter hasn't picked that up. Need to clean up the whitespace on all the template index.html files first...

I must say this thing is looking very nice overall.

saschakiefer commented 10 years ago

That Linter doesn't pick it up is pretty clear, since the template files are on the ignore list (I wagely remember, that linter had issues with the template tags in it). But that is anyhow a good point and we should at least lint te templates once to get the relevant issues out of the way.

And I sometimes have the last use case. I use components for structuring even thoug I'm not going to reuse them...