Gustav Novotný 7 Years Ago Hi Javeed, thank you for an interesting new view on CMS/Small portal apps. I'm looking forward to try that After first reading, several questions comes to my mind. (And maybe some code example would help here. ) One of them is: how you keep consistency of the two pieces (CMS structure/template and plugin with backend REST services)? I understand the great flexibility of UI layer here, but what about versioning and consistency with backend plugin. When you change the spec a bit you need to do both, deploy new version of backend and do some manual change in the CMS. (Or keep the structure/template/article within the backend plugin, but then the flexibility is not much different form JSPs.) Is the move form JSP to VM really worth is so much?The second thought is about Liferay 7 migration, shouldn't be botch ways (MVC portlet/CMS articel) similar and easily upgradable without much effort?Please take these thoughts just as friendly discussion kick-off or my ask for clarification. I always really like such a new ideas and thank you for the article again. Please sign in to reply. Reply as... Cancel Javeed Chida Gustav Novotný 7 Years Ago Hi Gustav. Your comment does a great job of pinpointing one of possibly many engineering concerns with the approach I outlined. My intent in using the term 'web application content' was really to foster discussion around thinking about our CMS Template as a versionable entity. Liferay already supports content versioning. If we were to also version templates (and structures), then providing a version ID to our back end REST application is akin to telling it: "by the way, here's the version (or versions) of the front-end template you are compatible with". I really think a methodology could emerge here.Regarding your comment on the move from JSP's to VM being worth it or not: we are wading into a mobile-first implementation style. We have some very talented UI developers. The reality is a JSP file is not the same to them as a velocity template. The latter is far less daunting to UI developers and way easier to experiment with. Switching to velocity templates IMO makes for less time spent by server side developers (me) in supporting the tasks of UI developers.Thanks so much for your insightful comment. Glad for the critique. Looking forward to read more from you. Please sign in to reply. Reply as... Cancel
Javeed Chida Gustav Novotný 7 Years Ago Hi Gustav. Your comment does a great job of pinpointing one of possibly many engineering concerns with the approach I outlined. My intent in using the term 'web application content' was really to foster discussion around thinking about our CMS Template as a versionable entity. Liferay already supports content versioning. If we were to also version templates (and structures), then providing a version ID to our back end REST application is akin to telling it: "by the way, here's the version (or versions) of the front-end template you are compatible with". I really think a methodology could emerge here.Regarding your comment on the move from JSP's to VM being worth it or not: we are wading into a mobile-first implementation style. We have some very talented UI developers. The reality is a JSP file is not the same to them as a velocity template. The latter is far less daunting to UI developers and way easier to experiment with. Switching to velocity templates IMO makes for less time spent by server side developers (me) in supporting the tasks of UI developers.Thanks so much for your insightful comment. Glad for the critique. Looking forward to read more from you. Please sign in to reply. Reply as... Cancel