Новая тема   Ответить

 Proo
на пхп сделал такую вещь, напр в файле есть инклуд и код:

Код:

Переменная title инициируется в инклуде, но значение не сохраняет когда используется в файле, откуда вызывается инклуд. Вроде должно работать.. пробовал объявлять переменную перед include в этом же файле, где и вызывается, не помогло

Может нужно не .php а .inc файл инклудить, или еще что..

Последний раз редактировалось: Proo (23/04/09 в 14:30), всего редактировалось 1 раз

 webboxxx
так не будет работать. подключаемые скрипты нельзя через http грузить, только с файловой системы. http://ru2.php.net/include/

 -=Faraon=-
allow_url_include = On
В php.ini если включён то должно работать!

 -=Faraon=-
хотя переменную брать небудет всёравно с другого хоста. но подтянуть файл сможеш!

 oktan
Поможет комбинация

site.php на выходе должно выдавать
Код:


в этом случае
Код:

 Proo
Цитата:

там много переменных, не только тайтл..

как то сложновато..

все оценил, надесюсь еще варианты есть )

 ibiz
можно поизвращаться в этом духе
site.php на выходе должно выдавать Код:
echo $title."\n";
echo $title2."\n";
echo $title3."\n";

<?php
$f=file("http://somedomain.com/site.php?site=81");
$title=$f[0];
$title2=$f[1];
$title3=$f[2];
?>

переменные, они какбэ внутри сервера и передать их с одного сервера на другой невозможно без жеских извращений

можно еще вот так поизвращаться
site.php на выходе должно выдавать Код:
echo "$title:|:$title2:|:$title3";

<?php
$f=file("http://somedomain.com/site.php?site=81");
list($title, $title2, $title3) = explode(":", $f);

 Proo
Цитата:

Да уж

Еще хочу рассмотреть вариант подключения к БД вместо инклудов.. дело в том что запросы будут идти с разных хостов, а данные как бы на одном сервере..

Как думаете подлючение к БД с др. серверов нормальный вариант?

 ibiz
Proo писал:

нормальный, главное не забывать закрывать соединения

 Proo
Цитата:

че были прецеденты ?

 Sirgey
Вы где такую траву берёте....?

 Formator
Сделаешь allow_url_include = On и когда-нибудь встретишь утро с новостью о заломанном сервере. Нахуй такое советовать человеку - за такое руки надо отрывать.

Удалённый коннект к базе возможен, только не забудь привязать по ипу.

Для подобных вещей умные люди придумали протоколы типа SOAP. Если лень разбираться с этим, то передавай все нужные данные с помощью serialize и распаковывать с помощью unserialize. Т.е. на удалённом сервере делай:

Код:
а на клиенте:
Код:

Простейший вариант, тоже далеко не лучший.

 MoriArty
> Для подобных вещей умные люди придумали протоколы типа SOAP
+1

> serialize и распаковывать с помощью unserialize
кроме того, снабжаешь весь свой "кластер" приват/паблик ключами (или просто обычный симметричный ключ), и упомянутое выше утро, на некоторое время, произойдёт с отсрочкой ;)

зы: и вообще, имхо в ПЫХе много всякого кариеса от прошлых версий (типа ради совместимости) осталось... это не означает, что всё это можно использовать без последствий;)

 Dr.Syshalt
Formator писал:

Если php 5.2 - то лучше json. json_encode/json_decode. Все просто и куда надежнее.

 Sirgey
Formator +1, только как ты написал - нельзя - получается дыра для неопредёлённого кол - ва параметров.

Надо на стороне приёма:
list($title, $description, ...) = unserialize(file_get_contents("http://somedomain.com/site.php?site=81"));

либо, если совсем туго с пониманием процессов воспользоваться советом ibiz.

 dDan
дык пиши там просто $title = "blabla";
потом eval() юзай и все

 Sirgey
Цитата:

Нельзя так делать, уже писал постом выше почему. Хочешь передать стопку переменных - конкретизируй на стороне приёма какие именно переменные ты хочешь принять (а лучше и тип данных, если можно конечно).

 Sixty-nine.
спасибо поржал
скока кодеров развелось..

 MoriArty
Гы, чё вы ссоритесь ;)
В общем, ТС, если проблема ещё актуальна – тогда плиз конкретизируй: статические ли ИПы на всех хостингах, зависящих от централизованной БД, имеется ли возможность разрешать удалённый мускульный доступ на сервере где БД.
Если это всё true, то тогда делай так, как говорил ibiz, всё.
Если же что то из этого не выполняется, то ИМХО, в порядке простоты (но не эффективности):

1. метод с serialize (Sirgey + +, я цитировал только саму суть операций, естественно, extract это зло в данном случае)
2. xml-rpc/soap

Кстати, решение типа list($title, $description, ...), ИМХО так же не является достаточно правильным (разумеется, основываясь только на той инфе, которую предоставил ТС) так как является прямым примером жёсткой зависимости в архитектуре (всё-таки распределённая система ;) и избавиться от которой, можно например сведением зависимостей экспортирующей/импортирующих частей к одному транспортному интерфейсу. То есть все учавствующие в обмене стороны, знают интерфейс некоего Registry, реализующим методы типа setProperty($name, $value), getProperty($name), и возможно, умеющий самостоятельно сериализоваться/десериолизоваться… то есть, упрощённое подобие Transition Object. Ну или просто тупо ассоциативный массив по сети гонять ;)

То есть, поскольку до конца не ясны масштабы сети, нагрузки на БД, род запросов, универсальность базы (что там вообще - ферма сплогов, аутентификация, единная для всех сайтов "класстера") и т.д., кроме сериализации (без кеширования и прочих наворотов) ИМХО, слегка сложновато, НО! Если есть возможность конфигурировать удалённый доступ к мускулю на стороне сервера БД, юзай именно это… ИМХО ;)

~~~
правка: и т.д., РЕКОМЕНДОВАТЬ кроме сериализации (без кеширования и прочих наворотов) ИМХО,