Getting Good at Obsolete Tech While Boosting Your APEX Front-End
•Download as PPTX, PDF•
1 like•86 views
The world of front-end development is changing fast. From the moment you start adopting a new technology, a newer and better one is emerging. It's a reality that's hard to face when you're getting good at obsolete technology.
Recommended
Recommended
More Related Content
What's hot
What's hot (12)
Viewers also liked
Viewers also liked (16)
Similar to Getting Good at Obsolete Tech While Boosting Your APEX Front-End
Similar to Getting Good at Obsolete Tech While Boosting Your APEX Front-End (20)
Recently uploaded
Recently uploaded (20)
Getting Good at Obsolete Tech While Boosting Your APEX Front-End
- 1. When you’re getting good at an obsolete technology Sponsored by
- 4. 4 • North America’s largest APEX consulting firm • 12 years working with Oracle APEX • 80 employees and growing • Committed to APEX innovation • Our services: application development, coaching, consulting, EBS extensions, and Forms migration • Visit insum.ca for more information!
- 5. 5 Disclaimer
- 6. 6 Front-End vs Back-End in APEX
- 7. 7
- 8. 8
- 9. 9
- 10. 10 Static Files Handling in APEX
- 11. 11 Where do CSS and JavaScript belong? Level APEX Placeholders Substitution Strings Application SC > User Interface Attributes > Details > File URLs #APPLICATION_CSS# #APPLICATION_JAVASCRIPT# Theme SC > Themes > Details > File URLs #THEME_CSS# #THEME_STYLE_CSS# #THEME_JAVASCRIPT# Page Template SC > Templates > Details > File URLs #TEMPLATE_CSS# #TEMPLATE_JAVASCRIPT# Page Properties Page Designer > Page Properties > File URLs #PAGE_CSS# #PAGE_JAVASCRIPT# Page 0 Page Designer > Page 0 > Custom Region with HTML #BODY# #REGION_POSITION_01# … #REGION_POSITION_08#Anywhere… Page Designer > Custom Region with HTML
- 12. 12 Creating new CSS and JavaScript Version 1.0 Well crafted HTML templates State of the art JavaScript Perfectly balanced CSS
- 13. 13 Editing CSS and JavaScript Where’s the code? Dealing with specificity Lack of document- ation Version 2.0
- 14. 14 CSS after many project versions
- 16. 16 Agenda • Installation • Project Configuration • APEX Setup • Running it! • Features • Q/A
- 17. 17 Installation
- 18. 18 Prerequisites • Oracle APEX (5+) • Node.js (4+) • Git (optional)
- 19. 19 On the command line • Open a command line • Go to desired directory Ex: cd c:sandbox • Execute: git clone https://github.com/OraOpenSource/apex- frontend-boost.git cd apex-frontend-boost npm install
- 21. 21 config.json
- 22. 22 config.json { "yourProjectName": { "appURL": " https://apex.oracle.com/pls/apex/f?p=12192", "srcFolder": "C:Sandboxsrc", "distFolder": "C:Sandboxdist" }, "material-apex": { "appURL": "https://apex.oracle.com/pls/apex/f?p=12192", "srcFolder": "../material-apex/src", "distFolder": "../material-apex/dist" } }
- 23. 23 APEX Setup
- 24. 24 Build Option • Not for PROD • Scoping to DEV • Create a Build Option Shared Components > Build Options (BO) Setting Value Build Option DEV_ONLY Status Include Default on Export Exclude
- 25. 25 Application Process • Used to overwrite #APP_IMAGES# • Made possible by a simple cookie • Notes: Prod env. uses default #APP_IMAGES# Dev env. uses localhost (local files)
- 26. 26 Application Process (…) • Create Application Process Name Setting Sequence -999 Process Point On Load: Before Header (page template header) Name OOS APEX Front-End Boost Config Build Option DEV_ONLY Source See below declare l_cookie owa_cookie.cookie; begin l_cookie := owa_cookie.get('oos-apex-frontend-boost-app-images'); if l_cookie.vals.count > 0 then apex_application.g_flow_images := l_cookie.vals(1); end if; end;
- 27. 27 Referencing #APP_IMAGES# • Examples #APP_IMAGES#js/app#MIN#.js #APP_IMAGES#css/app#MIN#.css • Remember Application level Theme level Template level Page properties level • Read the docs on Github!
- 28. 28 Running it!
- 29. 29 Three Options • From the command line npm start -- --project=yourProjectName • From Windows Launch apex-frontend-boost.bat Enter project name • From Linux/OS X ./apex-frontend-boost.sh Enter project name
- 30. 30 Use it wisely you must
- 31. 31 Folder Structure /src/ css js img lib scss less APEX Front-End Boost css changes js changes more… /dist/ css js img lib
- 32. 32 The features you can use
- 33. 33 • Reloads Browser • config.json example • Responsive development "browsersync": { "enabled": true, "port": 3000, "notify": true }
- 34. 34 Minified CSS and JavaScript • Generates a .min version of the code Smaller file size Better performance • Enabled by default • Usage #APP_IMAGES#js/app#MIN#.js #APP_IMAGES#css/app#MIN#.css
- 35. 35 Concatenated CSS & JavaScript • Merge your files together Less HTTP requests, better performance Simpler file management within APEX • config.json example "javascriptConcat": { "enabled": true, "finalName": "app" }, "cssConcat": { "enabled": true, "finalName": "app" }
- 36. 36 Error Warnings • CSS and JavaScript are interpreted languages • Code Linters.
- 37. 37 • Debugging a minified file • Linking the minified file to the source file
- 38. 38 • CSS Preprocessors • config.json example "sass": { "enabled": false, "includePath": "" }, "less": { "enabled": false, "includePath": "" } "sass": { "enabled": true, "includePath": "../bs4/node_modules/bootstrap/scss" }
- 39. 39 • Vendor prefixes • Removes complexity a { display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex } a { display: flex }
- 40. 40 Theme Roller • Custom attributes • config.json example • More on my other session "themeroller":{ "enabled": false, "finalName": "themeroller", "files" : [] }
- 41. 41 Conclusion
- 42. 42 What it does How it helps you Minifies code Saves time Concatenates code Performance ++ Sourcemaps Favorite coding environment SCSS / Less No more browser manual refresh Vendor prefixes Changes only affects you Theme Roller Error notifications More… Recap
- 43. 43 Official Github Page • https://github.com/OraOpenSource/apex-frontend-boost • Provide feedback • Submit issues
Editor's Notes
- Hello everyone! You know, it’s always awkward when you have to decide a session title several months in advance, especially when you only have a slight idea of what the content will be. When I submitted the session as “When you’re getting good at an obsolete technology”, I kind of knew the direction I was taking. Months have passed and an actual open source project came out of it.
- Several weeks ago we unveiled an Open Source APEX project that generated a lot of noise on social media. The project is released under OraOpenSource which has well over ten active Oracle and Oracle APEX projects under it’s belt. It’s been sponsored by Insum since the very beginning, so I want to thank them for allowing us to spend that much time into the development process. Thank you all for being here, I’m excited to present APEX Front-End Boost to you even though it’s a few weeks old already.
- My name is Vincent, I’m a developer, I’ve been working with APEX for over 6 years now You might know me from Twitter or my blog. I’ve contributed to some interesting open source projects. You can ping me on any of those mediums, it’ll be my pleasure to chat with you and I’m usually pretty fast to reply. Also, if you want to contribute to one of my open source projects, just know that I’m very keen to that as well.
- For those who don’t know Insum, we are the North America’s largest APEX consulting firm. We do application development, coaching, training, consulting and much more.
- Until the end of the session, I will go back and forth from this presentation to live demos. If Murphy’s law is against me, it WILL probably crash. Bare with me and wish me luck.
- As you would’ve suspected, today we’re going to talk about Front-end. Before we do so, let’s quickly make sure everyone understands the difference between front-end and back-end developers.
- You may have seen the iceberg analogy before. We know that the ice above the water represents the front-end stack. It is what users see and interact with. HTML, CSS and JavaScript are the front-end developer’s core technology. Underwater represents the back-end stack. We live and breath Oracle, do we? So that means Database Design, SQL, PL/SQL etc. Some of you may very well be considered full-stack developers. That is when you’re as comfortable on the front-end than on the back-end side. In the world of APEX, we always do a little bit of both right?
- Lately we’ve seen some crazy Node.js projects along with APEX, which pretty much fills the gap between the two stacks, as it allows to code seamlessly between front-end and back-end using JavaScript as a single language. Just look at the biggest APEX conferences. Look around the Kscope schedule. Count the number of sessions that talks about Node.js, it’s astonishing. And that’s way bigger than just us (APEX developers). The whole web development community is striving around Node.js and it’s a good time to jump into the ship. But anyway if you haven’t poked around yet, I strongly suggest to have a look. Especially in our line of work, start playing around node-oracledb, it allows to connect to the Oracle database from a Javascript environment. And trust me, it opens up a world of possibilities!
- Getting back to the iceberg analogy, I believe it is even truer for APEX developers. And the reason is we’ve been fed with incredibly rich themes for years, making it super easy to create visually pleasing applications in a matter of minutes. So basically you don’t need to have any front-end knowledge to build an APEX application. That being said, I am generalizing and there are some very talented front-end developers in the APEX community.
- Let’s move on. Since front-end development basically comes down to HTML, CSS and JavaScript, it is extremely important to understand the way static files are handled through APEX in it’s current state. As you might know there are a lot of places you can put CSS and JavaScript. Whether it’s inline code or as a reference to an external file, this kind of widespread use of front-end code can lead to maintenance issues.
- Here’s a summary of some of the possible locations you can put CSS and JavaScript in. You can choose from the application level, theme level, page template level, page properties, page 0 and more. All of them have their dedicated placeholders and substitution strings. Part of the challenge of creating a great theme is being able to properly use these substitution strings across the application. From my experience, I found that junior developers can have a hard time understanding the difference between those placeholders. When building APEX Front-End Boost, we have decided to streamline the use CSS and JavaScript. To put it simply, there shouldn’t be any inline CSS or JavaScript anywhere. We encourage to put every bit of code in external static files.
- Let’s say you start a new project. Your boss doesn’t want you to cut any corners, so you’ll take everything very slowly and think about how you will build these static files. Cause it needs to be maintainable right? So with that in mind you start coding meticulously. You write perfectly balanced CSS. State of the art JavaScript! And you think you’re in pretty good shape… You design some very well crafted HTML templates… And that gives 1.0 And you’re happy with it cause you’ve built a great app with all the best practices.
- Time flies. A year goes by. Your customer wants new stuff. Really simple changes. …And you start searching… **Where did I hardcode my background color again…? So you do an application-wide search. Or maybe it’s in a static file? Can’t remember… Maybe you find it, or maybe you don’t. But for some reason your background color change doesn’t work. CSS specificity is playing tricks on you. Its so tempting to override a CSS rule by adding a new one at the bottom of the file. And on top of it, there’s no documentation whatsoever. A few more iterations and you’ve got a time bomb. Hello version 2.0.
- It’s true. Coding in CSS and JavaScript is hard. It’s hard to learn and to maintain. It’s hard to organize and keep clean. The more you change the original codebase, the worst it’ll get. The only way to get around that is to have a perfectly well structured codebase that is consistent across the board.
- APEX Front-End Boost makes coding faster, easier, and prettier. This tool helps you work with static files more efficiently within an APEX application. APEX Front-End Boost is a personal local web server that hosts and distributes your files to your app. Without any further delay, here’s what it looks like. {Demo}
- Here’s today’s agenda. 1) First we’re going to show how to install APEX Front-End Boost. 2) Then we’ll show how to configure your different projects. 3) Then, you’ll want to tweak your APEX apps so they communicate well with APEX Front-End Boost. 4) Then we’ll show how easy it is to run the whole thing. 5) Once you grasp everything, we’re going to deep dive into all the available features. 6) Then it’ll be your turn…
- So! The installation process... This is a one shot deal.
- Let’s see what we need before we get started. Hopefully everyone agrees on this one. We decided to “officially” support APEX 5 and up, but it would work on APEX 4 as well. Node.js is the architecture on which APEX Front-End Boost is based upon. Specifically we will be using a tool called Gulp that will be watching your local files and executing the appropriate package. FYI, if Node.js scares you, rest assured. You don’t need ANY Node.js knowledge to use APEX Front-End Boost. We’re providing a nice interface that hides the complexity of anything Node related. Git is optional because you can always download the zip file from Github, but we favor a Git approach that will be easier in the long run to keep track of future updates.
- So let’s install this shall we? {Demo this slide} First off: Open up a command line Go to the desired directory of where you want to install APEX Front-End Boost Execute the following: git clone https://github.com/OraOpenSource/apex-frontend-boost.git cd apex-frontend-boost npm install You might see some deprecation warning because of the way we use package dependencies. Do not worry about it. They don’t affect APEX Front-End Boost.
- Now that we’re done installing, let’s see how to configure a project.
- Upon the installation process, APEX Front-End Boost generates a configuration file. That file is a JSON file that holds the settings for each one of your APEX apps. On the screenshot, I’ve shown the APEX Front-End Boost directory, inside of which lies the config.json file. It’s up to you to configure your projects appropriately.
- Let’s focus on the content of config.json. In this example, you can see 2 different projects, but you can have as many as you want. There is only 4 mandatory settings to fill out. So first off you define the project name. In this case I’ve got yourProjectName and material-apex. You’ll want to put your actual APEX application URL in the first parameter here. In the 2nd parameter, you’ll have to specify the local path to your project source folder. The path can be in an absolute or relative format, just like both of these projects. This is where lies all your static files basically. Same thing for the 3rd parameter, although this one does not need to exist yet, it’ll be created by APEX Front-End Boost itself. Remember, the whole idea is to enable and expose your local files to your APEX application, so this is where we make the connection.
- Now that the project is configured properly, we’ll need to tweak your APEX application a little, so it can communicate with APEX Front-End Boost. There are 2 ways of doing so, but today we will only show the simplest one. I invite you to read about both options on the APEX Front-End Boost Github page, over there you’ll find detailed step by step information on how to achieve both.
- APEX Front-End Boost isn't meant to run in production. A build option is used to limit the scope of APEX Front-End Boost to the development environment only. The build option is called DEV_ONLY. Status is set to include so that any component with that build option will be included in the development environment. Default on Export will be set to export, that way when you export your application anything tagged with the DEV_ONLY build option will not be run.
- Since APEX 5.0, #APP_IMAGES# is a repository available through the shared components, which allows to bundle static files as part of an application export. We encourage to use #APP_IMAGES#, as it makes the migration much easier than it was before. That being said, you will need an application process to overwrite the value of #APP_IMAGES#, in order to map to your local files instead. All of that will be made possible thanks to a simple cookie trick that understands that APEX Front-End Boost is running and that reroutes #APP_IMAGES# to your local folder. And because of our previously defined build option, this will only occur in the development environment, not in prod.
- Here’s the application process details. Sequence -999 is used to make sure this is the first thing that happens. Process Point is On Load: Before Header, also to make sure it is executed before the static files are loaded. Name doesn’t really matter, but we might as well put something representative like OOS APEX Front-End Boost Config. For all of you skeptics, yes, this is occurring on every page load, but remember this is for the development environment only, hence we apply the build option previously defined. The impact is minimal. Without going into details, the code is very simple. Basically we’re looking for a cookie named oos-apex-frontend-boost-app-images, if it exists, we overwrite #APP_IMAGES#, if not we do nothing.
- As I mentioned earlier, any static file must be referenced with the #APP_IMAGES# substitution string, regardless of where it leads underneath the hood. 1) Here are two common examples for your master CSS and Javascript files. 2) Remember what I said earlier. You can put these references to many places. Application level Theme level Template level Page Properties level And if you are really interested in seeing the different options available for making the APEX setup, read the docs on the official Github site!
- We’re almost there! Let’s just run it now.
- APEX Front-End Boost can be executed three different ways. If you’re a command line purist, from the APEX Front-End Boost root folder, you can execute the following command: npm start -- --project=yourProjectName. The project name value comes from the config.json file you have configured before. If you’re on Windows, you can simply execute the apex-frontend-boost shortcut, enter your project name. If you’re on a UNIX environment, you can execute our shell script and enter project name. This is really up to you. No pros and cons. Just personal preference. {quick demo of Windows shortcut}
- So that’s it, we’re done with installation/configuration/setup. Now learn how to use it wisely you must.
- Remember that we’ve specified a /src/ and /dist/ folder in the config.json file? This is where it makes sense… Under the source folder you’ve provided, APEX Front-End Boost will be looking for these sub folders. Some are mandatory, some are optional. Front-End Boost is watching for any changes in these subfolders. The magic happens as soon as you save any file in there. The code will be compiled into the /dist/ folder. The /dist/ folder is exposed to your local web server and at the end of the day, your APEX application points there.
- We’ve pretty much covered the basics. You’ve seen roughly what it can do earlier. If you want you can absolutely just use what you’ve seen. Now I will dig into the specific features to personalize APEX Front-End Boost to your likings. Just remember that most features are opt-in, so you don’t really need to include any of them.
- This is the main reason why APEX Front-End Boost is a killer tool. First of all, having this feature means no more browser refresh! As soon as you save your code in the text editor, you get automatic css injection / javascript reloading in the browser. This is what you’ve seen in the main demo. Browsersync is enabled by default. You can specify the port, allowing you to run multiple instances of APEX Front-End Boost for multiple projects at a time. There is also a notification option, that triggers a unobtrusive alert message on your browser when any CSS or JavaScript is changed. It makes responsive development easier by synchronizing multiple devices together. Your desktop, tablet and mobile device will imitate each others actions (scrolling, clicking, typing) as long as you've got APEX Front-End Boost running. {demo}
- APEX Front-End Boost generates a minified version of your CSS and JavaScript code. A minified file is stripped out of spaces and return carriages. In Javascript, variables are also renamed to a single character like a, b or c. Let’s say you’ve coded app.js in the /src/ folder. Upon saving, the /dist/ folder will contain both app.js and app.min.js This feature is enabled by default. Your APEX application should always use the minified version in production, therefore you should use the #MIN# substitution string. {no demo}
- Merging your files together is good practice. It reduces the amount of HTTP requests, therefore enhancing the performance. Also, having just one file to declare in your APEX templates makes life simpler. This feature is not enabled by default, so you’ll have to adapt the config.json file accordingly. If you do enable it, know that you can specify a name for a final file, otherwise it’ll default to app.js and app.css {demo concat and minified}
- Using a compiled language such as PL/SQL sure has advantages, like being notified of a syntax error right away. As you may know, CSS and JavaScript aren’t like that, they’re interpreted languages. It means that you won’t know what’s wrong until the error occurs on the page. We have included linters with APEX Front-End Boost, meaning that you’ll be notified for any CSS or JavaScript error upon saving in your favorite code editor. {demo}
- Sourcemaps is definitely one of my favorite features of Front-End Boost and they are enabled by default. One of the drawbacks of working with .min files is that it becomes impossible to debug. Have you ever seen a JavaScript error like this? It’s incredibly time consuming. APEX Front-End Boost comes with built-in Sourcemaps support. Sourcemaps are linking the final file to the original source one. Instead of seeing the mess above, you’ll be able to trace the code back to the right place. {demo}
- 1) We won’t get into the what, why and how of CSS preprocessors today. Way too much to cover, but the technology has been around for a while and you should definitely try it sometime if you haven’t already! 2) For now we support Sass and Less. Both are disabled by default obviously, as we don’t want to enforce a CSS Preprocessor to anyone. 3) If you do enable it, pay attention to the includePath property, this allows you to import Sass or Less files from another local folder on your computer. It it useful for integrating other frameworks such as Bootstrap, which also supports Sass. {demo transforming css to sass}
- Some CSS properties require complex knowledge of browsers vendor prefixes. Have you ever wondered why some CSS have to be written like this. APEX Front-End Boost comes with Autoprefixer built-in, which allows you to simplify your CSS code by removing the vendor prefixes. {demo}
- APEX Front-End Boost is highly compatible with Theme Roller. Have a look at the screenshot on the right. This ain’t universal theme. We generated these attributes from Front-End Boost, and it works perfectly. This part of APEX Front-End Boost requires a bit more knowledge about Theme Roller and Less, so I’ll skip this part today. For more information on Customizing the Theme Roller, I will be giving a session about it tomorrow.
- So that was APEX Front-End Boost… Let’s do a quick recap okay?
- What APEX Front-End Boost does Minifies CSS and JavaScript. Concatenates CSS and JavaScript. (optional) Generates CSS and JavaScript Sourcemaps. Parses SCSS and LESS to CSS. (optional) Adds CSS vendor prefixes. Generates APEX Theme Roller configuration. (optional) How APEX Front-End Boost helps you It cuts down on front-end development time. It enhances your application performance due to smaller file sizes. It lets you keep coding in your favorite code editor, without having to constantly upload anything to APEX or a web server. Stop manually refreshing of your browser to get CSS and JavaScript modification. Stop affecting other developers. Any development done within APEX Front-End Boost affects you and only you. Be notified of CSS and JavaScript errors as you save.
- Alright… remember that this is an Open Source project. Please provide feedback. Feel free to submit issues or pull requests because this is how we’ll make the product even better.
- Thank you all for attending. We are proud to make this tool available to everyone and we hope it’ll be as useful to you as it is to us. Tomorrow I will be giving a special Theme Roller advanced deep dive, and I will be showing how it integrates with Front-End Boost. Come see me! Any questions?