> On traditional website structures, there is usually a separate placed > meta-navigation menu containing contact data, about pages, terms of > use, etc. This could be easily generated with > > {menu: {used_nodes: files, start_level: 1, max_levels: 1}} > > While the main menu would be generated with > > {menu: {used_nodes: directories, start_level: 1, max_levels: 1}} > > Without this, the meta-navigation menu would have to be typed > manually.Thanks for the suggestions! However, since I plan to redesign how the menu is generated, I will probably not implement the directories value. The new mode of operation will then allow complete control over the nodes included in a menu and its representation. Ie. it will also be possible to specify more than one menu! Since I will have now more time again I hope that I will also find more time for webgen development. The next release will probably be out in the next one or two weeks.> Further, I noticed that if "used_nodes" is omitted in a menu tag, then > the meta information setting "in_menu: false" will be ignored and > everything is visible in the menu. Is this intentional behavior?If you leave out the "used_nodes" key, the default value for it is taken which is "all". This means that fragments are also shown in the menu and since fragments are generated automatically by default via the fragments content processor, all files that have fragment nodes will show up in the menu! -- Thomas
Hi,
I want to suggest an extension for the "used_nodes" option of the menu
tag. Currently, there are the options "all", "files" and
"fragments"
implemented. What about distinguishing "files" and
"directories"? This
would come in handy with traditional website structures. Example:
|-folder1
| |- index.page
|
|-folder2
| |- index.page
|
|-about.page
|-contact.page
|-index.page
On traditional website structures, there is usually a separate placed
meta-navigation menu containing contact data, about pages, terms of use,
etc. This could be easily generated with
{menu: {used_nodes: files, start_level: 1, max_levels: 1}}
While the main menu would be generated with
{menu: {used_nodes: directories, start_level: 1, max_levels: 1}}
Without this, the meta-navigation menu would have to be typed manually.
Further, I noticed that if "used_nodes" is omitted in a menu tag, then
the meta information setting "in_menu: false" will be ignored and
everything is visible in the menu. Is this intentional behavior?
Thanks,
Michael
Thomas Leitner wrote:> Thanks for the suggestions! However, since I plan to redesign how the > menu is generated, I will probably not implement the directories value. > The new mode of operation will then allow complete control over the > nodes included in a menu and its representation. Ie. it will also be > possible to specify more than one menu!> Since I will have now more time again I hope that I will also find more > time for webgen development. The next release will probably be out in > the next one or two weeks.Great news! Webgen has proven to me as an indispensable tool for rapid web-development. With its collection of content processors in one place (my favorites being haml, sass and maruku) and its template engine, it allows for really flexible solutions for lots of different website purposes! Since I actually earned money with webgen, I''ve donated a small amount also to you for balance. Thanks for webgen and keep it up!> If you leave out the "used_nodes" key, the default value for it is > taken which is "all". This means that fragments are also shown in the > menu and since fragments are generated automatically by default via the > fragments content processor, all files that have fragment nodes will > show up in the menu!Well, when an ''invisible'' default value overrides a ''visible'' "in_menu: false", that''s a bit counterintuitive IMO. I had to dig hard to find that one out! Another suggestion: What about including a postprocessor for pretty HTML formatting? See http://raa.ruby-lang.org/project/tidy Thanks, Michael
> Since I actually earned money with webgen, I''ve donated a small > amount also to you for balance. > > Thanks for webgen and keep it up!Thanks!!!> > If you leave out the "used_nodes" key, the default value for it is > > taken which is "all". This means that fragments are also shown in > > the menu and since fragments are generated automatically by default > > via the fragments content processor, all files that have fragment > > nodes will show up in the menu! > > Well, when an ''invisible'' default value overrides a ''visible'' > "in_menu: false", that''s a bit counterintuitive IMO. I had to dig > hard to find that one out!Yeah, that''s really a bit counterintuitive. I think the best ''solution'' to this is to set the default to ''files'' for the time being?!> Another suggestion: What about including a postprocessor for pretty > HTML formatting? See http://raa.ruby-lang.org/project/tidyShould be easy to do, will look at it. Best regards, Thomas
Am Fri, 03 Jul 2009 19:52:15 +0200 schrieb Michael Franzl <michaelfranzl at gmx.at>:> > Yeah, that''s really a bit counterintuitive. I think the best > > ''solution'' to this is to set the default to ''files'' for the time > > being?! > > This would help for the time being IMO.Hmm... I just realized that this change would lead to a big problem: *all* current sites which do not specify the used_nodes options in the menu tag itself will work differently which is not really that good... So I''m inclined to leave the default as it is...> Another question: > > I noticed the depreciation warning that the object "node" will be > replaced with "context.node". Well, at least in my experience with > webgen, "node" is frequently used in templates for doing page > specific things -- like excluding a sidebar when a certain metainfo > value is set. > > Would it be possible to create an short alias for "context.node", > like "n", for the sake of ''cleaner'' template code?Certainly possible, but not very descriptive! If you find yourself using `context.node` very often in a template, you could just do `n context.node` at the beginning of the template. In the last releases I have actually deprecated all short forms (node, ref_node, ...) because I wanted to have one object, the context object, to hold all the needed information. Also note that in the next version of webgen, the context object will be much more powerful since it will provide easy access to render nodes via the blocks content processor and to render tags via the tag content processor! -- Thomas
> Yeah, that''s really a bit counterintuitive. I think the best ''solution'' > to this is to set the default to ''files'' for the time being?!This would help for the time being IMO. Another question: I noticed the depreciation warning that the object "node" will be replaced with "context.node". Well, at least in my experience with webgen, "node" is frequently used in templates for doing page specific things -- like excluding a sidebar when a certain metainfo value is set. Would it be possible to create an short alias for "context.node", like "n", for the sake of ''cleaner'' template code? Michael
> Hmm... I just realized that this change would lead to a big problem: > *all* current sites which do not specify the used_nodes options in the > menu tag itself will work differently which is not really that good... > > So I''m inclined to leave the default as it is...I think a hint in the documentation will do it too.> Certainly possible, but not very descriptive! If you find yourself > using `context.node` very often in a template, you could just do `n > context.node` at the beginning of the template. > > In the last releases I have actually deprecated all short forms (node, > ref_node, ...) because I wanted to have one object, the context object, > to hold all the needed information.Understandable. Then in this case `n = context.node` is good enough!> Also note that in the next version of webgen, the context object will > be much more powerful since it will provide easy access to render nodes > via the blocks content processor and to render tags via the tag content > processor!Will Maruku 0.6.0 also be supported? It seems to be Ruby 1.9 compatible! Michael
> > Hmm... I just realized that this change would lead to a big problem: > > *all* current sites which do not specify the used_nodes options in > > the menu tag itself will work differently which is not really that > > good... > > > > So I''m inclined to leave the default as it is... > > I think a hint in the documentation will do it too.Will do that!> > Also note that in the next version of webgen, the context object > > will be much more powerful since it will provide easy access to > > render nodes via the blocks content processor and to render tags > > via the tag content processor! > > Will Maruku 0.6.0 also be supported? It seems to be Ruby 1.9 > compatible!The next version will recommend Maruku 0.6.0 and this version of Maruku indeed works better on 0.6.0. However, there was a change in how REXML process tags with namespaces which affects Maruku: it isn''t possible now to use HTML/XML tags with namespaces in Maruku markup! Since webgen uses namespaced XML tags for some features (for example, <webgen:block />) this is very bad... I haven''t found out how to nicely parse an XML document with namespaces that have not been specified beforehand with REXML under 1.9 without resorting to some hacks. -- Thomas