Cytat
Nie do końca rozumiem co dokładnie chcesz stworzyć (to chyba przez to, że słowa plugin/moduł mają po 1000 znaczeń :]) ale...
Musze zaprojektować system ERP a właściwie podstawkę, którą można dowolnie rozszerzać. Taki system z reguły składa się z kilkunastu niezależnych od siebie elementów np. HR, work flow, crm. Elementy te są na tyle "duże", że zastosowanie zwykłego systemu pluginów odpada, dlatego pomyślałem aby pluginem mógł być pojedynczy moduł np.
Kod
modules
default
|-controllers
|-models
|-views
hr
|-controllers
|-models
|-views
|-plugins
crm
|-controllers
|-models
|-views
Na etapie projektowania tak rozbudowanego systemu nie jestem w stanie przewidzieć zależności pomiędzy poszczególnymi modułami np. Work Flow, może być użyty w CRM'ie, statystyki sprzedaży z CRM'a mogą być użyte w HR do generowania raportów, raporty z HR mogą być wykorzystane przez Work Flow itd. Sprawę dodatkowo komplikuje fakt, że moduły będą pisane przez zupełnie nie znanych mi programistów a więc system musi być przejrzysty, intuicyjny i przede wszystkim na tyle "łatwy" aby pisanie dodatkowych modułów nie była przeprawą rzez piekło.
Cytat
Odgórne narzucanie czegokolwiek lubi się mścić.
Pewnie tak
ale jakoś muszę udostępnić miejsca, w których klasa A będzie mogła zmienić model w klasie B bez ingerencji w kod (jeden z wymogów projektu..).
Cytat
1. Nadpisywanie niemal zawsze jest najgorszym sposobem rozszerzania o dodatkowe, potencjalnie niepowiązane funkcje.
4. Nawet się nie waż takich głupot robić.
5. Nie rozumiem co masz na myśli tutaj przez API (znowu, 1000 znaczeń tego słowa).
1. Teraz gdy zobaczyłem Twój przykład z dispatcherem to faktycznie nadpisywanie nie miało by sensu
4. Gdzieś widziałem przykład wykorzystania serializacji do zmian w strukturze klasy podczas aktualizacji i powiem ci, że byłem wniebowzięty takim podejściem do problemu ;P
5. API:
class CRM {
public function view() {
$api_wf = new API_WorkFlow();
$api_wf -> setId(1);
$raport = $api_wf -> getRaport() //-> generateCSV(); - dodatkowa metoda zmieniająca kontekst danych
}
}
class Model_WorkFlow {
public function getRaport() {
// zwraca obiekt raportu
}
public function setName($name) {
$this->entity->name = $name;
}
}
class Plugin_WorkFlow {
public function generateCSV() {
// zwraca string w formacie csv
}
}
class API_WorkFlow {
public function setId($id) { $this->id = $id; }
public function getRaport
($params=array()) {
//prosty przykład wykorzystania API
if(isset($params['view']) && $param['view'] == 'json') {
return new Model_WorkFlow_JSON($this->id);
}
else {
$model = new Model_WorkFlow();
return $model -> getRaport();
}
}
public function editName(Model_WorkFlow_RaportInterface $raport, $name) {
$model = new Model_WorkFlow($raport);
$model -> setName($name);
$model -> save();
}
}
$crm = new CRM();
$crm -> view();
W ten sposób mamy dostęp do zdefiniowanych w API metod bez bezpośredniego wywoływania modeli, kontrolerów itp. z innych modułów.
Cytat
W zależności od tego, jak solidne/rozbudowane narzędzie chcesz uzyskać, a: oprzyj to o zwykły menadżer zależności (np. PHP-owski Composer), b: nie mam pojęcia czy istnieje jakiś odpowiednik w PHP (pewnie nie), ale pogoogleaj za Java OSGi - bardziej za architekturą i sposobie działania.
Pogooglam dzięki za wskazówkę
Zmienne lokalne danej metody są na wyłączny jej użytek i nie powinny mieć wpływu na cokolwiek poza wnętrzem metody.
