Announcing Bonfire - A jumpstart for your web apps

[eluser]Basketcasesoftware[/eluser]
@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"!

[eluser]tieungao[/eluser]
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....

[eluser]InsiteFX[/eluser]
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

[eluser]tieungao[/eluser]
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?

[eluser]Basketcasesoftware[/eluser]
[quote author="InsiteFX" date="1303921782"]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[/quote]
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? ;-P

[eluser]Basketcasesoftware[/eluser]
@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

[eluser]tieungao[/eluser]
[quote author="Basketcasesoftware" date="1303939811"]@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[/quote]

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 :

Code:

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.

[eluser]Basketcasesoftware[/eluser]
@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.

[eluser]tieungao[/eluser]
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.

[eluser]kilishan[/eluser]
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.