On Dec 5, 8:11 pm, "David Pollak" <[EMAIL PROTECTED]>
wrote:
> On Fri, Dec 5, 2008 at 9:56 AM, Marius <[EMAIL PROTECTED]> wrote:
>
> > 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]]
>
> No.  There are a bunch of problems with this:

I was kind of hoping so ...

>
>    - The Req is not always around, so you'd have to have have to have
>    Can[Req] and then the whole pattern matching thing becomes ugly and 
> unweildy
>    - Even without the Can[Req], there's a lot of cruft in the pattern
>    - The goals are slightly different.  TemplatePF returns a Can[NodeSeq],
>    where ViewDispatchPF returns a LiftView.  LiftView is used elsewhere.
>
> If anything, I'd opt for getting rid of TemplatePF all-together.  But, last
> time I tried that, there were a bunch of things that stopped working.  I may
> be able to overcome those issues with some recent additions to Loc.

Well if we'd get rid of TemplatePf we might as well use ViewDispatchPF
where  based on the Request URI path and have a single place to handle
this.

If you want me to start looking into this, please let me know.

>
>
>
> > 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.
>
> Actually, the Req is not passed around, so it's not always available.
>
>
>
>
>
> > 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
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to