Bonfire
Bonfire copied to clipboard
lonnieezell
Bootstrap 3.3 (was 3.1.1) fork
I have Bonfire seemingly working in a bootstrap3 fork, but still many little cosmetic issues in the Admin. If anyone is interested, please feel free to help clean up...
I'm wondering though if Bonfire could be more loosely coupled somehow so it could use different UI's...? (Sorry if this is not truly an "issue" but I'm wondering if it could be made so 2.3.2 and 3.1.x could both co-exist and maybe have a config setting to select)
We could always open up a branch and figure out what needs to be done to allow the two to co-exist peacefully. I've started down the path a few times, but my own site is in 2.3.2 and I haven't gotten around to setting up a test theme in 3.x to test.
I think this would be possible, but a fair amount of work. The way I see it would have to happen is to create a new driver set that are basically Decorator classes for the views. They'd have drivers for each theme system to support, like BS 2 or 3, Foundation, whatever. In part it would be the form library, but that only covers portions. It would also have to cover basic UI items like headers, buttons, etc...
That would be quite a task, . I was thinking something simpler like a file suffix and/or a conversion engine that could take in a mapping to translate between syntaxes for all the BF views...
A conversion to TWBS3 would definitely be a welcome change, although not hugely important.
Yeah, I think it would be much simpler just to update to BS 3 at some point and call it good. Anything else is an extra layer of complexity that really isn't needed. They can still use anything they want for the front end.
Well, it certainly will be a simpler job then... I'll go on that premise.
I have the admin nav looking all nice now. I'm tweaking modules now. Maybe we can publish the current app as 0.7.1 and this will go into 0.7.2 or would it be start of 0.8?
We'd probably normally put it in 0.8. I'm not sure where 0.7.1 is going to end up, though, given the issues with the loader.
For now, the best bet will probably be to push the bootstrap 3 changes to the bootstrap3 branch, and we'll have to do our best to keep them in synch. Ideally, I'd like to have 0.7.1 on bootstrap 2 and a release that is primarily for bootstrap 3.
I may continue looking at methods to help the various CSS frameworks live side-by-side, and having the two branches for comparison may make it more obvious where we need to isolate related code.
One area I was specifically considering would be a Menu or Nav class which could be passed to a renderer/writer class to do the actual translation to HTML. Then the contexts library could create a Menu object and either use Dependency Injection or a config value to get the writer to generate the output. This would also allow users to build other menus/navs on their site the same way, and different writers could output navbars (of various types), tabs, pills, etc.
Or we could even find an existing menu library that could be modified to work with CI/Bonfire and work from there.
There is a menu branch with work in progress on that. It still needs work adding support for separators, permission checking and just going through to ensure that it's flexible enough to support these various frameworks.
Unfortunately, I haven't had time to wrap it up just yet.
I've taken a quick look at that, but I think it looks more like a replacement for the Contexts library's render_menu() method with some extensions for other uses.
I'm thinking along these lines:
- a general Menu class, basically a container, then you'd have the entries for the menu. The entries could be simple menu items or sub-menus (possibly with decorators or factories for different item types, like headers, dividers, and links, since there are bound to be others, like inputs, images, and buttons)
- a Menu Builder/Factory to build Menu objects from a given data source (like the contexts, a .json file, database table, XML, etc.)
- a Menu Writer/Renderer to convert Menu objects into output/HTML for the target framework
Ideally, we could leave Contexts::render_menu('text', 'normal'); in the admin theme's _header view and just have the Contexts library load a ContextMenuFactory to generate the menu object for the Contexts (or an object for each of the Contexts). Then it could load up a Writer/Renderer based on configuration and/or Dependency Injection (though Dep. Injection would likely require changing the code that loads the Contexts library or calls Contexts::render_menu(), it could default to a Writer that outputs the existing markup if nothing is injected).
Maybe something like this concept ( https://bitbucket.org/purposemedia/menu/ ) as a starting point for a menu class?
Have you pushed this into the bootstrap 3 branch yet? If so, I guess I missed the pull request...
I just tried, not sure if it worked? I'm out of sync by a day now and my merge attempt was not working on my system for some reason either...ugh. But everything's under boblennes/Bonfire.
It's ok if the branch is out of synch with the develop branch. I was primarily concerned with capturing the changes for bootstrap 3 in one location. I've merged the PR into the bootstrap 3 branch.
I was thinking about trying to put together something using KnpMenu (https://github.com/KnpLabs/KnpMenu), given that it's one of the more popular menu libraries on Packagist, and covers most of what I was looking for. I'll have to mess with it a little, though, to see if I can get it to play well with CI and bootstrap's navs.
At a glance, it seems like a pretty nice library. Still leaves the decision about how to get the menu information into the system, which the menu branch I've got solves most of already. I like the idea of using something like this for the rendering of it, though.
I may be bouncing around on quite a few big issues for a while. I'm working on a blog/wiki type of system that I hope to use for a handful of sub-sites.
I'm going to attempt to use KnpMenu for this project, and, if it works out, integrate it into the UI module and work on rendering the rest of my site's menus with it. Somewhere in there, that would eventually get me around to the contexts. I'm also considering writing the default theme for this new system in bootstrap 3, which would at least help me get more familiar with the process of transitioning from bootstrap 2 to 3.
This discussion touches on the points I raise in this issue comment I am commenting here to reboot the discussion so to speak :)
I'm redoing the Bootstrap fork. I am using composer to pull in jQuery and Bootstrap into /public/components and eliminating the multiple copies of the libraries. I've created a develop-bs3 branch but I'm git challenged, not sure how to push it to github since it's under ci-bonfire and not boblennes. I have some tidying up to do, should be ready in a few days... hopefully we can keep it in sync then going onward.
If you submit it as a pull request against the bootstrap3 branch, I should be able to merge it. Otherwise, I'm sure we can figure out something.
For anyone else watching this issue, #1125 pulls the latest changes from @boblennes into the bootstrap3 branch here. Due to the number of changes, I haven't given it a thorough look, yet, but I hope to do so soon.