Settings page integration

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Settings page integration
« Reply #16, on March 12th, 2012, 09:17 AM »
Strikes me that there's two ways to do it, either by checking for $txt[$current_setting . '_subtext'] and just setting subtext to that if found, or manually specifying it as a parameter. The former would be quicker and likely easier to use but the latter would be clearer how the answer is derived.

Which would you prefer to use? (Remember that you can have help text if you so desire, though it's not immediately obvious how... if you declare $helptxt[$current_setting] and then have it so your language file is also loaded by the lang_help hook, it should work (though I haven't tested to be sure)
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Settings page integration
« Reply #18, on March 12th, 2012, 01:51 PM »
Haha, indeed it does. But therein is the reason why $helptxt is a separate variable, it's to keep it structurally simple :)

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Settings page integration
« Reply #19, on March 12th, 2012, 01:52 PM »
Quote from Arantor on March 12th, 2012, 09:17 AM
Strikes me that there's two ways to do it, either by checking for $txt[$current_setting . '_subtext'] and just setting subtext to that if found, or manually specifying it as a parameter. The former would be quicker and likely easier to use but the latter would be clearer how the answer is derived.

Which would you prefer to use? (Remember that you can have help text if you so desire, though it's not immediately obvious how... if you declare $helptxt[$current_setting] and then have it so your language file is also loaded by the lang_help hook, it should work (though I haven't tested to be sure)
I'd do it the geek way and define an entire hook as <current_setting>_helptxt.
The way it's meant to be

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Settings page integration
« Reply #20, on March 12th, 2012, 02:03 PM »
That seems a big drastic seeing how there's absolutely no need to do anything extra in core for help popup strings.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Settings page integration
« Reply #21, on March 12th, 2012, 02:12 PM »
Quote from Arantor on March 12th, 2012, 02:03 PM
That seems a big drastic seeing how there's absolutely no need to do anything extra in core for help popup strings.
It was a joke, I'd just do it similarly to title. If title is passed, then pass the helptxt as well otherwise just take it if defined in txt entries.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Settings page integration
« Reply #22, on March 12th, 2012, 02:20 PM »
That's all well and good (and the use of help items was more a footnote that they work already without any extra core effort), but that doesn't solve subtext items, which are normally defined in $txt and have no direct correlation to the primary entry. I personally tend to try and be consistent and for $txt[$key], define $txt[$key . '_subtext'] but $txt[$key . '_note'] is also used.

So, should we auto-use $txt[$key . '_subtext'] or have something in the XML to specify the subtext? Note that it might also be good to allow for having post-values as well like in some of the numeric fields where after it, the word 'days' is used to indicate that it's a set number of days.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Settings page integration
« Reply #23, on March 12th, 2012, 02:25 PM »
I'd simply define it as $txt[$key . '_subtxt'] mostly because then it goes with other langaage strings and can be translated at one place.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Settings page integration
« Reply #24, on March 12th, 2012, 02:36 PM »
OK, cool. I'll implement that later on then as it's a pretty quick thing to add.

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Settings page integration
« Reply #25, on March 13th, 2012, 01:31 AM »
Quote from Arantor on March 12th, 2012, 09:17 AM
Strikes me that there's two ways to do it, either by checking for $txt[$current_setting . '_subtext'] and just setting subtext to that if found, or manually specifying it as a parameter. The former would be quicker and likely easier to use but the latter would be clearer how the answer is derived.

Which would you prefer to use? (Remember that you can have help text if you so desire, though it's not immediately obvious how... if you declare $helptxt[$current_setting] and then have it so your language file is also loaded by the lang_help hook, it should work (though I haven't tested to be sure)
I prefer the former, like Dragooon

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Settings page integration
« Reply #26, on March 13th, 2012, 01:35 AM »
OK, so I need to define an extra thing in the XML just for subtext as opposed to having something automatically check a preset $txt.

* Arantor goes to fire up the heavyweight XML editor to manage the schema.
Posted: March 13th, 2012, 01:33 AM

To be absolutely clear, we're talking about the difference between:

Code: [Select]
<settings>
<setting name="contact_verification" default="guests" />
</settings>

and
Code: [Select]
<settings>
<setting name="contact_verification" default="guests" subtext="contact_verification_somestring" />
</settings>

And then just defining $txt['contact_verification_subtext'] in the first case vs $txt['contact_verification_somestring'] in the second. The former is a 'just works' case.

The latter sounds like an awful lot of work for something most plugin writers won't even use...

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Settings page integration
« Reply #27, on March 13th, 2012, 01:53 AM »
Why would a plugin want to define its own subtext other than using its own format, like using _desc instead of _subtext?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Settings page integration
« Reply #29, on March 13th, 2012, 02:01 AM »
Yes, iit was. I was just exploring why someone would want to do otherwise, when this way seems better and simpler and less error-prone.