On Wed, Jan 6, 2010 at 12:27 PM, Danny <[email protected]> wrote:
>>
>> > 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.
I see. So you are suggesting we have a central location for default
values not specified in site.config. That's a good idea...
>> > 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?
Yes that is a good idea also. I was going to tinker with the idea of
deleting the site.messages page, and just use translation files to
customize messages, but I need a place to define the default messages.
Your suggestion may be better. Let me think about it some...
>> >> 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.
Let's come back to this when we write the forms processor. I have some
good ideas for that.
>> >> >> > 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.
I don't use phpbb. I'm not too worried about it, because a super
admin at least should have ftp capabilities if worse comes to worse.
Can fix about anything with that! :)
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.
