Yesod: unifying breadcrumbs and routes
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.
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 <schugschug@gmail.com> wrote:
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
I agree that defining breadcrumbs separately is an annoying, tedious process. But the fact is that it's a necessary tediousness. It's very rare that you could determine the title or parent that easily for every route. Take the simple example of a blog with multiple authors: / RootR GET /author/#AuthorId AuthorR GET /post/#PostId PostR GET The title for AuthorR and PostR will both need to be looked up from the database, and the parent page for PostR will also require a DB lookup. (You could restructure your URLs to avoid that, but that's not my point here.) Michael On Fri, Jun 10, 2011 at 2:02 AM, Eric Schug <schugschug@gmail.com> wrote:
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
participants (3)
-
Eric Schug -
Greg Weber -
Michael Snoyman