While that might make for nice default breadcrumbs, it wouldn't be
expressive enough for all use cases. I think we should reserve indentation
to indicate route nesting:
/posts PostsR
/#Int PostR
/comments CommentR
On Thu, Jun 9, 2011 at 4:02 PM, Eric Schug
There seems to be much redundant information created within the Yesod structure. One place to define the routes Another place defines the route hierarchy for breadcrumbs with titles. A third place defines, but not integrated into Yesod, defines use menus (usually similar hierarchy and titles).
Would it be possible to have all of this defined into one place, by extending the routes definition using white space hierarchy similar to hamlet definition. and optionally include Title name.
-- Example config/routes /static StaticR Static getStatic /favicon.ico FaviconR GET /robots.txt RobotsR GET / RootR GET "Home" /contact ContactR GET "Contact Us" /services ServicesR GET "Our Services" /services/stuffwedo StuffWeDoR GET "Stuff We Do"
The resource list would be expanded to include this hierarchy. Something like Resource String < http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/Data-Char.html#t:String> [Piece < http://hackage.haskell.org/packages/archive/web-routes-quasi/0.6.3/doc/html/Web-Routes-Quasi-Parse.html#t:Piece>] [String < http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/Data-Char.html#t:String>] String Maybe String
From this a breadcrumb could be build from a maker (if desired).
mkYesodData "Example" $(parseRoutesFile "config/routes") mkYesodBreadcrumbs "Example" resourcesExample -- creates breadcrumbsExample
and a hierarchy useful for building Menus
mkYesodHierarchy "Example" resourcesExample -- creates a nested table of (Route, Html) pairs
The menu list could also be pulled from the data, with possible few options.
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel