In Maven multi-module project with Vaadin Flow 14 how can I build a common/shared style/theme module and reuse/import in the web application module.
Which one I should use in the web application. The #StyleSheet which can handle external CSS, or the newer #CssImport? Or do I have to use some maven plugin to copy reosurces (CSS files) from the theme module into the web app module (into the frontend or resources folder)? Is there any examples out there for vaadin 14 multi-module theming?
Any hint would be great, thanks!
There are possibly many ways to do this. I would assume the simplest way is to have component sub-module in your project. I have example here
https://github.com/TatuLund/bookstore-flow-ee/blob/master/bookstore-starter-flow-my-component/src/main/java/com/vaadin/samples/HelloWorld.java
The component itself can include styles, etc.
What I am proposing to you is to use similar custom component as base-layout of your application that imports the needed styles etc.
Related
I'm trying to set up scalajs project using sbt, and since I will be including a "shared" module that will be used by both the jvm side of the project (server) and the js side (web client), I plan to use sbt-scalajs-crossproject. The problem is that I would like to separate part of the js code from the rest to publish as a library (all of the reusable js components). This would require splitting the js part of the project into multiple subprojects. Is this possible?
The best solution I have found is to put the reusable components in a separate scalajs subproject which is published as a distinct module. The rest of the code then goes into a cross-project which depends on the scalajs components project.
We are planning to build an application which has multiple modules
(say [Common which contains Admin, Registration], License Module,
Stock Module ). We have planned to use Maven as our build tool
Each module acts like a separate folder(war) where in it has MVC layers in it. Main POM should encapsulate all the modules and form a war file.
If a customer doesn't need License Module, i can just unplug the settings and recreate a war file without much effort.
Now i am struggling to find proper example to build a hierarchy(project structure like above)
Could you please guide me on this ?
You can create a parent project then add the child projects as modules. You can easily comment or delete these modules before building the project.
Here is a basic example.
http://www.concretepage.com/build-tools/maven/parent-pom-child-pom-example
You can get a good idea about parent child maven projects from the following thread as well.
Maven: adding a reference to a parent pom project
I am configuring grunt for SAPUI5 project. I can configure grunt taks for minify, test and etc. I see there is grunt-ui5 grunt plugin but I am not able to understand what exactly this plugin is doing or useful to SAPUI5 projects.
Thanks
The grunt-openui5 plugin by SAP is documented at github.
It can be used to build UI5 themes and package components and libraries into preload-files.
UI5 tries to load most of the modules of a component or library with a single request from a component-preload.json / library-preload.json file. If it cannot find a preload file, it has to request all modules individually resulting in many many requests and thus poor performance.
grunt-openui5 is used to create these preload files. It also minifies the code while doing so.
The grunt-ui5 plugin is something inofficial which seems to do similar things. You would have to ask the author directly to get more information. I recommend to use the official grunt-openui5 plugin.
For ui5 applications it's not common to use the grunt task for minification , instead we use the grunt-openui5 task. It will create the preload file, which is a json object that contains the whole app.
{
"version":"0.0",
"name":"app name",
"modules":[
"control1": "code for control1",
"control2": "code for control1",
]}
When control1 is required, ui5 just uses the preload to get the code for control1. In this way, ui5 avoids triggering a new request. Anyway, If the preload file is not present, it will have to request control1.js .
If you want to see a real preload file, open any ui5 app and go to the network tab of the browser.
Using the grunt-openui5 plugin for grunt, it will do the work for you, and will give you as a result a library.css, rtl, library-parameters.json (same thing, but for themes) and the preload.json (for the js files).
Instead of using grunt-ui5, I would recommend you to use the the oficial plugin grunt-openui5!
grunt-openui5 is a really amazing grunt plugin created by bunch of SAPUI5 core dev team ;)
It mainly allow you to do 4 things:
create Component-preload.js (optimized and minified version of your app)
create library-preload.js (optimized and minified version of a custom library)
create a custom theme
create a local web server to test your app locally
I've covered it a little bit on my blog post Custom Control 101 if you want to check it out.
I'm using it in daily basis and you can read some of my blog posts about it.
Just a small remark: in the future, consider switching from grunt to gulp, as gulp is newer and faster. For SAPUI5 there are packages with same functionality in gulp, as ingrunt.
I need some utility classes that will be common for three different Liferay portlets so I will develop them in one project that should be shared for my portlets.
I am using Eclipse with Liferay IDE plugin and my question is what kind of project is that one that I need?
I mean is it a simple Java project or any kind of Liferay project?
There are ways you can do this:
Create a simple Java project. Package it as a JAR file. Put the JAR file in global class-path In case of tomcat the global class-path would be ../tomcat-7.0.27/lib/ext/.
Create a simple Java project. Package it as a JAR file. Put the JAR file in the classpath of each and every portlet.
Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar. And then in the portletswhich would need these classes specify the propertyrequired-deployment-contexts=[name-of-your-project]inliferay-plugin-package.properties` of each of the portlet.
Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar and then put the [name-of-your-project]-service.jar in the global class-path and remove it from the WEB-INF/lib of your portlet project so that it does not conflict.
Conclusion
Use 1st-method if the code in utility classes does not depend in anyway on the Liferay API. But this would require a server restart everytime there is a change in the utility classes. Also the Utility classes could be used by Hooks since it is in the global classpath
Use 2nd-method if the code in utility classes does not depend in anyway on the Liferay API. This would not require server restart. But any change in the utility classes would require you to build & deploy all the plugin-portlets which use this jar.
3rd-method: This has the same limitations or features as the 2nd-method, just that you can use Liferay API & your custom service API in the utility classes.
4th-method: This has the same limitations or features as the 1st-method, just that you can use Liferay API & your custom service API in the utility classes.
So here I have listed pros & cons for you to decide for yourself. I would love to know if there are more ways (& much cleaner) to do this in liferay from experts.
I'm preparing to reorganize & refactory a Flash Builder application. The goals of the reorg are 1.) keep compile times for the part of the project I'm working on as fast as possible, 2.) keep the unrelated parts separate for code reuse. Goal #1 trumps goal #2 if there's a trade-off.
Currently, the app has assets in one project, core functionality AS3 in another project, and the MXML in a third project that links to the other two.
Would moving resources/code into swc libraries help compile time? What about compiling assets into an swf and embedding that into the main application? Any other techniques?
We had the same problem, application compile time was more than 1 minute.
Here is our solution:
There is a Core Library that contains class Core with static properties like: Core.resourceManager:IResourceManager, Core.stringManager:IStringManager, etc.
Main application project includes Core Library and provides implementation for all Core.someProp. This can be done via some hidden method like Core.setImpelentation().
There are unlimited number of Modules that use Core Library to contribute their display / logic to the application. Important:
Each Module is a separate Flash Builder project
Module link Core Library as external (it's included in Main App)
Module has XML-file that describes it, example it's name and icon in application control bar. It allows not to load all modules at start.
User should be able to choose which modules he would like to use. This will also help you in development.
You can optionally create Lib Library and include in it all classes that are common between modules and can be implemented using Core Library.
The result is incredible - you application becomes low-coupled, open/compile time decreases, APIs become more clear. Profit!
Modules are definitely the way to go here, as Maxim has described. Further to his advice, which is all solid, here's some other tips:
Extract styles out to a separate project, and compile the .css to a SWF. Load the SWF at runtime.
Structure your packages by business function first, MVC role second,
Eg: Rather than com.myapp.model.userconfig.UserOptions, use com.myapp.userconfig.model.UserOptions. Enforce that packages can only reference their siblings, or com.myapp.core.*.
This way, each package is a self contained module, which only references itself, or the core library.
Consider the Hellfire Compiler, which can farm your compilation over several CPU's in parallel
If not already, consider moving to the Flex 4 SDK, which has several compiler performance improvements, especially around compiling multiple SWC's.