Jump to content

Firestarter

Members
  • Content Count

    29
  • Joined

  • Last visited

Posts posted by Firestarter

  1. Подтверждаю, продажа, согласована с автором доргена Thunder. По ссылке можете почитать, о возможностях генератора дорвеев, вопросы почему "нет еще пары рук свободных" отпадают. 

     

    ПC; сегодня вышел Thunder 3.10 Framework )))

  2. @NedilkoAlex, так точно. Хороший движок для таких дел. Каталоги, визитки сервисы. Очень легко шаблоны натягивать, мощная и быстрая обертка над PDO. Единственной проблемой может оказаться Ext JS для админки: довольно сложный фреймворк. А так, - очень хороший движок.

    .   

  3.  

     


    Я проверю accessToken  if allright отдаю ему массив json со списком его друзей. Здесь кэш не играет никакого значения ( ну не о mysql кэшинге идет речь). Здесь render не требует больших ресурсов, ну никаких почти ресурсов он не требует.

    А, так тут понятно дело, что кэш не играет никакого значения. Согласен на 100%. Снимаю шляпу. 

  4. У вас кругозор веб-приложений заканчивается браузером, это думаю каждому понятно если что-то отдается в  браузер значит и рендериться будет.

    Вы занимались разработкой бэкенда для мобильных приложений ? Вот будете вы на плюсах его писать? 

    Ну ведь формируя ответ от сервера вы все равно что-то отдаете json, xml. Это ведь теже заголовки и боди. Это разве не рендер. Если под Бекендом вы подразумевали стенелоне приложение,  тут понятное дело. И то формы и т.д все равно отрисовываются.  

  5. везде где нет render-a перешли на node.js.

    Что значит "где нет render-a"? Если его нет, то возможно и не нужен веб фреймворк, а достаточно компилируемых языков. Если есть сайт, сервис, все что угодно, что должно отдаваться в браузер, тем или иным образом будет отрендерино в браузере. 

     

     

     

    Да Фреймворки используют много памяти, но зачем этого бояться?

     

    Совсем не обязательно. В зависимости от реализации. Реализация простой гостевой на Друпале или ВП будет намного больше кушать памяти, чем идентична на кодеигнитере, например. 

  6. В ДЛЯ пароли шифруются md5(md5('пароль'))

    Значит чтобы изменить, создайте какой то php файл, вставляем в него:

    $encripted_pass = md5(md5('Новый пароль который не забудете'));
    echo $encripted_pass;
    

    То что появится на экране вставляем в поле с паролем к вашему пользователю, и логинимся используя 'Новый пароль который не забудете'

  7. Шаблонизатор очень прост, хочу узнать у вас, всё ли хорошо?

     

    Файл index.php

    <?php
    
    include_once ('class.php');
    
    $content->set('{page_title}', 'Название нашей страницы');
    $content->set('{page_text}', 'Текст');
    
    $content->out_content('template.tpl');
    
    ?>

    Файл class.php

    <?php
    
    class content
    {
    
    var $vars = array();
    var $content = '';
    
    function set($name, $val) {
    $this->vars[$name] = $val;
    }
    
    function out_content($tpl) {
    $this->content = file_get_contents($tpl);
    
    foreach($this->vars as $key => $val)
    {
    $this->content = str_replace($key, $val, $this->content);
    }
    
    echo $this->content;
    }
    
    }
    
    $content = new content();
    
    ?>

    Файл template.tpl

    <!DOCTYPE html>
    <html>
    
    <head>
    <title>{title}</title>
    </head>
    
    <body>
    {text}
    </body>
    
    </html>

    Всё просто, но исходя из того, что я не знаю PHP хочу узнать у вас, всё ли хорошо или что-то исправить?

    Ваш шаблонизатор очень легко развить до такого. Отличная штука, сам юзаю.

  8. cms.ru.com попробуй эту

    опции небольшие, корзина товаров, модуль доствавки и скидки.

    Там пациент скорее мертв чем жив. Через полгода, когда придется что-то допиливать,  Вы залезете в код и будете матерится. 

  9. Если не учитывать Opencart, то Prestashop. ООП, читый код, огромное количество шаблонов и плагинов. Хотя, сомневаюсь что есть что-то проще Opencart'a. Simplacms Тоже ничего, но лицензия для маленького магазина может оказаться дороговатой. 

  10. @Anyue, подскажите пожалуйста по Мета Description. Ситуация сложилась следующая, что как правило, нужные(продвигаемые) ключи находятся в самом конце статьи и при генерации Мета Description посредством самого движка, в данный тег они(ключи) не попадают.Так вот вопрос, стоит ли переписывать этот момент, чтобы  ключи попадали в Мета Description или не обращать внимание? Так же приходит в голову мысль вообще не генерировать Мета Description, а пусть ПС сами формируют его? Спасибо

×
×
  • Create New...