On Tue, Feb 24, 2009 at 1:54 AM, David E Jones <david.jo...@hotwaxmedia.com>wrote:
> > For the most part we'd only want to accept "safe" HTML, but it is certainly > conceivable to need something more open/flexible/etc. It might be good to > have two service defs (both can call the same service impl), with names to > denote the difference, ie a suffix of "SafeHtml" and "AnyText" for the > other. > > As for storing JSON strings... it sounds a bit odd. The Content stuff is > really meant for content that is written and read by humans. I do agree the > above change would be good, but perhaps there is also a better place to > store your JSON strings (ie it sounds a little bit "hackish"... ;) ). That is an interesting thought and it would solve my problem. The JSON string is a complete representation of an online test (takes too long to build it on-demand), but it will not be read directly by humans. Thanks again for a simple and pragmatic solution to my problem and shedding new light on CMS philosophy. -Al > > -David > > > > On Feb 23, 2009, at 10:20 PM, Al Byers wrote: > > I am storing a very large JSON string in the database using the CMS. Am I >> right in understanding that because the createTextContent service does not >> have an "allowHtml" attribute on the textData field set to "none" that in >> ModelService.validate method it is the >> StringUtil.checkStringForHtmlStrictNone call that is encoding the double >> quotes that are in the string? >> >> What would setting allowHtml to "safe" do? Still encode? >> >> If this is the case, do we have any options other than writing different >> versions of content persisting services to handle the case where we do not >> want encoding to happen? >> >> -Al >> > >
