Claire Tech Blog

https://mailtrap.io/ http://nilhcem.com/FakeSMTP/

You should  not  have scriptlet code in JSPs. I'd recommend 100% JSTL and zero scriplet code. JSPs should be purely presentation. That's the hidden benefit of writing JSPs using only JSTL, because they get all their dynamic data elsewhere. Let the service layer have the business logic and determine what data the JSP needs. This answers your unit testing question, too. You should not have to unit test JSPs; those would be Selenium-like UI tests. If the logic is in the service tier, it's obvious how you test it. JSPs should not be inherited. You can certainly compose them together using something like SiteMesh, but inheritance has no part in your JSPs. Once they inherit from Servlet, the chain should be ended. Besides, it's a false alternative. Neither one should require reuse, inheritance, or unit testing. But that doesn't mean there isn't a clear winner: it's JSTL. No one should be using scriptlets in JSPs, except for very rare one-liners. Scriptlet

resource command - can be used for ajax / no need to refresh /    to retrieve images, XML, or any other kind of resource from a Liferay instance. Acction command - get request page refreshing needed

Dependencies required at compile time but never required at runtime (never getting called at runtime)

Customer Identity Accessibility Management - store user authentication Lightweight Directory Service

import -> restore export -> backup bak file

configuration files under osgi/config can be system-wide or portlet level configuration

Configure Workspace Create a file in the liferay workspace called  gradle-local.properties  with the following contents. This assumes The workspace is in  c:\liferay\parkland-portal  and liferay was installed in  c:\liferay\liferay-dxp-tomcat-7.1-sp1 # # Set the folder that contains the Liferay bundle downloaded from the # "liferay.workspace.bundle.url" property. The default value is "bundles". # liferay.workspace.home.dir=../liferay-dxp-7.1.10.1-sp1 For theme, try gulp init and target the tomcat server under liferay server

Hot Deploy Versus Auto Deploy As you develop plugins you’ll want to deploy them to your test servers and as you finish developing plugins you’ll want to deploy them to your production servers. There are  hot  deploy and  auto  deploy options to use in deploying your plugins. Most people confuse the two concepts, believing them to be one and the same. In reality, Liferay has TWO completely separate and different concepts for them. How, you say? We’re glad you asked! This tutorial gives you a brief synopsis of each deployment method. Go ahead and get started by learning about the hot deployment method. USING HOT DEPLOYMENT The first deployment method you’ll explore is  hot  deployment. You may be familiar with hot deployment in the context of Java EE application servers. In summary, you place an application artifact (WAR or EAR) file into a specifically configured directory, your application server (Tomcat, WebSphere, WebLogic, etc.) picks up that artifact, deploys it within the

Environment Setup Install MySQL Server 5.7 using MySQL Installer https://dev.mysql.com/downloads/windows/installer/5.7.html  Recomended Default User: root Recomended Default Password: password If the setup wizard generates a password for you make sure you note it.  mysql> create database lportal character set utf8 Create Liferay Folder and Clone Repository Create folder  c:/liferay  Clone git repository inside  c:/liferay Install Liferay 7.1 Liferay 7.1 SP1 Extract liferay-dxp-tomcat-7.1.10.1-sp1-20190110085705206.zip using 7-Zip in c:\liferay Copy  c:/liferay/parkland-portal/configs/common/portal-ext.properties  to  c:/liferay/liferay-dxp-7.1.10.1-sp1/portal-ext.properties Copy  c:/liferay/parkland-portal/configs/local/portal-ext-env.properties  to  c:/liferay/liferay-dxp-7.1.10.1-sp1/portal-ext-env.properties Recomended: Modify c:/liferay/liferay-dxp-7.1.10.1-sp1/tomcat-9.0.6/bin/ to increase the memory allocated to Liferay and explicitly point to the jdk inst

1. Should be a developer edition 2. Through SQL Server configuration manager, enable the TCP/IP port (default 1433) - In case of error regarding firewall blocking issue, add 1433  to TCP daynamic under IPAll 3. Create database first and then start tomcat server * In properties, defined user should have admin access. - good to set sa(system administrator for SQL server) jdbc.default.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver jdbc.default.username=sa jdbc.default.password= jdbc.default.url=jdbc:sqlserver://localhost:1433;databaseName=lportal index.search.spell.checker.dictionary[en_US]=dictionary/en_US_1.txt,dictionary/en_US_2.txt javascript.single.page.application.enabled=false dl.store.impl=com.liferay.portal.store.db.DBStore dl.file.entry.thumbnail.custom1.max.width=468 dl.file.entry.thumbnail.custom2.max.width=1024 dl.file.entry.thumbnail.custom3.max.width=1280