I think I am aware what you meant ... If you want to make SiteMap to
know how to render itself as <ul>/<li> hence "centralize" this fine by
me. I have nothing against it, I just don't see the need ... the good
news is that it may be just me ;)

The analogy with chooseTemplate is not very relevant IMHO because
choseeTemplate is a construct that one can use in many application
context whereas SiteMap is typically only one. But by all means don't
let me stay in your way:)

If you are implementing this in SIteMap then perhaps you should make
both Menu built in snippet and MenuWidget to use it?

Br's,
Marius

On Mar 21, 5:41 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> Sorry, what I mean is that the builtin Menu snippet code is duplicated, not
> SiteMap. For instance, here's how the builtin snippet generates the ULs:
>
>     S.request.map(_.buildMenu.lines.toList match {
>         case Nil => List(Text("No Navigation Defined."))
>         case xs =>
>           val liMap = S.prefixedAttrsToMap("li")
>           val li = S.mapToAttrs(liMap)
>
>           def buildANavItem(i: MenuItem) = {
>             i match {
>               case MenuItem(text, uri, kids, true, _, _) =>
>                 (<li><span>{text}</span>{buildUlLine(kids)}</li>) %
> S.prefixedAttrsToMetaData("li_item", liMap)
>               case MenuItem(text, uri, kids,  _, true, _) =>
>                 (<li><a href={uri}>{text}</a>{buildUlLine(kids)}</li>) %
> S.prefixedAttrsToMetaData("li_path", liMap)
>               case MenuItem(text, uri, kids, _, _, _) =>
>                 (<li><a href={uri}>{text}</a>{buildUlLine(kids)}</li> % li)
>             }
>           }
>
>           def buildUlLine(in: Seq[MenuItem]): Node = if (in.isEmpty)
> Text("")
>           else <ul>{in.flatMap(buildANavItem)}</ul> %
>           S.prefixedAttrsToMetaData("ul")
>
>           buildUlLine(xs)
>
>       })
>
> And here's the new code you put together:
>
>   private def buildMenu(kids: Seq[MenuItem]): Elem = {
>     <ul>{
>       for (m <- kids) yield {
>         <li>{
>           <a href={m.uri}>{m.text}</a> ++ (m.kids.isEmpty match {
>             case true => NodeSeq.Empty
>             case _ => buildMenu(m.kids)
>           })
>         }</li>
>       }
>     }</ul>
>   }
>
> What you've written is very similar, albeit without some of the attribute
> handling, etc. I was just saying that if someone else comes along and finds
> a need for fully expanding SiteMap into nested ULs, then they have to write
> similar code again. It's a fairly small snippet of code, but I don't know
> that that's really an argument against providing it as a general mechanism.
> I mean, chooseTemplate is just a few lines, but we include it because it's
> useful. I would be happy to make changes to the builtin Menu snippet on a
> new branch to show what I mean if you'd like.
>
> Derek
>
> On Sat, Mar 21, 2009 at 8:22 AM, marius d. <marius.dan...@gmail.com> wrote:
>
> > Similar approach yes, duplicate not quite. It just utilizes that the
> > API provided by SiteMap, MenuItem etc. and walks through a tree
> > structure and build <ul>/<li> constructs.
>
> > We could make the SiteMap to be self aware of rendering itself to <ul>/
> > <li> constructs but personally I don't really see this as being
> > necessary. Nonetheless if there are compelling reasons to do so I'd
> > like to know them. ... I like things do be decoupled and SIteMap is
> > expressive enough to represent it in so many ways,
>
> > Br's,
> > Marius
>
> > On Mar 21, 3:51 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> > > Awesome! It looks like you did end up having to essentially duplicate the
> > > code in the builtin Menu.builder snippet method to get this working. When
> > I
> > > was looking at it I thought that it might be nice to have a general way
> > of
> > > making the builtin Menu snippet just render the whole tree in case anyone
> > > else wants to use it (for a site navigation page, etc). I was thinking
> > that
> > > we could add an optional parameter that would essentially do that, then
> > you
> > > could just have the snippet look like:
>
> > > <lift:Menu.builder expandAll="true" />
>
> > > Or something. I suppose it's a pretty small chunk of code, but if someone
> > > else wants to do something similar it means they have to copy it all
> > over.
>
> > > Thoughts?
>
> > > Derek
>
> > > On Sat, Mar 21, 2009 at 3:44 AM, Marius <marius.dan...@gmail.com> wrote:
>
> > > > Folks,
>
> > > > I just committed the menu widget. Now the Widgets test site uses this
> > > > widget instead of the traditional builtin menu. You can also specify
> > > > the style of the menu using MenuStyle.HORIZONTAL,  MenuStyle.VERTICAL
> > > > and  MenuStyle.NAVBAR.
>
> > > > All these thanks to superfish jquery plugin
> > > >http://users.tpg.com.au/j_birch/plugins/superfish/
>
> > > > Oh you can also customize the superfish plugin by specifying the JsObj
> > > > to set the properties.
>
> > > > Thoughts/suggestions ?
>
> > > > Br's,
> > > > Marius
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to