I am working on the SAPUI5 application with normal ES5 code and using grunt-openui5 to create the Component-preload.js file to deploy to CRM system. Now I am planning to use ES6 style coding but we need to support an old browser. Therefore, I need to transpile it down to ES5 and then create the Component-preload.js file. Now my concern with this approach is when I debug the production issue, everyone gets it right, I want to debug my ES6 file, not ES5 file.
Any help or guidance is very appreciated.
One way to have a transpiled, debuggable preload file and separate ES6 based source files is probably to use the sap-ui-debug=true URL parameter option. Instead of the normal files, it will try to load -dbg.js versions of everything. This for instance is what the SAP WebIDE generates:
If you can set up your build set so that the original, untranspiled files are copied as -dbg versions, and your preload picks up the transpiled ones you might be able to make it work.
Here's the section of the SDK documentation that'll give you some more background information: https://openui5.hana.ondemand.com/#/topic/c9b0f8cca852443f9b8d3bf8ba5626ab
Related
I have stored a JavaScript file in a TYPO3 extension (under Resources/Public/Css/JavaScript/Backend/Iconpack.js), which is used as a JavaScript module in the backend.
However, when developing the extension, I packed the file full of console.log() to allow debugging, and also to better document certain things.
Of course I want that in the final extension as well as when downloading via composer, only a minimized version of this JavaScript is loaded, but not the original source file.
On the other hand, of course, I want the original source file to be stored somewhere in the git repository, so that you can actually continue working on it.
In the frontend, I would normally just store Iconpack.js, for example, in the same folder, create a minimized version from it, i.e. Iconpack.min.js, and use this minimized file.
But unfortunately that doesn't work in this case, because the file path for JavaScript modules is also the namespace.
What would be the best way to solve this?
To summarize:
The minimized version should be able to be used directly in the backend via Iconpack.js.
The namespace should be TYPO3/CMS/Iconpack/Backend/Iconpack and not TYPO3/CMS/Iconpack/Backend/Iconpack.min or similar.
The source file should not end up in TER or be loaded via composer.
But the source file should be accessible via Github.
I was able to find out that I can at least prevent a certain file from being loaded via composer with .gitattributes.
Unfortunately, that doesn't solve the question of where I should best place it so that other developers have it easier and it's clear that it's the source file.
Currently I only have the minimized version stored in git for this reason, but that makes little sense for an open source repository: https://github.com/quellenform/t3x-iconpack/tree/main/Resources/Public/JavaScript/Backend
Ideas?
Seems like there is no way to automatically create and manage resx files in VS Code now. Does someone know extension for it?
P.S. Yeah, I know that I can edit resx file as bare xml, but it`s not a right way.
The problem with resx is that it uses a Visual Studio "Custom Tool" to generate the code for the resources, and so requires Visual Studio to function fully.
I've been working on a replacement to resx that should also work from VS Code. It uses json rather than xml to define the resources, but otherwise behaves much like a resx file. The json resources file uses a ".resj" extension, and has a very simple structure. It currently only supports string resources that can be defined either inline in the json, or in an external file reference.
The project is open source on GitHub here:
https://github.com/MarkPflug/Elemental.JsonResource/
This is available as a nuget package "Elemental.JsonResource", currently only pre-release. Simply add this package to your project to enable using resj files. It doesn't add a runtime dependency to your project, everything is done at build-time. My hope is to provide feature-parity with what a resx file can do, but it could be useful even in its current state.
I am new to ExtJs.
When practicing in eclipse do we need to include the entire library(52 MB approx) in the appropriate location?
Is there any shorter version of this library?
Can I delete some files in the library which are not important?
What are the necessary .js files to be included for building a sample MVC pattern, CRUD operation support application in ExtJs 4.2?
For my setup, I include the /ext directory in my project, however I exclude it from the build path so that it doesn't slow Eclipse down. See Eclipse: Javascript validation disabled. but still generating errors?
Then, if you don't even want to see the directory in your workspace, you can create a working set.
I wouldn't recommend deleting/excluding ExtJS source files from your project, especially if you are using Sencha Cmd and/or using dynamic loading in your application.
If you really want to include the bare-minimum, you could get away with using ext-all.js, ext-all.css, and making sure you have all of the ExtJS image files.
I have a NetBeans javascript project with several included paths for plugins. I do not want to include the plugins in my core repository, so I have created separate, external folders for each and am including them via an include path. Because I test across many devices, I need my changes to upload on save and this works fine for the main code base, however, I would like to be able to edit a plugin via the include path and see those changes auto uploaded as well. Is this possible?
As of right now, the only alternative I see is to create separate projects for each plugin, which I am willing to do if this is the only option. The single project workflow is very preferable to me and I might be willing to switch IDE's if this is possible in another environment.
I would be happy to elaborate if my intentions are unclear.
I don't think it's possible. What about creating one single "umbrella" project for all plugins and simply manage it the same way you do the main project?
Personal note: What you have is basically several projects and the uploading is focused always on single project. So what you want is like "I want to treat them as projects but not to at the same time" :) Btw, how do you edit a plugin? I guess open it as a project in NetBeans or use some text editor. So again you basically treat it as a project.
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...