saschakiefer / generator-openui5 Goto Github PK

The initial view and controller are in the root directory; but there is no sap.ui.localResources() call for this. Therefore the app attempts to read resources from the same location as the UI5 library which is ttps://sapui5.netweaver.ondemand.com/resources/ and fail.

If I move the view and controller into a view subdirectory and adjust the source code to suit; it works fine.

I'll fork the repo and try fix it. I'd like to add support for XML views as well... ;-)

The current app template has a Fiori Style and Interaction Pattern. Nevertheless can't it be integrated in the Fiori infrastructure (i.e. Fiori Launchpad), yet. That should be provided

As you spotted the northwind mock server url's were hard-coded. This was just to get it working.... Now I'm thinking about dynamically generating them and there's a slight problem if we are using the bower library... It only includes the resources directory and not test_resources where the northwind mock resides.

I could just grab the northwind mock .js file and scaffold it directly, then there is no dependancy - I'll plunk it into the generated models/ directory.

What do you think? I think its safe to scaffold the file as the Northwind service hasn't changed for a very long time so I think its stable. Otherwise we'd need to add the test_resources folder to the bower dependancies as well...

?

The best practices described by SAP (in the SDK) state that its wise to use the Event Bus for navigation. Our apps are based around the TechEd Fiori example which do not... Should we enhance (in the future) for the Event Bus?

On NW ABAP, UI5 applications are provisioned inside a BSP container application. Investigate if there is a way we can have a grunt task that will deploy an app to NW ABAP.

Need to think of a good prompt to ask users. For example - more experienced users won't want to download UI5 with every app generation but are likely to have several versions already on their PC's. Some may not have internet access at the time of generating, etc.

Maybe a prompt that gives 3 different options:

1. download ui5 with bower and lunch the node server (as it does currently)?
2. select a location of your ui5 library (for those that already have versions of UI5 downloaded)?
3. use the https://openui5.netweaver.ondemand.com/resources/sap-ui-core.js library?

That should all be available for all generators.

I recognized, that inconsistent code style leads to diff information which is not meaningful (i.e. if the formatter modifies a lot of spaces, the whole file seems to be changed).
Therefore I created a wiki page with styling information which are based on JS Beautify.

It can be run either as a Node.js module or as a Sublime Text Plugin.

I also added a "Contribution" section on the README section to make it more prominent.

If there are any issues with that approach, please let me know.

If you have slashes in the text answers to the prompts that are writing into the package.json. npm install will fail.

We can easily escape them out - is it worth it..?!?

Throughout the code there are some places where " is used and some places where ' is used. Did you want to align this and use one all the way through... Even all the sapui5 examples that sap put out use both which is silly. Look at the generated index.html file as an example:
jQuery.sap.registerModulePath('Application', 'Application');
-- whereas double-quotes are used everywhere else.

i.e. If we generate a component inside our app with namespace foo.bar.mycomponent then JSHint will complain about the generated Component.js file that foo is not defined. Adding /*global foo*/ to the top of the file fixes this.

Should we ensure that generated files are all JSHint error free?

This issue applies to all generators - even the app generator. It just happens that we have sap defined as a global in .jshintrc which hides the error if you select the default namesace (sap.ui.demo) on your app.

Its generally considered bad form to have lots of GET requests to pickup many js files (as we would have in a typical UI5 app architecture). Can standard Grunt uglify and concat tasks be used in a UI5 environment?

The SDK hints at the fact that internally SAP have tools for this to build UI5 itself but there are no details on its use provided.

There should be a .gitignore file in the template (especially to not upload bower and node components).

After SAP went Open Source with UI5, I adjusted the repository name (as well as some content) to OpenUi5.
@js1972, hope that does not screw your current development, but I thought the earlier the better. Let me know, if there are some issues)

There is always the standard name taken in the App, instead of the name entered during the scaffolding prompts. I guess that's a bug?

When templating a file we typically substitute some variables for the generator prompt answers. We need to add test cases that inspect and ensure these substitutions have taken place. This will stop issues such as #44 from occurring.

Should we set the JSHint task to use the .jshintrc - only one place to make changes then.

In the gruntfile there is a task:
application: {
files: '<%= jshint.application.src %>',
tasks: ['collaboration']
}

this should be
application: {
files: '<%= jshint.application.src %>',
tasks: ['jshint:application']
}

Is this worth it or will openui5 soon have the missing libraries from sapui5?

Due to a bug in generator-generator we can't add additional tests for the app/fiori/vew generators yet. Once the fix is in we can write more robust tests.

Gulp.js is getting popular - the creators or Yeoman are putting effort into using it as well. Its nice: code over config; and much simpler than gruntfiles. Allot of popular grunt tasks are already available with Gulp.

We should have an option to set the port of the grunt serve task in order to avoid conflicts of already running servers (defaulted to 8080)

Check out this on jsbin:
http://jsbin.com/IGUhOfu/2/edit

Interesting... could possibly add similar to the generator as an option. Always better to show a spinner (or something) instead of blank when loading the libraries - which are pretty slow - especially from openui5.hana.ondemand.com.

At least the server port should be configurable. Maybe also the prefix to the UI5 repository

Currently the application is wrapped in an Application.js object. That should be changed to a component, since that's the recommendation.

Basic details prompts from promptForBasicDetails (script-base.js) are not being templated into index.html and package.json. All other prompts seem to be working fine - even those defined in script-base.js so I don't believe it is an inheritance or binding issue.

The Component.json template contains a legacy comment for the description. This should be removed or replaced by text form user input.

When generating a sub-view and you choose Y for add to application namespace... Why do you give the user the option to change the application namespace? It doesn't add a new resource root at all and only seems to effect the actual view name.

ToDo: Check Component Views

http://yeoman.io/blog/cleanup.html

In the current develop branch (no pull-request just yet) we can run the generator and choose what UI5 library to use.

1. From bower
2. Custom - remote: default or enter a remote url
3. Custom - local: enter a local relative path

Option (1) has been catered for by using sapui5/resources/ in index.html and also using a url alias in the JADS server to point to the 'real' bower_components folder.
Option (2) just directly writes the remote url into index.html and sets up no web server alias.
Option (3) enters sapui5/ into index.html and sets up an alias from that to the local directory (user must enter relative path from their project directory).

But....

Maybe we don't need this. As discussed - if a developer already has the UI5 libraries installed on their machine then are are more than likely going to have Apache, Tomcat or something already setup to serve them.
Maybe the url aliases will be confusing to the user?!?

Maybe for simplicity we should strip this functionality back to just two options:

1. Use Bower (default)
2. Use the standard sap remote url: (openui5.netweaver.ondemand.com).

... and use no server alias - just write the actual path for bower_components.

Discuss.....

When the component controller doesn't find the comment /* endOfResources */ in index.html, it adds sap.ui.localResources( "myDir" ); at the beginning of index.html.
if the hook isn't found, the generator should do nothing.

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.

As soon as JADS is available as node package and Grunt task, change the dependency to that instead of a local copy in the generator.

Currently the user prompts for Fiori and XML view follow the pattern: "There is a default behavior and on can decide, if he deviates from that". For the user it's not transparent what the default behavior is.

The application generator is currently dependent on the view generator. The Application.js file (which belongs to the application templates) is copied in the view generator to the application (because the view name which is called in the Application.js file is only known in the view generator). This should be changed.

Possibilities:

• Use a hard coded name in Application.js
• Copy Application.js in the application generator and change it in the view generator to the final view name

The generated views load by default: sap.ui.commons as UI Library.
When generating a fiori app, the ui library that is needed is sap.m.
The consequence is, that a view does not work out of the box. Should we ask the user for the library to use, or should we try to extract that from the bootstrap.

The complete path entered for the component will be used as component name in the Class declaration. But there might be cases, where the path is different to that name (e.g. additional package declarations). Maybe the namespace should be declared separately.

e.g. the namespace of the component is:
my.foo.bar.component

but the user want's the component be placed under js/components/

That could be the case, if there is one central place for components but the component should be put under a certain namespace extending a package.

Do you think, that is a viable use case or more of an edge case?

It reports errors in the Gruntfile.js where I have added comments to describe how to enable proxying of resources.
It just seems ridiculous to me that any linter would parse comments. According to the issues on the JSHint repo the owner wants this for consistency - which I think it stupid! The only answer is to enable smarttabs: true. But this does not seem to work on the generated Gruntfile.js.

The libTest section in the Gruntfile.js points to a directory which is not part of the scaffolding.

The watch:libTest task points to a jshint subtask which does not exist.

libTest seems to be an incorrect name anyways.

The default view directory is "view". For this, there is also a sap.ui.localResources("view"); statement generated in index.html.
If a user now creates a view in a different directory, which is not made known to the framework, it will always run into an issue. Therefore a new feature would be to check during the view generation, if there is an related localResources definition available, if not, generate one. I'll track that as errors/ feature request.

The component generators are not covered by tests yet. That needs to be fixed.

The logic used to prefix the splicable with spaces needs to account for the fact that the index.html might be written using tabs instead of spaces.
It just so happens that our classical app generator has an index.html that still uses space instead of tabs.

Create an application template for Fiori Apps

We are currently using JADS (grunt-jads originally based on https://github.com/bocallaghan/JADS) to serve our generated app. It is very simple and allows url aliases and basic resource proxying with GET requests (plus directory listings). We could continue to work on this....

However I've been investigating the widely popular grunt-contrib-connect plugin. On the surface it looks to have more basic functionality but dig a bit deeper and it can do all of the above that JADS can do plus more.
You can do aliasing by specifing multiple document roots to serve from (effectively the same thing). It has middleware configuration enabling you to specify your own web server middleware. Standard functions include dir listing. Then there is a slight enahncement to this that allows proxies: grunt-connect-proxy.

Should we switch to connect...? Discuss....

Note that under the hood they both just use the Node.js connect module to do the work.

Live-reload might be a bit confusing to newbies so lets make it an optional extra.

Question - what about the WATCH task? Its probably in the same boat and maybe that should be an option as well?

Build process (list of checkboxes):
-- Enable dynamic watching of files to Lint and run tests? (default true)
-- Enable Live-reloading of the browser? (default true)

?