To quote David from a previous thread on the mailing list:
> I've enhanced LiftRules as follows:
>
> /**
> * A partial function that determines content type based on an
> incoming
> * RequestState and Accept header
> */
> var determineContentType:
> PartialFunction[(Can[RequestState], Can[String]), String] = {
> case (_, Full(accept)) if
> accept.toLowerCase.contains("application/xhtml+xml") =>
> "application/xhtml+xml"
>
> case _ => "text/html"
> }
>
> You can change the determineContentType Partial Function in Boot.scala
> to accomplish your goals.
So maybe you could add in Boot.scala
determineContentType = {
case (Full(req), _) if req.path match {
case "text" :: "only" :: _ => true
case _ => false} => "text/html"
} orElse determineContentType
which would set the return type of any page under and including "/text/
only" to "text/html" and if not under that would chain to the standard
lift content type determine partial function...
Obviously you could define your own function to check the path rather
than in-line it...
David: Would req.param("x") be the equivalent to S.param("x") ??
Regards,
Marc
On 17/03/2009, at 2:58 PM, David Pollak wrote:
>
>
> On Mon, Mar 16, 2009 at 8:51 PM, Jeremy Mawson <[email protected]
> > wrote:
> Thanks Marc. <xml:group> works nicely.
>
> For this exercise this is hypothetical, but it matches very closely
> a project I have enabled in the past using struts and JIBX...
>
> Say the data was sourced from an external party's service and there
> was a contractual agreement to not alter the data in any way? I.E.
> I'm stuck with the poorly formed HTML. Probably one could agree with
> the partner that the transformation to valid XHTML is appropriate,
> but I'll let the question stand anyway.
>
> Is poorly formed (but otherwise supported-by-browsers) HTML
> renderable via Lift at all?
>
> If it's supported by the browser, it will be rendered, but Firefox
> and Chrome will both complain about malformed XHTML.
>
> You could run the String through an HTML parser (there are a few
> floating around for Java that will parse poorly formed HTML) and
> then walk the nodes and build XML. I would argue that this would
> satisfy any contractual requirements, although I no longer practice
> law, so I can't argue it on your behalf. :-)
>
>
>
> Cheers
> Jeremy
>
>
>
> 2009/3/17 Marc Boschma <[email protected]>
>
>
> On 17/03/2009, at 12:36 PM, Jeremy Mawson wrote:
>
>> If I change the line to "description" ->
>> <span>{Unparsed(result.description)}</span>, it compiles but I have
>> an unwanted span tag and worse ... if result.description is not
>> well formed XML my page will fail to render! Firefox complains of
>> an XML Parsing Error. The description field has an unmatched <br>
>> tag (literally <br>) in the middle of it to force it onto two
>> lines.
>>
>
> Try "description" -> <xml:group>{Unparsed(result.description)}</
> xml:group>
>
> That wraps the string in a scala XML group node...
>
> With respect to the <br> tag, it should be <br/> or <br></br> to be
> well formed. If you want to support non-well formed XML fro the
> database wouldn't you need to parse it and convert it to well formed
> first or upon retrieval ?
>
> Regards,
>
> Marc
>
>
>
>
>
>
> --
> Jeremy Mawson
> Senior Developer | Online Directories
>
> Sensis Pty Ltd
> 222 Lonsdale St
> Melbourne 3000
> E: [email protected]
>
>
>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
