Thread

@kilishan - Will definitely do that.

Right now trying to tweak thing to use the Auth library for client log in. This is a full fledged store front that has an optional membership. That means I need to find a way to access the members name (not the email address), for a “Hello, Mr. X” message if they log in, and a way to allow the public to create their own accounts without administrative intervention. I’ve had to create a Semiauthenticated_Controller class that differs by only omitting the $this->auth->restrict(); line. The Authenticated_Controller class forces a log in which wouldn’t do on the home page, yet I need a log in ability on that front page. Logging out is simple enough as is logging in an existing user. Trying to get their name and creating a safe, public method of account creation isn’t as trivial yet.

Edit: Oh, yeah. Found the member name function in Auth. 😊

Edit: Oh, wow! My name is now “1”!

i download the latest build and setup it already. But i dont know how to start developing with this.

Can u make some example how to make a new controller, where to put them in and so on….

When creating databases with phpMyAdmin it will default to latin1_swedish_ci

To change when creating the database set your collation!

Or else you will need to click on your database then the Operations tab and at the very bottom change your collation!

InsiteFX

I see in the docs have :

With the exception of the Public context, creating a controller for your module for a specific controller is a simple as naming your controller to match the context.  A controller for the content context, would be named content.php, while one that shows up in the settings context would be named setting.php.  For the public context, the controller should be named the same as the module.  For example, a Pages module would have a public controller called pages.php.

Why i need to do that rules?

When creating databases with phpMyAdmin it will default to latin1_swedish_ci

To change when creating the database set your collation!

Or else you will need to click on your database then the Operations tab and at the very bottom change your collation!

InsiteFX

Yeah, I kind of noticed. That was my first clue about the problem. 😊 Swedish? I think this is of the same nature as Bonfire’s defaulting to Florida as the default State for a member’s address. Clue to the creator’s origin maybe?  😜

@tieungao - You need to study Wiredesignz HMVC system. It’s not required that you use it for Bonfire, but it’s nice to have it. By default Bonfire starts out as the normal CodeIgniter MVC structure. But if you look in Bonfire’s folder structure you will see a “modules” folder. To see this in operation do this. In the modules folder create a folder called “home”. Inside “home” create the the folders “controllers”, “views”, and “models”. Move the home.php file from the application/controllers folder to the modules/home/controllers folder. Point your browser to your Bonfire project. You’ll notice no change, even though the starting controller is now in a completely different folder. Now move the home.php file from the application/views folder to the modules/home/views folder. Notice that, again, there is no change in the final output. If you want to see a simple layout using just CI and HMVC I prepared a simple zip file on my own site you can download. I don’t remember the exact thread I did that for but looking at it’s file structure might help you have a better understanding of the HMVC patttern. HMVC example

@tieungao - You need to study Wiredesignz HMVC system. It’s not required that you use it for Bonfire, but it’s nice to have it. By default Bonfire starts out as the normal CodeIgniter MVC structure. But if you look in Bonfire’s folder structure you will see a “modules” folder. To see this in operation do this. In the modules folder create a folder called “home”. Inside “home” create the the folders “controllers”, “views”, and “models”. Move the home.php file from the application/controllers folder to the modules/home/controllers folder. Point your browser to your Bonfire project. You’ll notice no change, even though the starting controller is now in a completely different folder. Now move the home.php file from the application/views folder to the modules/home/views folder. Notice that, again, there is no change in the final output. If you want to see a simple layout using just CI and HMVC I prepared a simple zip file on my own site you can download. I don’t remember the exact thread I did that for but looking at it’s file structure might help you have a better understanding of the HMVC patttern. HMVC example

First of all, thanks so much for helping me understand with a very clearly instruction about HMVC.

So when u told me that “Move the home.php file from the application/controllers folder to the modules/home/controllers folder. Point your browser to your Bonfire project. You’ll notice no change” , so this home controller still auto detect that this view files is application/views/home.php?

If i understand correct, it will find in application/views folder first and if not found home.php, it goes to modules/home/views to find home.php?

And i discovery that in the docs they said :

With the exception of the Public context, creating a controller for your module for a specific controller is a simple as naming your controller to match the context.  A controller for the content context, would be named content.php, while one that shows up in the settings context would be named setting.php.  For the public context, the controller should be named the same as the module.  For example, a Pages module would have a public controller called pages.php.

because he already define something at application/config/router.php about that, and if follow this rules to name controller, i dont need to add more route there. If i want to create a controller not follow this rules and i must add more route at route.php.

Thank you again for your userful and clearly instruction.

@tieungao - You’re very welcome. It took me a bit to work things out. Bonfire’s developer is looking for feedback. The documentation is still being worked on so he’s asking for things that might need improvement. He’s got a good PDF file for the Ocular system that provides Bonfire’s templating system. It’s also not finished. The link for that is in this thread somewhere I think. So far I just think he needs some more code examples of how the various functions are used. This is what makes CodeIgniter’s manual so easy to understand and use.

Hi i still have some questions :

- In the ocular 3.0 guide, i know that for display one html pages, this template system need :

+ Layout file.
+ Blocks
+ View files
+ Css and images and javascripts

about js, css and images i saw two directories contain this : assets at root directories and in theme/theme_name. I dont know why have all at theme directories, we still need assets directory?

- In the guide also said that the template system can automatic looking for views at application/controller_name/module_name.php , looking for views at into default theme, at modules/module_name/controller_name/method_name.php

So that this system is very difficult to follow and remember all the thing like that once u want to develop.

Hi tieungao,

Whether you need the assets folder is up to your application. It is intended to hold things that are not dependent on a particular theme. You might have common scripts that should be available to all themes, like jquery. You might store user uploaded images, etc.

As for the cascading nature of assets, views and layouts… not every application will use it, or need it. For smaller apps it is overkill, definitely, and you probably won’t want to use it. For larger apps it can be a blessing. So, the power and flexibility is there if you need it, but not required that you use it.

Hope that clears it up.

Thank kilishan for your clearly answer.

Maybe because im not familar with CI and HMVC,,  so it is so difficult with me to use your bonfire.

Can u make a tutorial how to make one article module, manager this in admin panel and display it at public pages (using the complete new templates set with js css and image). This will be the best way for some of newbie like me.

Thank for helping me out.

Well, Bonfire is designed for people who are familiar with CodeIgniter, so that’s probably the first hurdle to get over. 😊 Not that you can’t learn both at the same time. You definitely can.

I am actually working on a ToDo Module tutorial currently. Will hopefully be finished in the next day or two.

hehe i said that “Not familar”  means i not understand too much about some professional way like extended and modified standard CI. I’ve make many projects using CI and i understand about HMVC also.

I come to your Bonfire because i need one admin panel with nice-looking interface with Auth, and i can using it in every projects later. And i belivered u build the bonfire to help ppl do that.

I’ve searched this at this forum and at google for long time, i’ve tried pycroCMS, ionze cms, fuel CMS, but only your bonfire match what i need. You can see it easily because i active almost here.

That’s great to hear that u will make a tutorial soon. Im waiting for that.

I have some problems more, can u help me to solve :

- Like you said at docs :

With the exception of the Public context, creating a controller for your module for a specific controller is a simple as naming your controller to match the context.  A controller for the content context, would be named content.php, while one that shows up in the settings context would be named setting.php.  For the public context, the controller should be named the same as the module.  For example, a Pages module would have a public controller called pages.php.

I’ve tried to understand that and I guess u suggest user to name the controller like content.php and setting.php maybe because u add some like at routes.php for auto recognize them, but im not sure.

Note : I see in the core_modules have some controller name settings.php

Thank you for your time and sorry for my English.

You are correct. That is exactly why I am building Bonfire. It’s something that I will be using on all of my future projects, also.

There are routes built in which automatically recognize controllers within modules named after the contexts (content, stats, developer, etc.).

So, to create a page in the Content area of the admin pages, you would create a controller file named content.php. A barebones controller would look something like:

class Content extends Admin_Controller {

    public function __construct()
    {
        parent::__construct();

        Template::set('toolbar_title', 'Manage Articles');
    }


    public function index()
    {
        Template::render();
    }
}

This would automatically create a new submenu item in the Content context called Articles (assuming your module was named articles). It would look for the view file under:

modules/articles/views/content/index.php

To create the public-facing file, you would do something very similar, but the controller would be called articles.php and would simply be:

You are correct. That is exactly why I am building Bonfire. It’s something that I will be using on all of my future projects, also.

There are routes built in which automatically recognize controllers within modules named after the contexts (content, stats, developer, etc.).

So, to create a page in the Content area of the admin pages, you would create a controller file named content.php. A barebones controller would look something like:

class Articles extends Front_Controller {

    public function index()
    {
        Template::render();
    }
}

The view would be found at modules/articles/views/index.php. The page could be found at http://mysite.com/articles.

Hope that helps you get started!

Thank you so much.

Yes , your instruction is enough for me to get started coding with Bonfire!

Best Regards