Some deep code question about applicable_formats

Some deep code question about applicable_formats

par Valery Fremaux,
Nombre de réponses : 6
Someone has information about this line ?
 $thisformat = '^'.str_replace('*', '[^-]*', $format).'.*$';

Located in blocks_name_allowed_in_format($name, $pageformat) (lib/blocklib.php near §177 - sorry guys, but have patched blocklib.php so line number may be wrong...) No in-code documentation here. What is the heuristics used here for format matching ?

My immediate need is to change control over applicable_formats in all course formats as a global but essential cleanup customization. I would suggest this format checking might have a local hook entry to allow customization to take over applicable formats whitout having to patch ALL blocks !! This is specially usefull when adding alternate customized page formats that will need a reconsideration of those settings.

Something as :

function blocks_name_allowed_in_format($name, $pageformat) {

global $CFG

$accept = NULL;
$depth = -1;

if (file_exists($CFG->dirroot.'/local/lib.php')){
require_once ($CFG->dirroot.'/local/lib.php');
if (function_exists('local_get_format_mapping')){
$formats = local_get_format_mapping($name);
}
}

if (!$formats){
$formats = block_method_result($name, 'applicable_formats');
}

if ($format){
foreach($formats as $format => $allowed) {
$thisformat = '^'.str_replace('*', '[^-]*', $format).'.*$';
if(ereg($thisformat, $pageformat)) {
if(($scount = substr_count($format, '-')) > $depth) {
$depth = $scount;
$accept = $allowed;
}
}
}
}

...

Cheers...
Moyenne des évaluations: -
En réponse à Valery Fremaux

Re: Some deep code question about applicable_formats

par Hubert Chathi,
That specific line looks like it converts a pattern into a regular expression. Basically, the pattern must start at the beginning of the string. "*" will match any number of characters that are not a "-". The string can end with anything. (The pattern may contain other regular expression tokens too, which will be interpreted a normal regular expression tokens.)
En réponse à Valery Fremaux

Re: Some deep code question about applicable_formats

par Penny Leach,
Hi Valery,

About your first question - I was worried that it was me, (it wasn't) so I dug back through history and found it was introduced in 8a47e075 (assuming you're using git) - git show 8a47e075

Read the commit message and it might give you some idea about what it's meant for.

Regarding the second question - my best advice is to file a bug with a patch ;)
En réponse à Penny Leach

Re: Some deep code question about applicable_formats

par Dan Poltawski,
For the non-git/not near terminal users:
http://git.moodle.org/gw?p=moodle.git;a=commit;h=8a47e075 clin d’œil
En réponse à Dan Poltawski

Re: Some deep code question about applicable_formats

par Valery Fremaux,
Thanks all !!

Bug with a patch, of course !! when I get more that ten seconds free time clin d’œil

Cheers.

While I'm here with great Git and CVS users :

I use a Git to CVS bridged codebase and I am upset with the CVS identifier line changing on CVS commits and forcing a change to be tracked by upstream Git.

How could I avoid this cross effect ? Is there a way to ask CVS not to generate $Id$ tagging ?

Thanks.
En réponse à Valery Fremaux

Re: Some deep code question about applicable_formats

par Tim Hunt,
Avatar Core developers Avatar Documentation writers Avatar Particularly helpful Moodlers Avatar Peer reviewers Avatar Plugin developers
Note that the applicable formats code will probably change in 2.0 dev in a month or so as part of my block changes. I don't know exactly how it will work in future, but it will probably only become more flexible than it is now.

But, actually, that is no reason not to put a sane hook into 1.9, and I will do my best to keep the same hook in 2.0. However, I cannot absolutely promise that I will not have to change the semantics.