>
> > For configs, I think we could make another function like BOLTsetConfig
> > which takes a string in the identical pattern and sets the config
> > array (also modify the config init part) so that users wouldn't get
> > troubles by directly setting config array and get problems by adding
> > "BOLT" or not using lowercase as the index name. And we can then put
> > default config values alltogether in init routine instead of making
> > them everywhere.
>
> Not sure I follow you here. It's already easy to set config values via
> php (the syntax isn't that hard). But one advantage to having them set
> many places, is we don't need globals for everything. Maybe I'm
> missing your point, but that was the goal of the BOLTconfig
> function--to eliminate the need for as many globals as possible.
>
> I think I probably just missed your suggestion. But generally, the
> BoltWire config seems to be working fine.
I just think of nothing special but that good programs are well-
modalized. I know it works fine now. But it's inconvenient to overview
and manage all config options. And it'd be a burden when we want to
change the default value of, say 'BOLTblockSlashes', from 'true' to
'false', we have to find and replace many many parts.
>
> > For messages, I wonder if we need site.messages actually? It seems
> > that we are messed since site.messages and site.languages could both
> > affect the message output.
>
> > Would it be better to define all system messages directly in an array
> > variable in the core, and make site.language the only way to modify
> > message output? (A problem is that if language is configured to be
> > default the site.language is ignored. But we can simply add a
> > "site.language.en" and put only system messages and the "translation"
> > in it if we do need to change the messages in English.)
>
> I've consider this several times before, but for an English user, the
> site.messages page gives me a way to fully customize any system
> messages I want to. I suppose we could use a custom English language
> file for that--but it seems it would bog performance down
> unnecessarily. If not, I'll be happy to make the change. It would add
> even more functionality--as the ability to change many more things
> about the system.
I just think that it's annoying to define a system message in function
call, in site.messages, and again in site.language.
Well...what about just add a site.message.[lang] for message
translation and deletes the correspond definitions in lang?
>
> >> Many times it is convenient to insert a line break into a form session
> >> value, something like this:
>
> >> [text name]
> >> [text email]
> >> [box contents][box]
> >> [session body "Name: {=name}\nEmail: {=email}\n\n{=contents}..."]
>
> >> That's the purpose. We may change this in the future to only make it
> >> happen for session inputs, and never normal html inputs.
>
> > Well.. We probably put it at the wrong place, because putting it in
> > Xedit just make inputing:
>
> > [session body "Name: {=name}\nEmail: {=email}\n\n{=contents}..."]
>
> > actually same as the following:
> > [session body "Name: {=name}
> > Email: {=email}
>
> > {=contents}..."]
>
> This is not possible because it breaks the markup rule for [session...]
I know it wouldn't work. And what I meant is that when you input the
above text you get the result exactly same as the below. Just create a
page and make a try you should know what I mean.
>
> >> >> > However I still think it's not good to write it this way, which may
> >> >> > lock the superadmin himself.
>
> >> >> Good point. Seems the easiest way is to wrap the whole little routine in
> >> >> if (BOLTingroup('admin') === false) { }
>
> >> > No it wouldn't work. Because login page will be locked.
>
> >> To login, you just use &action=login
>
> > I am sure we can't because we are not considered @admin before logging
> > in. I did a test in v3.3.3 and it proved.
> > And what I meant to is to permit only superadmins instead of @admin
> > but it's OK if you think so.
>
> Oh, you are right. I'm open to other ideas... but shy of some kind of
> authentication it seems impossible. Unless the page you get when
> blocked is a login page...
I'll thik more about it. The first come to my mind is that maybe we
could refer phpbb3.x.
>
> Shouldn't the second line be elseif?
>
> if ($BOLTwhiteList != '' && strpos(BOLTloadpage($BOLTwhiteList),
> $BOLTvar['$ip']) === false) {print_r($IPblockedHTML);die();}
> elseif ($BOLTblackList != '' && strpos(BOLTloadpage($BOLTblackList),
> $BOLTvar['$ip']) !== false) {print_r($IPblockedHTML);die();}
It should be OK.
>
> >> >> > 10.Fixed a mistake of 3.3.2f while parsing [messages] before getting
> >> >> > zones so that function messages are not showed.
>
> >> It seems function messages work in the main BoltWire core. I am not in
> >> any way planning to move messages from BOLTmakepage to BOLTdomarkup.
> >> I've tried both ways more than once--but to get a full system wide
> >> return of all messages from all zones, it cannot be done in
> >> BOLTdomarkup. So I really think it needs to stay where it is.
>
> > Yes we can and it's tried and proven. In my process we first replace
> > [messages] in BOLTdomarkup to <div class="message" /> and make a total
> > replacement again after doing markup.
>
> > It's a little complicated but the benefit is to reduce the hardcodes
> > and to increase the freedom for users to further manage the markup
> > rules. And in any point <div class="message" /> is a string that
> > cannot be input in anyway so it would never mass up any markup rule
> > except the one which means to create a message block. Also it won't
> > make /= [messages] =/ or something like that work. Same for [results].
>
> I am not convinced it will work in all situations, or that it is more
> flexible. If a person wants some kind of different system, they simply
> don't use [messages] on the page and add whatever markup rule they
> want. If a person wanted to go further, they could always take
> advantage of the makepage hook to eliminate this feature. But doing it
> in domarkup is impossible if you have a message coming from say the
> bottom zone, and the [messages] markup is in the main page. It has to
> be rendered after all the zones have been processed.
I bet it works since the process of message is after all pages are
formatted - just like before where we process [messages] - in
BOLTmakepage:
$out = preg_replace('/\[\[([a-zA-Z]+)\]\]/e', "BOLTgetzones('$1')",
$out);
while (preg_match('/\~\~([0-9]+)\~\~/', $out) == 1) $out = BOLTescape
($out, false);
$out = preg_replace('/<div class="message" \/>/ie', 'BOLTmessages
("$1")', $out);
Though it's still up to you.
--
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.
