Здравствуйте, товарищи!

Помогите, пожалуйста, разобраться со следующим вопросом.

Есть функция в классе, которая инклудит скрипты php из разных файлов.

Возможно ли сделать inlude так как будто include был сделан не из класса, а из самого документа?

т.е. есть класс Someclass

$someclass= new Someclass;

Все ключаемые скрипты тоже должны использовать $someclass, поэтому и возникает необходимость выполнить include как будто за пределами класса, иначе в функцию необходимо будет добаволять референсы на этот класс типа $someclass =& $this; , а этот вариант не очень удобен, т.к. заранее не известно как пользователь обзовет класс.


Заранее премного благодарен!

вообще могу на 100% уверить что проблема в проектировании а не в реализации.
вроде как так нельзя сделать, за то есть много других вкусностей.

Напротив, в проктировании все хорошо получается.
Все делается так, чтобы конечному пользователю было проще (просто написать вызов функции, а все остальное будет выполнять движок).

В JavaScript, например, можно сделать просто eval - скрипт выполнится относительно функции, в которой он вызван, или можно window.eval - выполнится относительно всего документа, таким образом функция будет доступна во всем документе. Собственно говоря, аналогичное мне необходимо сделать и в PHP, чтобы функция была доступна во всем документе, а не только в функции, где был сделан include.

А кто это у нас пользователь, который может писать php функции? Может пусть такой продвинутый пользователь попишет целые классы?

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

Хм..., возможно, лучше всего запоминаются собственные шишки 

Вот решение проблемы - "как позволить юзеру грязными лапами залезть в код":

- пропустить полученый от юзера текст через php с ключом t. Если php не выругался - молимся и вставляем этот код в специально обученый файл, который инклудится во внешнем блоке... Каждая такая вставка должна оформляться очень характеными блоками комментариев.

- пишем специальную приблуду для извлечения функций из этого самого специального файла, на случай если грязные лапы юзера все таки убили нашу систему...

Никакой юзер никуда же не полезет.
Это всего лишь модули для сайта, которые должны выполнять определенные функции. И другой человек, который использует эти модули не должен вникать в них, а просто должен вызвать функцию и получить результат в нужно месте.

Это сообщение отредактировал(а) anthonyBoard - 6.11.2008, 23:49

ksnk, на сколько я понял, под конечным пользователем anthonyBoard имеет ввиду PHP программиста пишущего какие-либо модули к его библиотеке/фреймворку/CMS/etc. И хочет сделать что-то вроде:

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

Вообще-то функции, как раз таки и не висят в классе, а висят в этом самом "везде".
Только переменную, описанную во включаемом файле будет довольно сложно выковырять без предобработки файла каким-либо парсером.

К примеру, если нам приспичит подключить, хотя бы и предложеным sTa1kEr'ом способом, файл такого содержания
, То функцию my_function можно вызвать из любого места далее по тексту. Сломается она только при выводе $xx. Чтобы углубиться еще дальше в это недоразумение, предобработка может быть, к примеру такой :


Писать-же классы вместо функций более кошерно, так как при использовании классов как-то не принято использовать глобальные переменные. Таким образом надобность в странной манипуляции с файлом-инклудом как-бы и отсутствует.

sTa1kEr, Мне показалось, что система ориентирована на пользователей, плохо знающих PHP. Вероятнее всего, они при этом недостаточно четко смогут себе представить что такое паттерны программирования 

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

Спасибо огромное за пример!

На счет бред это или нет, я просто всей картины не описал о том, что и куда, но судить все равно вам. У пользователя есть возможность объявлять и создавать свои экземпляры классов, просто есть несколько темплейтов, которые необдохидо заинклюдить, и к классам они никакого отношения не имеют. Дело все в том, что эти заинклюденные файлы используют тот же самый класс, который их и добавил.

Что-то мне кажется, что вы не поняли что мне надо в итоге.

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

Вот упрощенный примерчик напишу:

Класс

шаблон


и наконец исполняемый файл



Вот, думаю, теперь из примера понятно что должно быть. В классе инклюдится template, в котором используется тот же самый класс, который его инклюдил, но PHP таким образом его не увидит, если не добавить в функцию __construct() global $someclass - я бы так и сделал, но что если пользователь обзовет его не $someclass, а $cool (и в template соответственно) -тогда все полетит.

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

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

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

Долго объяснять все структуру движка, но она хорошо справляется со всеми задачами и все было прекрасно, но возникла необходимость в модификации, т.к. к одной странице может принадлежать один шаблон, а может два (один в другом), вот когда два как раз и приводит к кривому инклуду.

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

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

Этот пользователь должен просто написать $someclass->doit(); и получить результат, $someclass->dothat(); - и получить другой результат, а не дописывать какие-то еще условия, отсюда и возникает проблема, что инклуд должен делаться из функции класса и ни как иначе, к сожалению.

anthonyBoard, Ну, дык! Тогда sTa1kEr прав - действительно, singlton в зубы и на мины...




 

Эх.. Все это не красиво получается. Наверное придется разрабатывать новую структуру модулей. Выручают конечно глобальные переменные, но все равно есть свои подводные камни.

Прошу прощения за глупый вопрос, но с таковым никогда не сталкивался, поэтому и спрашиваю:
Каково время жизни переменной, которая была заинклудена из файла в функцию класса? Она проживет пока жив класс, или по окончанию выполнения функции помрет?

Просто если она будет жить пока жив класс, то можно инклудить всегда относительно одной и тойже функции класса.

Если "плохо знающие PHP" не смогут вызвать статический метод, то это не "плохо знающие PHP", а "абсолютно ничего знающие в PHP".


Ну так, а что тут мешает через $this обращаться? Посмотрите как сделаны View-контролеры в Zend Framework-e http://framework.zend.com/manual/en/zend.view.html 

А что ему мешает писать Someclass::getInstance()->doit(); ?


Как вы это себе представляете? Функция закончила свою работу, а локальные переменные остались? Хотя, если конкретные переменные объявить статическими, то они действительно будут доступны при следующем вызове функции.

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

Да, наверное я загнался конечно на какую-то идеальность. Ладно, если ничего хорошего по структуре не придет на ум, то пусть через $this обращаются или пусть global делают вначале include.

Спасибо всем, кто участвовал в дискуссии этого топика! Если у кого-нибудь буду еще какие идеи - буду раз их увидеть здесь! Еще раз спасибо!

Как на счет только чтобы все темплейты обхединять в один и делать потом eval? Т.е. в каждом темплейте будет содержаться какое-то обозначение типа "[TEMPLATE-2]" и будет заменяться кодом соответствующего темплейта из файла, а потом eval'ом все будет выполняться. Получается все переменные будут доступны на одном уровене, что и требовалось.
Как вам такая мысль?

Не будет ли это тормознутее, чем это делалось сразу include?

ну и другой вариант забить на все переменные, которые могут возникнуть во время выполнения определенного темплейта и заставить пользователя делать их global, если он планирует где-то дальше их использовать.

На счет eval еще не уверен вот в чем.. Не поплывет ли дебагер?

а как на счет smarty?

Добавлено через 41 секунду
И раздел тоже по итогу не верно выбран )) Для профи - это не то что надо )

Я подумал, что вопрос достоен профессиональных взгядов.
Смарти - тоже не то. Но вопрос можено снять, т.к. я начал перепроектирование и вроде проблем возникнуть не должно, за исключением вопроса о добавлении функции, который я задал в Общем разделе. К сожалению одно единственное предложенное решение - не то что я ожидал.

Всем спасибо за участие в этой теме!

К вопросу по теме! Если в php 5.3 будет namespace - то тогда станет возможным реализовать поставленную задачу изначально, я правильно понимаю?

module1.php

module2.php

main.php

Вывод: