Announcing Bonfire - A jumpstart for your web apps

[eluser]daK[/eluser]
@kilishan

Thanks for sharing your hard work, hopefully some of us will start actively contributing and help in shaping your bonfire vision.

Bonfire has been a big change for me since I cloned it 2 days ago. I'm no freelancer or web-solutions developer, just a system administrator who likes to build some tools to help other colleagues productiveness in a low-fund public health care center.

My already CI powered apps are quite ABC. A MY_Controller with some view help functions, a few controllers and models, and a main header+content+footer view file with load->views inside. They were born from CI_1.6, and today are happily living under CI_Reactor.

I've been reluctant in refactoring my ci_apps. For too long. It's time to reaally check HMVC, time to implement and use a good a template class, time to implement some of those great libs out there, etc..

Bonfire has made me decide to finally evolve (after a "false start" with pyroCMS). Yeah, just that click that I needed. Thanks for that man.
Main goals:
I'll start with migrating old apps to bonfire environment, than re-factor them in modules, then building modules from scratch. Along the way, understand HMVC clearly, and make good use of bonfire dashboard. By the end I hope I'll have enough confidence to retribute and contribute to bonfire's repo.

I'd like to ear some of your or community thoughts:

1. If I had to go live with my old app a.s.a.p., I guess that I just need to drop files in application folder and tweak index.php and config/db files. What's advisable to do when dealing with my old MY_Controller.php?
2. If instead I decided to drop the old_app in a module folder, besides expected breaks, do you see any big cons to face?
3. In your writings, you enfatize your worry to avoid overkills and overheads. Can you point some of those general "better don't do" advices related to performance? I have no idea what critical objects we should avoid feeding large datas.... the thought of a template class will have to make room for everything the site displays scares me...

I'll find these answers by myself probably, but I would really like to ear other people PoV.

Thanks, sorry for the big post, had too.

[eluser]kilishan[/eluser]
@daK

I think it's awesome that my work on Bonfire has inspired you to dig a little deeper into some of the CI resources out there, like HMVC.

If I were you, I'd try just inserting the main app into the app folder and start going from there. Once you get it working, you can start refactoring your code into modules. I don't think it would work to drop the code into a module, and would make things harder for you in the long run.

As for performance, my biggest suggestion is don't worry about it too much at this point. For most of the sites that a lot of us create, it really doesn't make a difference. PHP and CI are fast enough to work well for most sites. If you have a site that starts to become popular, then it might matter. Until then, it's best just to pay attention to how you can structure your site to take advantage of caching, if you do anything at all.

[eluser]daK[/eluser]
Thanks for your insights

I'll push your knidness and ask a few questions regarding Migrations and Bonfire...

1. We're suppose to start (I mean intentionally) the migration process (from bonfire admin)? Or it will happen in the background whenever it finds an outdated version? It is set to TRUE in config, but I want to be sure it will not AUTO migrate...
2. Ok, so bonfire is my ci-projects new best friend, almost an extension to IDE. It even has migrations support. But I'm trying to visualize how it will share a few features, like migrations. Bonfire will help me migrate, but bonfire migrates also. If I had developed a 002_my_first_proj_migration.php, it would have collide with your 002_Version_02_upgrades.php sooner or later. How are we supposed to harmonize both migrations (pers projects and bonfire)?

Humm I'm here thinking that we can use the prefix bf_ to our help, I can have my schema_version on one side, and bf_schema_version on the other... or not? Is your idea of using migrations lib in bonfire aimed at having migrations in new ci-projects? Damn I'm confused.

[eluser]kilishan[/eluser]
Sorry about the confusion. Though some of that is probably because I haven't fully thought through or provided solutions to that yet.

For those that upgrade Bonfire often, it's probably a pain. If you start with a point release (0.2 when it's final, for example) and continue that site on from there, you will be fine and will not run into collisions.

However, one of the things just added to the ToDo list was to modify migrations to work with modules, also. When this gets done, it will support ordering of files (001, 002, etc) within each module to keep the abilities separate.

And, no, I don't have a timeframe for that.

[eluser]kilishan[/eluser]
And I forgot to answer your first question: Migrations are NOT run automatically. They must be initiated by the user from within the admin.

[eluser]daK[/eluser]
Thanks, you've answered them all, I like what you wrote, and as a bonus I got to know that

Code:

For those that upgrade Bonfire often, it’s probably a pain.

Yeah! now I know the pain is supposed to be there

But I guess building and debugging a dbforge install scripts for us is a much bigger pain

btw there are 2 config files for migrations in your bonfire...

ty

[eluser]kilishan[/eluser]
yeah, dbforge scripts are kind of a pain. For my personal modules, I don't use it. I know that I'm targeting MySQL in those cases so I modified the migrations class to allow for return a string of one or more SQL commands. Makes it much nicer.

To use, simply add <code>public $migration_type = 'sql';</code> and return the string of SQL from the up/down methods.

[eluser]daK[/eluser]
I remember someone announcing an sql migration tweak at pyroCMS forums, looked really neat at that time... was it you?

Curiously I was reading the TODO (btw so much ty) and thinking an example of an SQL initial import would be the cherry on top of the cake.
Maybe you'll find an extra time to input sql example into it (although I understand the TODO have taken a lot of spare time already...)

I'll try your snippet with one of your sql february dumps
:lol:

[eluser]daK[/eluser]
I could use a little help here pls

I've been rerereading this thread, with precious Lonnie help and basketcase usefull fourfender, trying to stick HMVC in my mind, and finding out whats happening behind "the scenes".

I built the home module, and was playing around with bonfire to see what shows up and where. It's been a lean curve for me...

I wanted to see what would happen if I had a home (CI) controller and a module home. Who would come up first. And tought that if I look into forensics, I would know if the class/method is built from a module or not.
But can't figure... I also don't know what the system folder is being used by the view/controller. Am I missing those vars in Forensics?

Is there a helper or something in bonfire that I could use in an empty controller
and an empty index.php (beeing my scratch view to later use index.php through folders) that would help output "where am I and who's calling me"?

I'm thinking it would help me to have some sort of skeleton like this:
modules/greyskull/controllers/content.php

Code:

class Greyskull extends Front_Controller {

    public function index()
    {
        Template::set_message('some helper or fn that returns where's this index.php or what module controller this comes from');
        Template::render();
    }
}

modules/greyskull/views/content/index.php

Code:

<?php echo Template::message(); //every view will tell me _where am I_ ?>

I tought it would be simple to build a snippet that would make every view display show me the view's file path and what method called her... just to know where I am while playing with modules... but sadly tried all day and giving up now...

Kinda frustrated 'cause I know this must be simple...

[eluser]loosetops[/eluser]
@daK,

I don't get what you are really trying to do. HMVC is kinda straight forward so don't think too much. Review a working example and everything will make sense. Check out the todo module tutorial method. It shows how the build backend modules for Bonfire, but also highlights HMVC in action.