Les applications traditionnelles de la page JSP ne peuvent pas utiliser efficacement les fonctionnalités de syntaxe ES6, et il est difficile de former et de compresser les projets, et ne peut pas être mis à jour à chaud. Les applications traditionnelles à une seule page ne peuvent pas effectuer un rendu côté serveur dans des conteneurs tels que Tomcat pour réaliser l'effet du référencement. Ce projet est bien intégré aux caractéristiques des fonctionnalités traditionnelles de rendu côté serveur JSP et de développement d'applications à une seule page, et est très facile à utiliser!
Adresse de code source
Démos et documentation
Si vous souhaitez prendre en charge IE8, vous devez rétrograder WebPack, car WebPack2 + ne prend pas en charge IE8, et essayer d'éviter d'utiliser des bibliothèques qui ne prennent pas en charge IE8, telles que jQuery2 +, Lodash4 +, Vue, etc. Bonne chance.
Si vous voulez faire du bon travail, vous devez d'abord affiner vos outils.
Si vous aimez modifier JS et CSS, il n'est pas non plus un problème d'utiliser VSCODE, mais il est recommandé d'utiliser l'idée lors de l'écriture de JSP et Java.
Ce qui suit résume les articles connexes sur la configuration de l'environnement, pour référence, l'adresse de téléchargement JDK, la configuration d'idées IntelliJ, l'environnement de développement frontal, la configuration d'idées Intellij, l'environnement Java Web Tomcat, le téléchargement et l'installation de Maven, le téléchargement et l'installation de Git Bash
├── pom.xml // maven配置文件
├── src
| ├── main
| | ├── filters
| | | └── resources // java工程资源配置目录
| | ├── java // java代码目录
| | ├── js // 前端页面工程
| | | ├── build // 编译相关以及webpack相关配置
| | | | ├── build.js
| | | | ├── check-versions.js
| | | | ├── logo.png
| | | | ├── utils.js
| | | | ├── webpack.base.conf.js
| | | | ├── webpack.dev.conf.js
| | | | └── webpack.prod.conf.js
| | | ├── config // 配置相关
| | | | ├── dev.env.js
| | | | ├── index.js
| | | | ├── js-jsp-map.js // 配置入口js和jsp的映射
| | | | └── prod.env.js
| | | ├── package.json // npm配置
| | | ├── src // web项目工程目录
| | | | ├── pages // jsp页面,最终的jsp文件们会按照pages相对路径打包进webapp/WEB-INF/jsp目录下
| | | | | ├── include // 共享的jsp页面,通过jsp:include引入
| | | | | | ├── common_script.jsp
| | | | | | ├── footer.jsp
| | | | | | ├── header.jsp
| | | | | | ├── init.jsp
| | | | | | └── meta.jsp
| | | | | ├── index // 页面1
| | | | | | ├── index.js // 需要在在config/js-jsp-map.js配置与jsp的映射关系,这样编译后的js会加载jsp的body下。一般js与jsp在同一个目录下。
| | | | | | └── index.jsp
| | | | | └── start // 页面2
| | | | | ├── dashboard.css
| | | | | ├── index.js
| | | | | └── index.jsp
| | | | └── my-component.vue 支持VUE
| | | ├── polyfills 兼容相关的代码
| | | | ├── console.js
| | | | ├── index.js
| | | | └── promise.js
| | | ├── static // 存在静态文件,最终这些文件会拷贝到webapp目录下
| | | | ├── favicon.ico
| | | | ├── images
| | | | | ├── jsp.svg
| | | | | └── webpack.svg
| | | | ├── js
| | | | | └── lib
| | | | | └── jquery.min.js
| | | | └── WEB-INF
| | | | ├── tld
| | | | └── web.xml
| | | └── styles
| | └── webapp // 该目录下的文件不用开发人员手动添加修改,在npm run dev或npm run build的时候自动生成。
| └── test
| └── java
La structure du répertoire du répertoire SRC / Main / JS est modifiée sur la base du modèle WebPack de Vue-CLI. Si vous avez créé un projet en utilisant ce modèle, il sera facile de commencer.
cd src/main/js npm run dev
Commencez Tomcat dans l'idée
Ouvrir http://localhost:8081 dans votre navigateur
Les points suivants doivent être prêts attention
Pour la première fois, le démarrage du projet, il est recommandé de démarrer Tomcat npm run dev en premier. Après cela, l'un d'eux redémarrera et l'autre n'aura pas besoin d'être redémarré. Par défaut, npm run dev s'exécute sous le port 8081, Tomcat s'exécute sous le port 8080. En fin de compte, il vous suffit d'accéder à la page de 8081 dans le navigateur et la page de 8080 n'est pas nécessaire. En mode développement, le CSS introduit par JS est introduit dynamiquement et la page aura un effet flash. Ne vous inquiétez pas, il n'apparaît pas dans l'environnement post-libération. Lors du développement de pages JSP, le déploiement à chaud retardera. Pour plus de détails, veuillez vous référer à la section Page JSP pour développer des fichiers JSP dans le répertoire des pages et ne pas vous développer dans le répertoire WebApp. Sinon, après le passage au répertoire des pages pour développer ou package, le fichier JSP sous le WebApp sera écrasé, ce qui entraînera le contenu modifié perdu. À mesure que les fichiers d'entrée configurés dans js-jsp-map.js augmentent, la mise à jour à chaud de webpack-dev-server sera très lente. Il est recommandé de commenter temporairement certains fichiers d'entrée inutilisés en fonction des besoins de développement actuels et de conserver 1 à 3, ce qui augmentera considérablement le temps de mise à jour chaud.
npm run build
Le WebApp est utilisé comme répertoire de sortie. Les fichiers de la statique seront copiés dans le répertoire de sortie. Le fichier JSP dans le répertoire des pages sera copié dans le répertoire WebApp / Web-Inf / JSP en tant que fichier de modèle. Le portail JS associé au JSP sera fusionné et comprimé et introduit dans le corps du fichier JSP. Le CSS associé à JSP sera extrait de la tête de fichier JSP introduite par un seul fichier CSS.
Si le contexte de l'application de votre application emballée n'est pas /, par exemple, /app , c'est-à-dire que l'adresse d'accès est basée sur http://localhost:8080/app , alors lors de l'emballage, n'oubliez pas de configurer / publicPath configurate / app et toutes les adresses de la page JSP doivent être ${pageContext.request.contextPath}/ ${ctx}/
Le JSP traditionnel est développé sous src/main/webapp . Dans ce cadre de projet, les fichiers JSP sont développés sous src/main/js/src/pages . Bien que le répertoire de développement soit incohérent, il possède toujours toutes les caractéristiques du développement traditionnel de JSP.
<jsp:include page=''></jsp:include> ou <%@include file=""%><c:set> , <c:if> , <c:forEach> etc. peuvent tous être utilisés<% out.println("hello world"); %>File->Syncronize> SynCronize (Key Key Ctrl+Alt+Y ), puis cliquez sur le troisième bouton à gauche de Run et sélectionnez Update classes and resources pour mettre à jour manuellement. Après avoir rafraîchi la page, vous pouvez voir la dernière page. En fait, lorsque npm run dev , le JSP dans le répertoire des pages sera utilisé comme fichier de modèle pour le plugin HTMLWEBPACKPLUGIN. Chaque fois que le fichier sous pages est modifié, il sera sorti dans le répertoire relatif sous webapp/WEB-INF/jsp . Si vous avez besoin de comprendre les principes spécifiques, veuillez aller au chapitre principalEn plus des bibliothèques standard C, FMT, FN Tag, vous pouvez également personnaliser la bibliothèque de balises.
<%@ taglib prefix="elf" uri="/WEB-INF/tld/elfunc.tld" %> Notez que l'adresse de la page JSP doit démarrer par / web-inf /, et que le chemin pour développer JSP est dans le répertoire js/src/pages , ce qui fait que l'idée ne résout normalement pas le chemin du fichier TLD dans le répertoire JSP, et il ne peut pas être terminé automatiquement lors de l'utilisation de balises personnalisées. Cependant, il peut fonctionner normalement et le processus de développement réel a peu d'impact. Si vous avez une meilleure solution, veuillez nous contacter.
Parce que vous utilisez WebPack comme outil d'emballage, vous pouvez facilement effectuer une conversion de syntaxe de JS et CSS, et actuellement en charge:
Dans le processus de développement d'une seule application de page, il existe une excellente fonctionnalité qui est des mises à jour à chaud. Si le fichier JS est modifié, la page déclenchera des mises à jour en temps réel. Dans ce cadre de projet, vous pouvez toujours profiter de la joie des mises à jour chaudes. Lorsque vous modifiez JS et CSS, la page déclenchera des mises à jour en temps réel.
Ce projet prend déjà en charge Vue par défaut. Ce chapitre est également écrit en Vue, et vous pouvez profiter de la joie du codage apportée par Vue.
Ce projet combine les fonctionnalités de WebPack et JSP pour implémenter des applications de plusieurs pages, ce qui est cool. Ensuite, comment a-t-il été réalisé? Ici, nous parlerons de la façon de résoudre les problèmes les plus fondamentaux des problèmes rencontrés dans la construction du projet.
L'utilisation de WebPack pour implémenter des applications de plusieurs pages est facile à associer à la configuration de plusieurs portails d'entrée, chaque entrée correspond à un HtmlWebpackPlugin . Le fichier JSP est utilisé comme fichier de modèle pour HtmlWebpackPlugin . Une fois l'entrée JS emballée, elle sera insérée dans le corps. Le projet a également été construit de cette manière. Voici quelques points pour prêter attention
{ test: /.jsp$/, loader: 'raw-loader' } dans webpack. Ici, raw-loader est utilisé pour la copie en texte brut. Si vous avez un chargeur plus adapté à JSP, vous pouvez donner à des fichiers JSP de nombreuses fonctionnalités.config/js-jsp-map.js .Tomcat s'exécute sous le port 8080, WebPack-Dev-Server s'exécute sous le port 8081 et est deux applications différentes. Ensuite, ne serait pas nécessaire d'écrire le débogage sous Tomcat pour le développement et de déboguer dans WebPack-dev-Server pour le développement. Cela ne serait-il pas très gênant?
Heureusement, WebPack-Dev-Server a un paramètre proxy. Nous utilisons le proxy pour inverser toutes les demandes d'accès à WebPack-Dev-Server à 8080. De cette manière, pendant le processus de développement réel, le navigateur n'a qu'à ouvrir la page du port 8081. Cela prendra en compte les fonctions du rendu du serveur JSP, ainsi que les fonctions de la conversion de syntaxe WebPack et de la mise à jour à chaud. Tomcat ne peut être redémarré que si nécessaire. Voici quelques points pour prêter attention
npm run dev et Tomcat, mais les deux services doivent être démarrés avant l'accès au navigateur 8081.npm run dev et redémarrer Tomcat. N'oubliez pas que s'il y a de nouveaux fichiers et supprimer, il est préférable de redémarrer les deux services.Nous savons que WebPack-Dev-Server utilise un système de fichiers en mémoire. La page JSP est finalement publiée sur Tomcat, et le fichier JSP en mémoire ne peut pas être écouté par idée, donc même si la sortie finale JSP change, elle ne peut pas être déployée sur Tomcat. Heureusement, nous avons trouvé un plugin WebPack WriteFilePlugin, qui peut forcer les fichiers de sortie du programme WebPack-Dev-Server vers le système de fichiers disque. Voici quelques points pour prêter attention
Cette idée est en fait non seulement applicable aux applications de plusieurs pages JSP sous Tomcat, mais aussi pour s'appliquer au nœud en tant qu'applications de plusieurs pages de serveur. Profitez-en!