The Grails Config.groovy setting grails.views.default.codec specifies the default codec used to encode data within ${...} in Grails views.
This config setting can take any of the values none (no filtering required), html (to avoid XSS-attacks) and base64 (has no real-world use-case that I know of).
The Grails default is none (no filtering).
Questions:
Are there any compelling technical reasons not to use the safer option "html"?
When do you choose to go with the default option of "none" in your Grails projects?
A question on similar topic here.. I don't claim big expertise on this, but I imagine. Why it's not html by default is strange to me. I found GRAILS-2945, where this was proposed but ultimately rejected, without too much explanation. There is also some more information in GRAILS-1827, when the issue was first implemented.
Related
As I have asked questions in this form - thanks for your many helpful answers - i have found many really neat things that one can do using ExtLibUtil.???? however, other than a bit here and a bit there I have not found anything that gives a listing on the various functions. I one post I read that it is all in the source of the extension Library, and it might be if you really understand where in the source to look. Sure would appreciate a pointer and starting point.
I've been unable to find a JavaDoc for it. The library slipped passed us when we wrote the book - certainly I was not as au fait with Java to be aware of it and all the strength within it. So the best option currently is to look at the source code in Eclipse. Many of the methods are helper methods to easily access things like viewScope etc, which is easy from SSJS but less easy from Java. Most are pretty self-explanatory.
Content assist doesn't seem to work from SSJS, but will from any Java class or, alternatively, open up one of the Java classes created for XPages / Custom Controls under the "local" package in Package Explorer, type "ExtLibUtil." in any method and you'll see the list.
I want to send log messages to several files (i.e. different appenders) based upon some property of the message.
The problem is that each appender needs to specify quite a verbose layout (that contains a compication conversionPattern and a couple of converters). I have ended up duplicating this configuration in each appender. This works but is not ideal as it makes the config much longer than I would like as well as the pain of having to update 3 complicated bit of configuration when the layout changes.
I want to be able to define the layout once and have all my appenders refer back to that one definition (in the same way that several loggers can refer to the same appender). But perhaps there is a better way to achieve my goal of reducing duplication in the configuration?
My google-foo is weak and I could not find an answer. Can anyone here help?
TIA.
I am sorry but unless you are ready to code your own Layout class there is currently no way to skip on the copy-pasted configuration.
You can inherit from the LayoutSkeleton to get started, and either build your layout in code or use an alternate configuration file (I don't think that log4net would be kind to a dangling layout configuration in its config file)
I'm relatively new to Expression Engine, and as I'm learning it I am seeing some stuff missing that WordPress has had for a while. A big one for me is shortcodes, since I will use these to allow CMS users to place more complex content in place with their other content.
I'm not seeing any real equivalent to this in EE, apart from a forthcoming plugin that's in private beta.
As an initial test I'm attempting to fake shortcodes by using delimited strings (e.g. #foo#) in the content field, then using a regex to pull those out and pass them to a function that can retrieve the content out of EE's database.
This brings me to a second question, which is that in looking at EE's API docs, there doesn't appear to be a simple means of retrieving the channel entries programmatically (thinking of something akin to WP's built-in get_posts function).
So my questions are:
a) Can this be done?
b) If so, is my method of approaching it reasonable? Or is there something stupidly obvious I'm missing in my approach?
To reiterate, my main objective here is to have some means of allowing people managing content to drop a code in place in their content that will be replaced with channel content.
Thanks for any advice or help you can give me.
Here's a simple example of the functionality you're looking for.
1) Start by installing Low Replace.
2) Create two Global Variables called gv_hello and gv_goodbye with the values "Hello" and "Goodbye" respectively.
3) Put this text into the body of an entry:
[say_hello]
Nice to see you.
[say_goodbye]
4) Put this into your template, wrapping the Low Replace tag around your body field.
{exp:low_replace
find="[say_hello]|[say_goodbye]"
replace="{gv_hello}|{gv_goodbye}"
multiple="yes"
}
{body}
{/exp:low_replace}
5) It should output this into your browser:
Hello
Nice to see you.
Goodbye
Obviously, this is a really simple example. You can put full blown HTML into your global variable. For example, we've used that to render a complex, interactive graphic that isn't editable but can be easily dropped into a page by any editor.
Unfortunately, due to parse order issues, EE tags won't work inside Global Variables. If you need EE tags in your short code output, you'll need to use Low Variables addon instead of Global Variables.
Continued from the comment:
Do you have examples of the kind of shortcodes you want to support/include? Because i have doubts if controlling the page-layout from a text-field or wysiwyg-field is the way to go.
If you want editors to be able to adjust layout or show/hide extra parts on the page, giving them access to some extra fields in the channel, is (imo) much more manageable and future-proof. For instance some selectfields, a relationship (or playa) field, or a matrix, to let them choose which parts to include/exclude on a page, or which entry from another channel to pull content from.
As said in the comment: i totally understand if you want to replace some #foo# tags with images or data from another field (see other answers: nsm-transplant, low_replace). But, giving an editor access to shortcodes and picking them out, is like writing a template-engine to generate ee-template code for the ee-template-engine.
Using some custom fields to let editors pick and choose parts to embed is, i think, much more manageable.
That being said, you could make a plugin to parse the shortcodes from a textareas content, and then program a lot, to fetch data from other modules you want to support. For channel entries you could build out of the channel data library by objectiveHTML. https://github.com/objectivehtml/Channel-Data
I hear you, I too miss shortcodes from WP -- though the reason they work so easily there is the ubiquity of the_content(). With the great flexibility of EE comes fewer blanket solutions.
I'd suggest looking at NSM Transplant. It should fit the bill for you.
There is also a plugin called Shortcode, which you can find here at
Devot-ee
A quote from the page:
Shortcode aims to allow for more dynamic use of content by authors and
editors, allowing for injection of reusable bits of content or even
whole pieces of functionality into any field in EE
Does anyone have a link to a concise summary of what makes a portlet "JSR-286 compliant" vs being only "JSR-168 compliant". I've got a copy of the spec and that's anything but concise so linking the spec is not a useful answer. I've searched the web for an hour now and I've found nothing that is clear (aside from the spec, which of course requires that you read the previous spec too, and then weed out the "new features" from the "required compliance".
Particularly I've found that there's quite a bit of confusion out there on the necessity of web.xml, which appears to come from people using Liferay and not realizing that Liferay is dropping in a web.xml for them.
Do JSR-286 portlets require a web.xml file in their WAR files?
What I'd really like is something that contains one or more of the following lists:
Things you have to do to a JSR-168 to make it become JSR-286 compliant
Things you must not do, that would cause an otherwise JSR-286 compliant portlet to be considered only JSR-168.
You can leave "use the portlet-app_2_0.xsd" off the list, as I consider that part obvious.
I'm open to the answer that both lists are empty aside from the DTD/xsd for portlet.xml, and the difference is only in what the portal supports, but please back that assertion up with a link or other reference.
The reason I care is I see posts about Vaadin portlets in Liferay that imply that some features are not available for JSR-168 portlets... It may also be that some logic in Liferay switches based on which version of portlet.xml it sees, but I haven't confirmed that either so that would be interesting information too, but not the answer to my question.
According to this doc, but it's also mentioned in jsr286:
The JSR 286 spec(Portlet 2.0) does not break binary compatibility with JSR168(Portlet 1.0). This means that all portlets written against the Portlet 1.0 specification can run unchanged. The only exceptions to this rule are:
renderResponse.setContentType is no longer required before calling getWriter or getOutputstream. In JSR168, calling getWriter or getOutputstream without previously setting the content type resulted in an IllegalStateException.
getProtocol for included servlets / JSPs returns ‘HTTP/1.1’, In JSR168, it returned null.
So as long as your jsr168 portlet doesn't depend on the value returned by getProtocol() you're safe (ie every jsr168 portlet is a jsr286 portlet).
The posts you see seem to be logical as jsr286 is a newer spec and there are some features that make jsr268 portlet not a jsr168 portlet.
Ok, Since I've not found anything new that distinguishes a 2.0 portlet from a 1.0 portlet (aside from using additional services and ) I'll begin the lists for my answer here.
Must Do:
Conform to the 2.0 XSD for portlet.xml (xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd")
Must Not Do:
Rely on getWriter throwing an exception if renderResponse.setContentType has not been called yet. (Seems unlikely anyway)
Rely on getProtocol() returning null
The upshot is, if you simply convert your portlet.xml, you are now "286 compliant" unless you relied on the two items in the second list for your program flow. I can't find anything else, but if someone finds another item for these lists, please edit.
I don't often have need for tomahawk components anymore since jsf 2.0 provides great selectOneMenu support and most of other functionality I used to use them for, but when it comes to a selectOneRadio component I don't know of another provider with a layout="spread" option. This is essential from time to time to achieve a certain layout I'm asked for.
I'm using Tomahawk for exactly this purpose but recently discovered some serialization issues caused by this component during failover. I was wondering if anyone has discovered another provider with similar "spread" functionality or if anyone has written/published an alternative based on h:selectOneRadio?
We also wanted to use the "spread" option - in our case for DDA compatibility (no using tables for layout) but for political reasons were unable to use Tomahawk. We ended up writing our own custom renderer for radio buttons and checkboxes.
It wasn't too hard, took me a few hours to get it working the way we wanted. I'm at home for a couple of days without access to the code base so I can't give you the exact code but it's a pretty simple matter of overriding the encodeBegin() and decodeBegin() (or encodeEnd() and decodeEnd() depending on your usecase) methods and writing the html appropriate for your application.