Pull to refresh

Comments 22

PSR? «array()»? открывающий «<?»? Composer? И в качестве добивающего «var» в объявлении полей класса.

Шёл 2016ый год…
P.S. Я уж не говорю про смешение логики и представление — это само собой очевидно и говорит лишь о небольшом опыте.

Но использование var… Это же PHP начала 2000х годов, когда в мире царствовала версия 4. Это даже если учитывать небольшой опыт — надо очень сильно постараться, чтобы найти какой-то «учебник», где такое написано, примерно как ПК с Pentium 3 на борту. Просто раритет и подрастающее поколение такое даже в глаза не видело нынче.
UFO just landed and posted this here

Идея может и неплохая, но код… Приведите код к psr-2. Смените кодировку на utf-8. Добавьте тесты. Замените var на нормальную область видимости. Вынесите шаблон и JS код отдельно от класса.

Спасибо учту. Пока нет необходимости разделять на файлы. Суть в том чтобы инструмент был максимально компактным и состоял из одного файла.

максимально компактный но зависимость от jquery? И как вы сами вообще умудряетесь там всё править в этой мешанине. Ну уже хотя бы как то разделили код метода showFormна части по внутренним темплейтам в heredoc. или вообще зачем там класс тогда, сделали бы просто скрипт, тоже было бы в одном файле но чище. Ну или phar есть.


На самом деле я удивляюсь вашей "смелости". Такое на хабр выкладывать… Идея спорная всё же. А исполнение хуже некуда.

UFO just landed and posted this here

А еще у вас всё плохо с именами переменных. Date где по логике data, safe где должно быть save, Attrebut с одной t. Это я уже не говорю о семантической корректности например имени метода getAtributes

отформатировал. переименовал переменные
UFO just landed and posted this here
Самое удивительное, что часто конфигурация имеет больше 2-х уровней вложенности, и тут все перестает работать…
Плюс, сильно зависит от форматирования и правильности комментариев в конфиге
UFO just landed and posted this here
в основных конфигах точно. Но вот всякие параметры типа количество объектов на странице, емайл, и прочее можно вывести для сохранности в отдельный файлик.
Ну и на худой конец класс сразу же создает бэкап который позволяет вернуться к первоначальной версии.
Я бы вообще для визуального редактирования, если уж очень понадобилось, использовал бы какой-нибудь свой формат, с экспортом и опционально импортом, а конфиги напрямую редактировать не давал бы — только ручками (по фтп, например)
Извините, но что это за убожество и как оно попало на habr? Автор, вы в php 2 недели отроду? Я пожалуй впервые вижу столь извращенный велосипед там, где он совсем не нужен и там, где есть отлично документированные нативные функции php. Отбросим следование стандартам, psr, best practice и другие концепции, давайте по факту.
1. Логика чтения и записи в файл конфигов. Я или очень сильно отстал от жизни, или чего-то не знаю, но зачем делать вот это:
public function getAtributes() {
		$conf_str=file_get_contents($this->file_name);
		foreach($this->date as $n=>$cf) {
			if(preg_match("#".$n."[^\r\n]*//([^\n\r]+)[\n\r]#",$conf_str,$m))
				$this->atribute[$n]=trim($m[1]);
		}
	}

Что вам мешает иметь конфиги вида:
<?php
return [
    'param1' => [
        'param2' => 'value'
    ]
];

и делать прямой инклюд данного конфиг-файла как то так:
.... 
if (!file_exists($path)) {
    return;
}
$configArray = include($path); // look at ex#5 http://php.net/manual/en/function.include.php
if (!is_array($configArray)) {
    return;
}

и вы получите тот же самый массив конфига без извращений через preg_match*, притом что ниже в конструкторе вы так делаете сами (вопрос — а на*рена этот конструктор там вообще?)
public function __construct($file_name) {
    // ....
    $this->date = require $this->file_name;
    // ..... 
}

Поехали дальше. Зачем вы делаете замену значений по ключу в строке?
public function safe(){
    $conf_str=var_export($this->date,true);
    //$atr=$model->getAtribute();
    foreach($this->atribute as $n=>$v) {
        $conf_str=preg_replace("#([^\n\r]*".$n."[^\n\r]*)[\n\r]#is","\\1//".$v."\n",$conf_str);
    }
    file_put_contents($this->file_name,"<? \n return ".$conf_str." \n ?>");
}

выглядит так, будто вы специально пытаетесь выстрелить себе в ногу или сломать ее о свой кривой велосипед. Почему вы не работаете со своим же массивом $this->data не обновляя в нем значения переменных из входящего POST а позже не конвертируете финальный результат в str (var_export)? Какую цель вы преследуете, заменяя значения через preg_replace в сконвертированной строке?
2. Смешались в кучу кони-люди. Зачем вы используете синтаксис html/css в теле функций на echo? Я видал всякое, видал echo внутри php конструкций, видал echo и return'ы внутри функций, но чтобы в теле класса содержимое метода представляли вот так:
<?php
class Configer {
    	function showForm(){ ?>
		
<style>
	#configForm span{display:inline-block; width:150px; }
}

я вижу впервые… не нужно так.

танцы с preg_match и preg_replace там я так понял из-за комментариев. Другое дело что благодаря коду это не очевидно)

Да, я это уже понял позже когда более пристально глянул в «код», если его так можно назвать. Стоит ли оно того конечно вопрос (выходит что конфиг инклюдится, а позже считывается, а при сохранении замены ведутся перебором цикла, и тут шаг в сторону будет равен выстрелу в ногу).
Ну вообще код, представленный в топике, попадает в раздел «не нужно, но было бы приятно прихерачить сюда гуй — гуяк гуяк и в продакшн через 2 часа», и никогда не должен выкладываться на хабр.
Ибо сюда заходят люди, которые хотят прочитать что-то действительно новое и интересное.
А подобные топики нещадно заминусовываются вместе с кармой автора.

У самого таких поделок вагон и маленькая тележка, но они редко попадают даже на личный гитхаб, ибо смысл?
Возможно смысл в том, чтобы получить критику от сообщества. Например, zenn потратил время на анализ представленного автором, а значит конвертация кармы в опыт вполне может быть оправданна.
У автора под рукой интернет и если бы он потрудился изучить статьи других авторов — не раз бы наткнулся на ссылку: http://getjump.me/ru-php-the-right-way/ и мог хотя бы попытаться следовать, пусть не всем, но хотя бы большинству рекомендаций. Моё мнение, если бы автор стремился к критике сообщества — он бы мог её получить и без хабрасуицидов.

P.S. В нашем же случае — автор просто положил большой болт и понадеялся на непонятно что. Да, можно оценивать его работу, как действительно какую-то работу и сказать ему «спасибо» за это. Ну вклад в сообщество и всё такое…

Но тут немного иная ситуация: Подобная задача решается намного проще, быстрее и качественнее, так что такой «вклад» не только не нужен, сколь вреден. И вреден не только как пример «как не надо писать», но и тем, что он может навредить тому, кто решится его использовать, начиная с безопасности, заканчивая повреждением исходных файлов конфигураций.
Sign up to leave a comment.

Articles