TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Navigation/Menu structure based on the application
  • While i'm still working on Hanami, this can into my mind:

    We all use docblocks in the controller files, so why didn't use them for navigation item explanation.

    For example:


    <?php

    class Blog_Controller extends Controller {
    /**
    * Displays all articles
    */
    public function index() {}

    /**
    * Displays a specific article
    */
    public function article($id) {}
    }


    Based on that, i would like to generate something like this using reflection:


    • <?php __('Blog index page') ?>


      <?php __('Displays all articles') ?>



    • <?php __('Blog article page') ?>


      <?php __('Displays a specific article') ?>




    This is combined with a js sortable functionality in the end.


    But my problem is, that the blog_controller of the admin app is loaded instead of the front app, which i want. How can i load the frontend app blog_controller? Another question is, how can i set the admin app on top of the front app and modules?
  • Funny you should mention that! I'm just in the process of finishing a module/project I was working on last year that does something very similar, and is about 80% done.

    It's basically a resource kit to set up config-driven navigation for your Kohana site.

    It consists of 2 parts:

    1. Setup

    - a front-end GUI that scans your controllers folder and returns a hierarchical tree of routes - using the same GUI you can then reorder nodes within groups using drag and drop, and give user-friendly menu names to controllers and methods - the final structure is converted into a static configuration file 2. Live - a core set of classes read the configuration file and output location-aware standards-compliant menu HTML - class methods allow different levels of depth from single choices to full site maps, eg $nav->menu(), or $nav->tree(3) - menu items can also be added or removed programmatically, eg $nav->insert('/admin', $items) - multiple configuration files can be read to build the structure, for example user.cfg and admin.cfg - base classes concentrate on generic core methods in order to be easily extended

    It uses a system of fallbacks to determine menu names: Javadoc, previous configs, controller name.

    Approximate ETA of 4 - 6 weeks I would say, assuming my nexy Kohana project starts in the next week or so.

    Is that the sort of thing you were talking about? Dave

  • Well i think this goes in the same direction.

    I would like to read the structure from the exisiting controllers through the main app and the activated modules.

    So you read the directories manually to catch something like

    controllers
    + blog.php
    + forum
    + index.php
    + categories.php
    ...

    Maybe in addition later on you can merge them with static pages. Till now i havn't think of manipulating the navigation programmatically. My storage solution should be a nested set. Maybe a config file is good, too.
  • Yeah, that's pretty much it.

    I didn't use reflection, I used recursion and regular expressions to get all the data, but the result is the same.

    My problem was, as usual, scope creep! I was doing a lot of css-background image headers at the time for my HTML sites, so it seemed a no-brainer to introduce automatic menu-text images, but next thing I know I'm getting involved in a text > image module, a CSS generation module, the front end for both of them, an integrated overall front end, all the HTML, CSS, forms and options, needed to present everything nicely and provide enough flexibility, usability issues, etc, etc.

    Task #1 will be to revisit the project and release the core code and think about the fancy stuff for version 2!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion