JTable - что это? - Разработка расширений для Joomla 2.5

почему бы все не писать или в JTable, или в JModel

http://ссылка вырезана, так как домен распространяет вирусы/blog/joomla/klass-jtable-v-joomla

уже прочитал много статей с Вашего сайта Я понять не могу, зачем мы использовали этот класс в примере с HelloWorld. Без него же и так в модели можно таскать данные из бд. А тут мы целый класс определяем для всего одной таблицы.

$table = $this->getTable('table_name');
$table->bind( array ('title'=>'text', 'created'=>date('Y-m-d H:i:s'), 'text'=>'lala' ) );
$table->strore(); 

$table = $this->getTable('table_name');
$table->hit(10); 

вы очевидно ещё не очень хорошо знаете ООП)

просто получается что мы можем работать с одиночной записью в табличке как с объектом!

$db = JFactory::getDBO();
$query = $db->getQuery(true);
$query->select('id, greeting, ordering');
$query->from('#__helloworld');

public function seeIt($a=1)
	{	
		return $a;
	}

$table = $this->getTable('helloworld');		
$table->seeIt();
return $table;

$a = HelloWorldModelHelloWorlds::seeIt();
var_dump($a);

Т.е. вместо этого кода, где мы каждый раз создаем запрос к БД

Код: php

$db = JFactory::getDBO();
$query = $db->getQuery(true);
$query->select('id, greeting, ordering');
$query->from('#__helloworld');

мы используем методы, которые уже есть + те которые мы написали сами/переопределили. И можем без запроса получать, например, все строки, или строку по ID, или весь столбец записать в массив, если создать такой метод.

function __construct( &$db )	{
		parent::__construct( '#__content', 'id', $db ); // вот тут второй парамерт
	}

а скажите пожалуйста вот что. сейчас все больше встречается написание запросов в виде

Код

$query = $db->getQuery(true);
$query->select('id, greeting, ordering');
$query->from('#__helloworld');

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

и второй вопрос: как используя такой принцип выполнить например ALTER TABLE ?

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

представляю. давайте посмотрим...

в том то дело что вы не представляете

    *
    * @param   mixed   $conditions  A string or array of where conditions.
    * @param   string  $glue        The glue by which to join the conditions. Defaults to AND.
    *                               Note that the glue is set on first use and cannot be changed.

   public function where($conditions, $glue = 'AND')
   {

переходить на такую форму записи стоит!

То бишь мы не сформируем сложное условие где будет и AND и OR - для объединения берётся только первый оператор.

пока только минусы:
1. Самое главный минус - ограниченные возможности.
2. Так себе минус, которым можно пренебречь, но все таки - медленее.
3. И вообще не минус - вопрос удобства. Просто дело привычки. Кому то удобнее, кому то нет. Но даже если этот пункт считать плюсом - то первые 2 перекрывают его полезность полностью.

банальный импорт как вы говорите отлично писался и без использования стиля $query->where.. никакой путаницы, никаких неудобств. просто как я уже сказал - пункт 3 - дело привычки.
итого извините, но фразазвучит мягко говоря чересчур громко

То бишь мы не сформируем сложное условие где будет и AND и OR - для объединения берётся только первый оператор.

$query->where('(published=1 OR published=2) AND id IN(1,2,3,4,5)');

Вот когда методы JDatabaseQuery более-менее будут соответствовать потребностям - можно будет ими пользоваться в полной мере.

А мне вот нужен весьма удобный REPLACE, которого нет там.

а зачем Replace что то не пойму? что он будет заменять? и для UPDATE проще юзать JTable!

Ну разумеется.
Вместо того чтобы один раз сформировать запрос REPLACE лучше конечно делать как в ядре J - сначала сформировать запрос SELECT, а потом по условию - если найдено, то UPDATE, а если не найдено - то INSERT

хм.. а примеры где вы это использовали можно?

Да взять тот же импорт данных в базу c синхронизацией по уникальному ключу.
Вместо того чтобы сначала через запрос SELECT выяснять есть ли запись в базе, чтобы решить что использовать - INSERT или UPDATE, можно использовать один запрос REPLACE - тогда в случае наличия записи она будет обновлена, в случае отсутствия - создана.

я не думаю что он пришел сюда что бы ему объяснили чем такой подход лучше

1. какие именно ограниченные возможности?

2. ну если вы сильно гоняетесь за скоростями то может не стоит смотреть в сторону CMS и PHP вообще?)

3. с помощью конструктора запросов удобнее составлять запросы ) их проще читать и отследить что где и когда! и ошибиться сложнее!

сделать класс в котором из разных методов вы вручную создадите запрос

вас никто убеждать не собирается использовать конструктор запросов, но думаю вам и CMS тогда стоит сменить, ибо в Joomla в везде натыканы зыпросы которые формируются с помощью конструктора, если недайбог придется дорабатывать сторонний компонент вы можете и повиснуть )

ALTER TABLE. REPLACE. Добавить таблицу в конце концов при установке компонента.

не стоит преувеличивать и утрировать. потеря скорости должна быть оправдана. тем более как я уже сказал - этим можно пренебречь.

опять таки, как я уже сказал, дело вкуса и привычки. но все удобство сводится к нулю из-за п.1

расширить JDatabaseQueryElement чтоли? или вы о чем? так нах зачем мне такой класс, который еще и расширять надо, вместо того чтобы писать запросы привычно?

мне показалось, или вы это так легонько камень бросили? причем тут разбор чужих расширений? каждый пишет как ему удобно. кому то удобнее с конструктором - да пожалуйста. надо будет разобраться - разберусь. я спрашивал исключительно в разрезе своих. да/нет. вышло, что нет. поскольку, как сказал SDKiller, методы JDatabaseQuery далеко не полностью соотвествуют всем потребностям. Соотвественно, полностью отказаться от "старой" записи не получится. А комбинировать не вижу смысла. Ибо создаст еще большую путаницу. Это в принципе как раз то, для чего я и пришел - понять до конца - можно (нужно) / нельзя (не нужно).