David,
I understand the rationale for the existence of these 2 things ... but
apparently it creates some sort of confusion. I wonder if there is a
way of "unifying" them. I'm thinking that there might be cases where
in order to load views from some endpoint one would have to implement
a TemplatePf and a ViewDispatchPf ... which is some extent may seem
redundant.
Would it make any sense to have ?
type TemplatePf = PartialFunction[(List[String], Req),() => Can
[NodeSeq]]
and even if we are in the middle of processing chunks of templates the
path is provided as well as the initial Req and pattern matching can
still be done. At the first call the List[String] is probably the same
with Req.parsePath.path but I don;t see it as a major inconvenience.
Br's,
Marius
On Dec 5, 6:33 pm, "David Pollak" <[EMAIL PROTECTED]>
wrote:
> On Fri, Dec 5, 2008 at 7:35 AM, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> > > I'd suggest creating a ViewDispatchPF and adding it in using
> > > LiftRules.appendViewDispatch
>
> > > type ViewDispatchPF = PartialFunction[List[String], LiftView]
>
> > > So, it's going to look a lot like your existing code.
>
> > Excuse my ignorance, but what's the difference between TemplatePF and
> > ViewDispatchPF?
>
> type TemplatePF = PartialFunction[Req,() => Can[NodeSeq]]
>
> type ViewDispatchPF = PartialFunction[List[String], LiftView]
>
> As per my exchange with Marius, the TemplatePF is used to map the Req(uest)
> to the NodeSeq that represents the page that satisfies the Req(uest).
>
> However, the initial XHTML may reference other XHTML. Typically, these
> XHTML chunks are templates such as the surround template or perhaps a search
> template. Lift references these XHTML chunks by path, not Req. Thus, there
> must be a way to translate between a path and something to vend the XHTML
> chunks. The ViewDispatch mechanism does this translation. If there is no
> ViewDispatch that can satisfy the path, then Lift looks in the filesystem.
>
> So, what does the LiftView trait look like:
> /**
> * The preferred way to do lift views... implement a partial function that
> dispatches
> * the incoming request to an appropriate method
> */
> trait LiftView {
> implicit def nsToCns(in: NodeSeq): Can[NodeSeq] = Can.legacyNullTest(in)
> def dispatch : PartialFunction[String, () => Can[NodeSeq]]
>
> }
>
> So, your code would look something like:
>
> LiftRules.appendViewDispatch {
> case "templates-hidden" :: Nil => new LiftView {
> def dispatch = {
> case "default" => loadDefaultTemplateFromDB _
> }
>
> def loadDefaultTemplateFromDB(): Can[NodeSeq] = ....
> }
>
> }
>
> There is no documentation on what ViewDispatch is
>
> > actually for - my understanding of "views" within lift, were
> > dynamically generated stuff like XML RSS feeds or such. Is this not
> > the case?
>
> No. A "view" is XHTML used to render a page to the browser. XML and RSS
> feeds are handled using an entirely different mechanism.
>
>
>
> > Im confused as to what this has to do with my use case?
>
> > Cheers
>
> > Tim
>
> > PS: sorry if this appears like im being very slow!
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Collaborative Task Managementhttp://much4.us
> 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
-~----------~----~----~----~------~----~------~--~---
