Każdy rozwiązuje problem w inny sposób, tym razem chodzi mi o Applet.

W moim przypadku applet musi mieć dostęp do bazy danych i jakiegoś szablonu, czyli modelu i widoku. Takie same prawa ma wówczas Controller. Moj kontroler wygląda mniej wiecej tak:

[PHP] pobierz, plaintext 
<?php
 
abstract class Vcontroller implements VcontrollerInterface
{
	protected $_aData = array();
	protected $_oView = NULL;
	protected $_oConfiguration = NULL;
 
	final public function __set($sName, $sValue)
	{
		$this->_aData[$sName] = $sValue;
	}
 
	final public function __get($sName)
	{
		return (isset($this->_aData[$sName]) ? $this->_aData[$sName] : NULL);
	}
 
	final public function setView($sName)
	{
		$sViewPatch = Vframe::patchView($sName);
		$sViewClass = $sName . V_APP_SURFIX_VIEW;
 
		if(!Vframe::isUsable($sViewPatch))
			throw new VcontrollerException('View "'.$sName.'" does not exists (file "'.$sViewPatch.'" passed)!');
 
		require_once($sViewPatch);
 
		if(!class_exists($sViewClass, FALSE))
			throw new VcontrollerException('Class of view "'.$sViewClass.'" does not exists in file "'.$sViewPatch.'"!');
 
		$oViewObject = new $sViewClass;
 
		return $oViewObject;
	}
 
	final public function setModel($sName)
	{
		$sModelPatch = Vframe::patchModel($sName);
		$sModelClass = $sName . V_APP_SURFIX_MODEL;
 
		if(!Vframe::isUsable($sModelPatch))
			throw new VcontrollerException('Model "'.$sName.'" does not exists (file "'.$sModelPatch.'" passed)!');
 
		require_once($sModelPatch);
 
		if(!class_exists($sModelClass, FALSE))
			throw new VcontrollerException('Class of model "'.$sModelClass.'" does not exists in file "'.$sModelPatch.'"!');
 
		$oModelObject = new $sModelClass;
 
		return $oModelObject;
	}
 
	final public function getApplet($sName, $sAction = NULL)
	{
		$sAppletPatch = Vframe::patchApplet($sName);
		$sAppletClass = $sName . V_APP_SURFIX_APPLET;
		$sAppletAction = (($sAction) ? $sAction : V_APP_DEFAULT_ACTION) . V_APP_SURFIX_ACTION;
 
		if(!Vframe::isUsable($sAppletPatch))
			throw new VcontrollerException('Applet "'.$sName.'" does not exists (file "'.$sAppletPatch.'" passed)!');
 
		require_once($sAppletPatch);
 
		if(!class_exists($sAppletClass, FALSE))
			throw new VcontrollerException('Class of Applet "'.$sAppletClass.'" does not exists in file "'.$sAppletPatch.'"!');
 
		$oAppletObject = new $sAppletClass;
 
		if(!method_exists($oAppletObject, $sAppletAction))
			throw new VcontrollerException('Applet method "'.$sAppletAction.'" does not exists in class "'.$sAppletClass.'" ('.$sAppletPatch.')!');
 
		ob_start();
 
			$oAppletObject->$sAppletAction()->display();
 
			$sAppletContents = ob_get_contents();
 
		ob_clean();
 
		return $sAppletContents;
	}
 
	public function getConfig($sConfigName = NULL)
	{
		if(!$this->_oConfiguration instanceof VconfigPattern)
		{
			$oConfig = new Vconfig();
 
			$sCurrentConfig = ($sConfigName) ? $sConfigName : get_class($this);
 
			if(!Vframe::isUsable(Vframe::patchConfig($sCurrentConfig)))
				return NULL;
 
			if(!$oConfig->hasConfig($sCurrentConfig))
				$oConfig->setConfig($sCurrentConfig, $sCurrentConfig, FALSE, FALSE);
 
				$this->_oConfiguration = $oConfig->getConfig($sCurrentConfig);
		}
 
		return $this->_oConfiguration;
	}
}
 
?>
[PHP] pobierz, plaintext 

Gdyby się głebiej zastanowić, mój applet zbudowany byłby z kontolera i akcji. Fajnie jakby nie wyświetlał danych z szablonu, ale je zwracał. Postanowiłem więc zrobić takie coś:

[PHP] pobierz, plaintext 
<?php
 
abstract class Vapplet extends Vcontroller
{
	public function display()
	{
		return;
	}
}
 
?>
[PHP] pobierz, plaintext 

Applet dziedziczy z kontrollera ale nie wyswietla danych (specjalnie mam funkcję display() która jest w modelu, bo tak jest wywoływany szablon akcji w dispatcherze.

zwróćmy jeszcze raz uwagę na odpalenie appletu w akcji:

[PHP] pobierz, plaintext 
<?php
final public function getApplet($sName, $sAction = NULL)
	{
		$sAppletPatch = Vframe::patchApplet($sName);
		$sAppletClass = $sName . V_APP_SURFIX_APPLET;
		$sAppletAction = (($sAction) ? $sAction : V_APP_DEFAULT_ACTION) . V_APP_SURFIX_ACTION;
 
		if(!Vframe::isUsable($sAppletPatch))
			throw new VcontrollerException('Applet "'.$sName.'" does not exists (file "'.$sAppletPatch.'" passed)!');
 
		require_once($sAppletPatch);
 
		if(!class_exists($sAppletClass, FALSE))
			throw new VcontrollerException('Class of Applet "'.$sAppletClass.'" does not exists in file "'.$sAppletPatch.'"!');
 
		$oAppletObject = new $sAppletClass;
 
		if(!method_exists($oAppletObject, $sAppletAction))
			throw new VcontrollerException('Applet method "'.$sAppletAction.'" does not exists in class "'.$sAppletClass.'" ('.$sAppletPatch.')!');
 
		ob_start();
 
			$oAppletObject->$sAppletAction()->display();
 
			$sAppletContents = ob_get_contents();
 
		ob_clean();
 
		return $sAppletContents;
	}
?>
[PHP] pobierz, plaintext 

przypisanie tego jest równie proste:

[PHP] pobierz, plaintext 
<?php
class index_Vcontroller extends Vcontroller
{
	public function index_Action()
	{
		$oView = $this->setView('example');
 
		$oView->menu = $this->getApplet('menu_example');
 
		return $oView;
	}
}
?>
[PHP] pobierz, plaintext 

U mnie poki co wygląda to w zaprezentowany sposob.

Jak wygląda to w Waszych frameworkach?

Po co grzebiesz się w takie applety ? Ja po prostu do każdego dorzucam generowanie bloków. Pobranie ich, a potem w szablonie jako tablica

jak dla mnie to dobre rozwiązanie... potrzebuje tego w moich aplikacjach

btw: a subtemplaty? ja w widoku do metody display() dorzuciłem sobie możliwość wpisania nazwy templatu do wykonania, a następnie zwrócenia przez ob_get_content() + return mi tak wygodnie... no i praktycznie

pozdrawiam, Athlan

Może tak ci powiem. Robisz inny szablon includujesz i wiO !

u mnie to dziala tak:

[PHP] pobierz, plaintext 
<?php
public function display($sTemplate = NULL)
	{
		if($sTemplate)
			$sRender = $sTemplate;
		else
		{
			if(!isset($this->_sTemplate))
				throw new VviewException('Template has no specified!');
 
			$sRender = $this->_sTemplate;
		}
 
		$sTemplatePatch = Vframe::patchTemplate($sRender);
 
		if(!Vframe::isUsable($sTemplatePatch))
			throw new VviewException('Template "'.$sTemplatePatch.'" does not exists!');
 
		ob_start();
 
			require_once($sTemplatePatch);
 
			$sContents = ob_get_clean();
 
		return $sContents;
	}
?>
[PHP] pobierz, plaintext 

Po co takie zamotanie ? Można to dużo łatwiej zrobić.

Stopien waszej pracowitosci jest imponujący

[HTML] pobierz, plaintext 
<plugin:calendar>
[HTML] pobierz, plaintext 

Tak wyglada umieszczenie plugina w szablonie widoku Kazdy plugin to klasa zawierajaca metode perform i tyle

BTW: Kto wpadl na nazwe aplet

Turgon - w Mojavi tak to nazwali sie chlop zafascynowal

Prph... A ja mu tłumaczę, że to bzdura.

Ja nazwalem to Applet, widac innym nazwa sie spodobala Dlaczego Applet? Bo mi pasowala nazwa, a innej nie znalem.

NuLL dobrze prawi, jak powinno sie uzyc pluginu/apletu. IMHO, to widok, a raczej szablon powinien wywolac aplet, tj. umiescic go gdzie trzeba. Ja rozwiazalem to nastepujaco:

1. widok posiada helpery w posiacie metod, np: url(atrybuty) generujacy link, applet do wczytania apletu.
2. Applet ma podobna, ale nie taka sama funkcjonalnosc jak kontroler. Ma dostep do widokow, modeli i niech robi, co chce.

Jak koms sie chce, niech zajrzy do Rapide (link w sygnaturze).

Pozdrawiam, Adrian.

A ja się ciekawiłem jak wykorzystać. Obejrzałem rapide literce po literce i jest super. Ale daj jakieś zastosowanie Apletów i Helperów ;]

Witam,

Helpery uruchamiane są z szablonów, jak zwykłe metody obiektu $this:

[HTML] pobierz, plaintext 
<a class="button" href="<?= $this->url('User', 'Add') ?>">Dodaj</a>
[HTML] pobierz, plaintext 

W tym przykładzie: helper URL. Generuje poprawny url (tj. zgodny z routerem) z podanych argumentów: kontrolera, akcji i tablicy asocjacyjnej parametrów.

Jak wspomniałem, dostępny jest helper, który ładuje aplet:

[PHP] pobierz, plaintext 
<?= $this->applet('Menu') ?>
[PHP] pobierz, plaintext 

Helper Menu może wyglądać następująco:

[PHP] pobierz, plaintext 
<?php
 
class View_Applet_Menu extends Rapide_View_Applet
{
  public function execute()
  {
	if(!$this->getUser()->isAuthenticated())
	  return;
 
	$oView = $this->getView('Applet');
	$oView->setTemplate('AppletMenu');
 
	return $oView->fetch();
  }
}
 
?>
[PHP] pobierz, plaintext 

Jak widać, sprawdza, czy użytkownik jest zalogowany. Jeżeli tak - zwróci zawartość menu w postaci kodu HTML. Aplety mogą korzystać z widoku oraz modelu. Dziedziczą z ogolnej klasy:

[PHP] pobierz, plaintext 
<?php
 
abstract class Rapide_View_Applet implements Rapide_View_Applet_Interface
{
  public function getController();
  public function getAction();
 
  public function getParameters();
  public function getParameter($sParameter);
 
  public function getConfig();
 
  public function getView($sView);
  public function getModel($sModel);
 
  public function getUser();
  public function getLanguage();
}
 
?>
[PHP] pobierz, plaintext 

Pozdrawiam, Adrian.

Prph... ano super pomysł, z poziomu szablonu... hmmm, w sumie to by mi było wygodniej

btw słyszałem gdzieś "applet" spodobało mi się i tak nazwałem tą funkcjonalność w moim frameworku, komuś się coś niepodoba? Jak zwał tak zwał, ważne ocb...

no to ide kodzić