(あなた) 12年 前 [...] Ok, so in the last post I talked about JSP Include Buffer. That post talked about how you'd override JSPs from Liferay's core in a maintainable way. Now I'd like to introduce you to another Liferay... [...] Read More 投票するためにはログインが必要です。 次として送信する: キャンセル
(あなた) 12年 前 [...] Ok, so in the last post I talked about JSP Include Buffer. That post talked about how you'd override JSPs from Liferay's core in a maintainable way. Now I'd like to introduce you to a Liferay Theme... [...] Read More 投票するためにはログインが必要です。 次として送信する: キャンセル
Kieran Brady 12年 前 Our approach to maintainability in this area is that whenever we want to override a JSP in a hook, we take the original Liferay version and check it into our hook project in SCM, then apply our customisations and check those in. This way we can make a diff of exactly what the changes are and can re-apply them if neccesary when upgrading. Simple and easy to explain.Having to manipulate the buffered HTML as described sounds like crazy talk to me for all but the simplest use cases - why provide a method to override JSP in hooks, then give a further method to side-step the override to get to the original, and then re-process the result!? This makes your hook code less maintainable/fathomable and more spaghettified IMHO. 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé Kieran Brady 12年 前 Hey Kieran,Liferay has been using this pattern for hooks already for a couple of years. We are now just extending it to themes since JSP changes are global, and the requirement was for themes to support non-global changes to the view tier.As much as you may like the diff approach it has been our experience that, beyond a certain magnitude, it becomes unmaintainable. The buffer approach has proven itself over the course of several versions in several projects to be far better than the diff approach.Note we use this technique _from_ hooks to avoid having to replicate the original code. This is much closer to "extends" behavior of java than a "diff" and also results in our hooks having far less code than using the diff approach.Another point is that you can't place JSPs in a theme and so you'd have to re-write the entire logic of the JSP in a template language, which I don't have to tell you will be itself a challenge on top of having to maintain the converted mapping over several versions of the product. 投票するためにはログインが必要です。 次として送信する: キャンセル Kieran Brady Ray Augé 12年 前 Hi Ray - thanks for the reply. I guess I'm just thinking about our specific use cases and what suits us - as you say, its great to be able to 'extend' in the OO sense, it just seems somewhat unreachable through the manipulation of buffered HTML, particularly if there is a core element or set of elements in that page that you want to change. 投票するためにはログインが必要です。 次として送信する: キャンセル Raymond Gardner Kieran Brady 12年 前 Hi Ray,I am new to Liferay so, please forgive my naiveness.All I see happening here is a red colored border being wrapped around the start.jsp output. That is great if your objective is this simple.How do you change the guts of a jsp using this method? Do we have to parse the html variable and seek out places to add and places to replace?I'm somewhat lost. 投票するためにはログインが必要です。 次として送信する: キャンセル Sergio Sánchez Raymond Gardner 12年 前 I guess that is the case, to modify the markup generated by the core JSP file.I think that could be useful for small modifications like deleting some tags (if we want to disable some functionality an there are not any other menas to do that)If we want to change a lot the behaviour of the core JSP file, wouln't it be better to modify the JSP file as we were doing until now?Also, another use case could be to attach custom JSP code before or after the core JSP code. In that case this new tag could be very useful.Am I right? 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé Sergio Sánchez 12年 前 You're right on both counts... I wasn't saying that this is the only way, just another method to add to your toolbox. The Liferay methodology is to use the solution that is the cleanest for the current problem. There are no one size fits all solutions. Otherwise, we'd have all been out of a job log ago. 投票するためにはログインが必要です。 次として送信する: キャンセル
Ray Augé Kieran Brady 12年 前 Hey Kieran,Liferay has been using this pattern for hooks already for a couple of years. We are now just extending it to themes since JSP changes are global, and the requirement was for themes to support non-global changes to the view tier.As much as you may like the diff approach it has been our experience that, beyond a certain magnitude, it becomes unmaintainable. The buffer approach has proven itself over the course of several versions in several projects to be far better than the diff approach.Note we use this technique _from_ hooks to avoid having to replicate the original code. This is much closer to "extends" behavior of java than a "diff" and also results in our hooks having far less code than using the diff approach.Another point is that you can't place JSPs in a theme and so you'd have to re-write the entire logic of the JSP in a template language, which I don't have to tell you will be itself a challenge on top of having to maintain the converted mapping over several versions of the product. 投票するためにはログインが必要です。 次として送信する: キャンセル Kieran Brady Ray Augé 12年 前 Hi Ray - thanks for the reply. I guess I'm just thinking about our specific use cases and what suits us - as you say, its great to be able to 'extend' in the OO sense, it just seems somewhat unreachable through the manipulation of buffered HTML, particularly if there is a core element or set of elements in that page that you want to change. 投票するためにはログインが必要です。 次として送信する: キャンセル Raymond Gardner Kieran Brady 12年 前 Hi Ray,I am new to Liferay so, please forgive my naiveness.All I see happening here is a red colored border being wrapped around the start.jsp output. That is great if your objective is this simple.How do you change the guts of a jsp using this method? Do we have to parse the html variable and seek out places to add and places to replace?I'm somewhat lost. 投票するためにはログインが必要です。 次として送信する: キャンセル Sergio Sánchez Raymond Gardner 12年 前 I guess that is the case, to modify the markup generated by the core JSP file.I think that could be useful for small modifications like deleting some tags (if we want to disable some functionality an there are not any other menas to do that)If we want to change a lot the behaviour of the core JSP file, wouln't it be better to modify the JSP file as we were doing until now?Also, another use case could be to attach custom JSP code before or after the core JSP code. In that case this new tag could be very useful.Am I right? 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé Sergio Sánchez 12年 前 You're right on both counts... I wasn't saying that this is the only way, just another method to add to your toolbox. The Liferay methodology is to use the solution that is the cleanest for the current problem. There are no one size fits all solutions. Otherwise, we'd have all been out of a job log ago. 投票するためにはログインが必要です。 次として送信する: キャンセル
Kieran Brady Ray Augé 12年 前 Hi Ray - thanks for the reply. I guess I'm just thinking about our specific use cases and what suits us - as you say, its great to be able to 'extend' in the OO sense, it just seems somewhat unreachable through the manipulation of buffered HTML, particularly if there is a core element or set of elements in that page that you want to change. 投票するためにはログインが必要です。 次として送信する: キャンセル Raymond Gardner Kieran Brady 12年 前 Hi Ray,I am new to Liferay so, please forgive my naiveness.All I see happening here is a red colored border being wrapped around the start.jsp output. That is great if your objective is this simple.How do you change the guts of a jsp using this method? Do we have to parse the html variable and seek out places to add and places to replace?I'm somewhat lost. 投票するためにはログインが必要です。 次として送信する: キャンセル Sergio Sánchez Raymond Gardner 12年 前 I guess that is the case, to modify the markup generated by the core JSP file.I think that could be useful for small modifications like deleting some tags (if we want to disable some functionality an there are not any other menas to do that)If we want to change a lot the behaviour of the core JSP file, wouln't it be better to modify the JSP file as we were doing until now?Also, another use case could be to attach custom JSP code before or after the core JSP code. In that case this new tag could be very useful.Am I right? 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé Sergio Sánchez 12年 前 You're right on both counts... I wasn't saying that this is the only way, just another method to add to your toolbox. The Liferay methodology is to use the solution that is the cleanest for the current problem. There are no one size fits all solutions. Otherwise, we'd have all been out of a job log ago. 投票するためにはログインが必要です。 次として送信する: キャンセル
Raymond Gardner Kieran Brady 12年 前 Hi Ray,I am new to Liferay so, please forgive my naiveness.All I see happening here is a red colored border being wrapped around the start.jsp output. That is great if your objective is this simple.How do you change the guts of a jsp using this method? Do we have to parse the html variable and seek out places to add and places to replace?I'm somewhat lost. 投票するためにはログインが必要です。 次として送信する: キャンセル Sergio Sánchez Raymond Gardner 12年 前 I guess that is the case, to modify the markup generated by the core JSP file.I think that could be useful for small modifications like deleting some tags (if we want to disable some functionality an there are not any other menas to do that)If we want to change a lot the behaviour of the core JSP file, wouln't it be better to modify the JSP file as we were doing until now?Also, another use case could be to attach custom JSP code before or after the core JSP code. In that case this new tag could be very useful.Am I right? 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé Sergio Sánchez 12年 前 You're right on both counts... I wasn't saying that this is the only way, just another method to add to your toolbox. The Liferay methodology is to use the solution that is the cleanest for the current problem. There are no one size fits all solutions. Otherwise, we'd have all been out of a job log ago. 投票するためにはログインが必要です。 次として送信する: キャンセル
Sergio Sánchez Raymond Gardner 12年 前 I guess that is the case, to modify the markup generated by the core JSP file.I think that could be useful for small modifications like deleting some tags (if we want to disable some functionality an there are not any other menas to do that)If we want to change a lot the behaviour of the core JSP file, wouln't it be better to modify the JSP file as we were doing until now?Also, another use case could be to attach custom JSP code before or after the core JSP code. In that case this new tag could be very useful.Am I right? 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé Sergio Sánchez 12年 前 You're right on both counts... I wasn't saying that this is the only way, just another method to add to your toolbox. The Liferay methodology is to use the solution that is the cleanest for the current problem. There are no one size fits all solutions. Otherwise, we'd have all been out of a job log ago. 投票するためにはログインが必要です。 次として送信する: キャンセル
Ray Augé Sergio Sánchez 12年 前 You're right on both counts... I wasn't saying that this is the only way, just another method to add to your toolbox. The Liferay methodology is to use the solution that is the cleanest for the current problem. There are no one size fits all solutions. Otherwise, we'd have all been out of a job log ago. 投票するためにはログインが必要です。 次として送信する: キャンセル
(あなた) 11年 前 [...] Basically you can't: http://www.liferay.com/community/forums/-/message_boards/message/14269385 BUT, if you take a look here: http://www.liferay.com/web/raymond.auge/blog/-/blogs/jsp-include-buffer... [...] Read More 投票するためにはログインが必要です。 次として送信する: キャンセル
Hari babu 10年 前 Hi Ray, Thanks for the post. The code that you mentioned under section "From a Velocity Template" is not working in Liferay CMS Templates. because I only see the red border with the following text " ${pageContext.findAttribute('html')}" displayed, instead of the actual start.jsp output.Also I unchecked the "Cacheable" checbox of CMS template to have the http-request available to CMS template.Request you to please help me here...Thanks,Hari. 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé Hari babu 10年 前 Ok, the issue is that CMS template don't have access to "true" request/response/pageContext as a JSP or theme template has.So this context variable: $pageContext does not exist. 投票するためにはログインが必要です。 次として送信する: キャンセル Luca Orlandi Ray Augé 9年 前 So how can i achieve this in vm? 投票するためにはログインが必要です。 次として送信する: キャンセル
Ray Augé Hari babu 10年 前 Ok, the issue is that CMS template don't have access to "true" request/response/pageContext as a JSP or theme template has.So this context variable: $pageContext does not exist. 投票するためにはログインが必要です。 次として送信する: キャンセル Luca Orlandi Ray Augé 9年 前 So how can i achieve this in vm? 投票するためにはログインが必要です。 次として送信する: キャンセル
Nabil Bahtat 10年 前 Hi Ray,I used what you suggest but I got an error stackoverflow when I tryto manipulate the resulting html string in order to add some specific code. For example, when I search a string in html var using stringutil.contains or html.indexof, I got an java.lang.StackOverflowErrorThanks for your helpNabil 投票するためにはログインが必要です。 次として送信する: キャンセル