On Thu, Jan 7, 2010 at 10:24 AM, riccardo <[email protected]> wrote: > On Thu, Jan 07, 2010 at 08:35:09AM -0500, The Editor wrote: > >> On Wed, Jan 6, 2010 at 7:32 PM, riccardo <[email protected]> wrote: > [...] >> Thanks for the feedback. I agree with you on both goals--simple file >> management system, and simple code base. And yet robust. > > Perfect. > [...] >> > dokuwiki ... >> > just placing the >> > variables that are to be changed in a config file will change only them >> > and >> > inherit the values for all others from above. >>· >> This is a nice idea. I'm thinking of combining this idea with >> something Danny suggested (can't recall if it was onlist or off), >> about having a central config script that would keep all the default >> config settings in one location.· > > I was going to suggest that next. IMO it's best to put all the config items > in one file and include it. This is not only easier for the average user, > it makes writing a configuration front-end (I guess in BW that is going to > be a config form on a special page) much easier, and also simplifies trying > out different combinations (by symlinking to different variations) while > developing a site or while developing the engine itself.
Currently, most everything can be configured through the site.config page, except a few variables that might pose security risks. However the default values are often scattered throughout the code--which of course is convenient for me as a developer. Also for plugin developers and the like. Currently any site.config/default code value can be overwritten in config.php or in a hierarchical version of that page for certain sections of the site. That's three locations these can be set already. Setting up a ini.php script or something in the barn with all the default values has some attractiveness to me--namely a central list of all the possibly configurably values--but there are disadvantages. First, another script to read and process. Second (and bigger), a fourth location to check for config values. (site.config, core/plugins code, config page--and now ini.php). Presumably, we would design this so you could have a field or farm ini.php file override the system page to make customization easier, meaning more places to consider when debugging. Third, as a developer I have to constantly sync the code with the ini script (something I'm having trouble with, as shown in the messaging and translation systems). And of course plugin developers would not have access to a central ini script anyway. So it may be best to just document somewhere the possible config settings, and then encourage people to use the site.config/config.php system as it is. On the other hand, there are a lot of filters, attrs, vars, etc in engine.php that could be moved to an ini file. The question is, what would be the benefit of that. I'm just thinking out loud. I tend to find if I don't jump on every good idea, some sense will come through in the long run. I often think back to many discussions I had with Pm over at PmWiki. He was an excellent mentor--and warned against distributing config options among too many locations. That counsel seems to apply here. >> Especially if it could be combined with a hierarchical system, which does > > Do you mean a hierarchy of config variables? I've seen this used elsewhere > where config variables are in a two dimensional array -- makes naming > easier when altering the code, and also finding the right variable easier > when configuring a site. Yes exactly. Adding a dimension to the config array for locations in the hierarchy, and BoltWire simply checks for the config value with the closest hierarchy marker. This could make it very easy to set config values for different sections of the site all in config.php. Should be easy to do with no disruption to current sites. But a possible hit on performance. Of course, we could just as easily do what I often do now if ($pageArray[0] == 'test') $BOLTconfig[...] = '???'; else ... Accomplishes the same thing, but keeps the core engine fast and clean. Both of which I like... :) So I'm not yet convinced about this idea either. It appeals to me, but not every feature actually strengthens a software program. > [...] >> > For both dokuwiki and cmsmadesimple, I wrote tags for things I like to >> > do >> > often -- and example being a box ...· >> > [with very variable contets and parameters] > [...] >>· >> It's probably just a simple issue of customizing the box css style or >> adding some new styles, and if you wish, some markup rules. Here are >> two solutions pages you might want to look at, for ideas. >>· >> http://www.boltwire.com/index.php?p=solutions.css.stickynotes >> http://www.boltwire.com/index.php?p=solutions.css.special > > Ye--es. There may be easier or just different ways of achieving what I want > in BW. I'll need to find time to play a bit. But the code I wrote for doku > and cmsms was a custom tag that accepted a stack of possible parameters to > allow floated "bits" in a range of styles to be inserted by someone who > doesn't know or want to mess with css directly, and to allow these "bits" to > follow a style determined by the site css while being able to be controlled > in size and position etc. I am likely to feel moved to hack something. You should right now be able to do in BoltWire: <div class="highlight,large,small-caps">Your stuff</div> To add more or different options, just modify your css. We could easily develop a markup that converts: <box highlight large small-caps>Your stuff</box> to what you want. In fact, it may not be a bad idea for the core... I'll think about it. Is that what you had in mind? >> If you need help customizing something, post the markup you want to >> use, and the html output you would like to see, and someone should be >> able to whip together a markup rule and/or some css for you pronto. > > Thanks. As I say, I am more likely to try to do it myself, but it's good to > know help is at hand. Glad to have you aboard. Looking forward to your contributions. Cheers, Dan
-- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
