sfMenuGeneratorPlugin - 0.1.2
Generates simple menus with no style.
You are currently browsing
the website for symfony 1
Generates simple menu structures.With credential management. Highly configurable through app.yml and module.yml
|Jose Zarate||lead||moc.liamg <<ta>> etarazj|
Copyright (c) 2008 Jose Zarate (Markhaus)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Simple menu structure generator.
Easily configurable through .yml files
advanced module.yml overriding
No fancy behaviors
Just plain old html!
symfony plugin-install http://plugins.symfony-project.com/sfN1IterationPlugin
Configuration at 'app.yml' and 'module.yml'
all: ... ... sf_menu_generator: root: text: 'Choose' items: [contacts](users,) contacts: text: 'Contacts' deny: [contenteditor](manager,) users: text: 'Users Menu Node' link: 'users/list' items: [newuser, modifyuser](listusers,) allow: [admin] listusers: text: 'User List' link: 'users/list' newuser: text: 'New user' link: 'users/new' modifyuser: text: 'Modify user' link: 'users/modify'
Use of the helper
The plugins use 'menu items' defined in app.yml or module.yml.
These items are not defined hierarchically. Instead of that each menu item has an items sections which refers to the other menu items that are to be considered childs.
Each menu item is defined as follows:
itemName: text: 'text to show' link: 'link to be fed into link_to()' items: [subitem2](subitem1,) allow: [credential2](credential1,) deny: [credential4](credential3,) html_id: 'idItem' html_style: 'float:left;color:#FF00FF;' html_class: 'mypersonalclassname' a_id: 'idAItem' a_target: 'blank'
text: this is the text meant to be inside the li element. Can be anything, even html tags. Not mandatory.
link: this is the link the menu item will point to. it's not mandatory if nothing is set, then an '#' is generated.
items: this is an array of the menu items (defined just like this one elsewhere in the yml file) which are supposed to be the childs of this one.
allow: Array of the credentials a user must have to view this particular item . If none is given , 'any' wildcard is assumed .
deny: Array of the credentials a user must not have to view this particular item. If there is collision between this parameter and the allow parameter, the most resctrictive approach is taken.
a_*: attributes for the "a" tag. can be anything .
html_*: attributes for the "li" tag.
If no 'html_class' is providen, the "li" tags have the class="mg node_
If there is an 'html_class' parameter, then the "li" tag will have that class name, plus "node_
user: text: 'Users' html_class: 'soft' will generate .. ... <li class="soft node_user"> .... <a ..>Users</a> </li>
The helper will read its configuration from both app.yml and module.yml.
Items can be defined in both files.
user: text: 'users' items: [user2](user1,) user1: text: 'user1'
user2: text: 'user2'
As you see in the previous example, you can use child items that are defined elsewhere.
In case of overlapping, the module.yml definitions have precedence.
user: text: 'user from the root menu' items: [user2](user1,) ..
user: text: 'user from the module'
is equivalent to:
user: text: 'user from the module' items: [user2](user1,)
Overlapping the items, allow and deny section
Regarding the 'items' , 'allow' and 'deny' sections, special rules apply when there is overlapping. The syntax is similar to the one used on stylesheets section of view.yml.
The items|allow|deny section defined for an overlapping menu item at module.yml file are added to the items|allow|deny section defined at the app.yml configuration file.
If there is a '-' prefix for one of the elements of the items|allow|deny array, then that element is removed from the childs.
The special '-' instructs to remove all the elements that are already defined at the *items|allow|deny section , at the moment the parser reads that special character. (The following elements are not affected).
so, if we have these two overlapping menu items:
user: ... items: [user2, user3, user4](user1,) allow: [cred2](cred1,)
user: items: [-user2](user5,) deny: [cred2]
user: items: [-*,user6] allow: [-cred1]
In module1.yml, the 'user5' child will be added, and the 'user2' will be removed. The 'cred2' credential is denied
In module2.yml all the childs defined in app.yml will be removed, and the 'user6' child will be added. The cred1 is no longer allowed
The helper is fairly simple to use:
The first argument is an array with the menu nodenames, as they are defined and discussed in the previous section.
The second argument are html attributes to pass to the main "ul" tag of the menu.