Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

2 Stron V   1 2 >  
Reply to this topicStart new topic
> PHP preprocessor
hawk
post 20.04.2004, 16:13:11
Post #1





Grupa: Zarejestrowani
Postów: 521
Pomógł: 0
Dołączył: 3.11.2003
Skąd: 3city

Ostrzeżenie: (0%)
-----


Chodzi mi po głowie taki "preprocesor" albo "kompilator" do php. Hmm, wyobraźcie sobie że macie jakiś obiektowy systemik - powiedzmy kilkanaście klas, w tym interfejsy (PHP5). I chciałoby się wypuszczając oficjalną wersję tego systemiku wrzucić to wszystko do jednego pliku, bo i tak te klasy się nazwajem potrzebują. A interfejsy w ogóle nie są potrzebne - tylko ułatwiają pisanie - i można je całkowicie usunąć.

I uruchamiałoby się taki preprocesor, który mergowałby pliki, usuwał (niepotrzebne już) instrukcje require_once(...) itd. Sprawa nie jest prosta, bo preprocesorowi trzeba jakoś powiedzieć, co ma do czego przerzucić, a co zostawić w spokoju. No i nie może on absolutnie pogubić się i wprowadzać do kodu nowe błędy.

Czy takie coś może istnieje? Czy to jest w ogóle dobry pomysł?
Go to the top of the page
+Quote Post
seaquest
post 20.04.2004, 17:09:16
Post #2





Grupa: Przyjaciele php.pl
Postów: 790
Pomógł: 7
Dołączył: 6.02.2003
Skąd: Polska

Ostrzeżenie: (0%)
-----


IMHO pomysł ciekawy, ale nieopłacalny. Załóżmy, że system składa się z kilkudziesięciu klas, ale przecież nie zawsze wszystkie są potrzebne, czasami nie musisz używać wszystkich klas, a parser to przetwarza (niestety) i tracisz potrzebne sekundy....


--------------------
Michał Płachta
Warsztat: Mac OS X Leopard, PostgreSQL, Text Mate, Retrospectiva + SVN
Go to the top of the page
+Quote Post
Nalfein][WR
post 20.04.2004, 18:37:26
Post #3





Grupa: Zarejestrowani
Postów: 66
Pomógł: 0
Dołączył: 22.04.2003
Skąd: Żory / K-ce

Ostrzeżenie: (0%)
-----


Właśnie dlatego ten prekompilator musiałby być konfigurowalny tj. mieć jakiś plik wejściowy z listą klas i na podstawie tych klas załadować wybrane pliki, oczyścić z komentarzy, zbędnych instrukcji wg. gdzieś w ustawieniach wprowadzonych regexów, a następnie scalić generując docelowy plik .php biblioteki. Ale jest też druga strona medalu - w plikach, które używały dotychczas klas includując pojedyncze pliki także należałoby pozmieniać wywołania, albo w jakiś sposób powiązać nazwę klasy z nazwą biblioteki, ale to wymaga ingerowania w __autoload bądź wyprowadzenia dodatkowego obiektu do ładowania klas.


--------------------
Gadu-Gadu: 3909164
Go to the top of the page
+Quote Post
hawk
post 20.04.2004, 18:37:41
Post #4





Grupa: Zarejestrowani
Postów: 521
Pomógł: 0
Dołączył: 3.11.2003
Skąd: 3city

Ostrzeżenie: (0%)
-----


Hmm, ja zakładam że:
1) preprocesor odpalam sobie tylko raz, u siebie, zanim wypuszczę na zewnątrz gotową wersję (a wersja z wieloma plikami mogłaby nazywać się "debug")
2) wiem które klasy są potrzebne zawsze a które od czasu do czasu, i łączę ze sobą tylko te, które i tak będą musiały być zawsze wczytywane

To powoduje, że trzeba jakoś poinformować parser, co wolno mu mergować sad.gif
Go to the top of the page
+Quote Post
Nalfein][WR
post 20.04.2004, 20:12:31
Post #5





Grupa: Zarejestrowani
Postów: 66
Pomógł: 0
Dołączył: 22.04.2003
Skąd: Żory / K-ce

Ostrzeżenie: (0%)
-----


No jakoś trzeba. Ja wykorzystuję swój generator kodu wbudowany we framework, który odczytuje pliczek XML-owy ze "składnikami" i robi na jego podstawie gotowy "posiłek" dla interpretera w postaci pliczku php. Zmiana przepisu pociąga za sobą rekompilację. Użytkownik dostaje samo menu - klasy w osobnych plikach, ale przy pierwszym odpaleniu zostanie zrobiony cache.

U mnie pliczek źródłowy wygląda tak:

  1. <?codegen use="php-cache"?>
  2. <cache>
  3.  <part>
  4.        <source path="./core/Object.php" />
  5.      <class>Object</class>
  6.  </part>
  7.  <part>
  8.      <source path="./core/Worker.php" />
  9.      <class>Worker</class>
  10.  </part>
  11.  <part>
  12.        <source path="./core/Component.php" />
  13.      <class>Component</class>
  14.  </part>
  15.  <part>
  16.        <source path="./util/List.php" />
  17.      <class>List</class>
  18.  </part>
  19.  <part>
  20.        <source path="./util/Map.php" />
  21.      <class>Map</class>
  22.  </part>
  23.  <part>
  24.        <source path="./application/Application.php" />
  25.      <class>Application</class>
  26.  </part>
  27.  <part>
  28.      <source path="./application/CustomApplication.php" />
  29.      <class>CustomApplication</class>
  30.  </part>
  31.  <part>
  32.        <source path="./application/PaladineFramework.php" />
  33.      <class>PaladineFramework</class>
  34.  </part>
  35. </cache>


Procesor wyciąga klasy po regexach. Bardzo proste, a spełnia swoje zadanie.


--------------------
Gadu-Gadu: 3909164
Go to the top of the page
+Quote Post
Nalfein][WR
post 20.04.2004, 20:17:31
Post #6





Grupa: Zarejestrowani
Postów: 66
Pomógł: 0
Dołączył: 22.04.2003
Skąd: Żory / K-ce

Ostrzeżenie: (0%)
-----


serafin - to zarzuć może nazwą...

Argument co do czasu wykonywania jest chybiony. Operacja przecież będzie wykonywana tylko przy zmianach projektu.


--------------------
Gadu-Gadu: 3909164
Go to the top of the page
+Quote Post
e-Gandalf
post 20.04.2004, 21:31:22
Post #7





Grupa: Przyjaciele php.pl
Postów: 195
Pomógł: 0
Dołączył: 7.07.2003
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Hawk: jej! :DDDDD Wiem, ze to niewiarygodne, ale myslalem swego czasu o czyms identycznym. Dokladnie o "kompilacji"/"kompresji".
Zalety? Liczne.

1) Mieszacz kodu. Uzyskujemy efekt zblizony do kompilacji i uwierzcie - wlasciwie niemozliwy do rozkodowania (przy uzyciu rozsadnych srodkow)
2) Zmniejszenie includow - jak wszyscy wiemy include i require to wlasciwie najwezsze gardla kazdej aplikacji
3) usuniecie komentarzy w wersji "produkcyjnej", a jak wiemy, dobrze udokumentowany plik potrafi zawierac wiecej komentarzy niz kodu smile.gif

Ja za, ale moze po Tothu smile.gif


--------------------
"(...)Zrozumienie wymagaloby od Ciebie odrobiny pokory. A dzis, w dobie
obalania autorytetu i udowadniania, ze doswiadczenie jest niepotrzebnym
balastem, to jest niemodne.(...)"
Go to the top of the page
+Quote Post
hawk
post 20.04.2004, 21:56:53
Post #8





Grupa: Zarejestrowani
Postów: 521
Pomógł: 0
Dołączył: 3.11.2003
Skąd: 3city

Ostrzeżenie: (0%)
-----


Taki preprocesor może bardzo dużo zrobić minimalnym kosztem, naprawdę...
1) Wycinanie komentarzy - zero regexpów, wbudowany tokenizer, idzie jak burza
2) wycinanie białych spacji - w PHP5 jest do tego jedna funkcja
itd...

@Nalfein: czy twój generator kodu potrafi wyciąć niepotrzebne już require_once i inne takie? Bo generalnie to co napisałeś to mniej więcej to o co mi chodzi - podaje się w jakimś pliku, jakie pliki ma sparsować, i wypluwa jeden scalony plik.

Ja bym jeszcze bardzo chciał wywalić z pliku "produkcyjnego" interfejsy, bo prawie zawsze nie są one potrzebne do poprawnej interpretacji (chyba że ktoś używa instanceof, ale ja zamiast tego zawsze class type hints w definicji metody, i tutaj można je wyciąć).

@serafin:
A da sie to zrobić jakimś preprocesorem C? awkiem? nie wiem... Takie coś musiałoby rozumieć chociaż trochę kod php.
Go to the top of the page
+Quote Post
wojtek
post 21.04.2004, 14:22:22
Post #9





Grupa: Zarejestrowani
Postów: 80
Pomógł: 0
Dołączył: --

Ostrzeżenie: (0%)
-----


To ja jeszcze wtrace swoje dwa grosze - nie wiem czy znacie moze taka aplikacje jak POBS http://pobs.mywalhalla.net/. Najprostsza rzecza jaka robi to wlasnie usuwanie bialych znakow, lecz zmienia ona takze nazwy zmiennych, funkcji itd na nieczytelne. Jest to dosyc skomplikowane zadanie, autorzy sami pisza ze po zastosowaniu skryptu trzeba naniesc kilka zmian czy poprawek. Napisanie takiego pre-processora byloby dosyc trudne i trzebaby przewidziec mnostwo sytuacji - jesli jednak udaloby Ci sie cos takiego napisac, mysle ze byloby to bardzo przydatne narzedzie.
Go to the top of the page
+Quote Post
e-Gandalf
post 21.04.2004, 16:24:34
Post #10





Grupa: Przyjaciele php.pl
Postów: 195
Pomógł: 0
Dołączył: 7.07.2003
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Cytat
Byc moze nie zrozumialem troche idei... Jesli ma to wygladac w ten sposob, ze wg listy plik scala je w calosc to jest to chybiony pomysl. Czemu ? Skad "preprocessor" bedzie wiedzial ze includujac plik akcji ma go pominac (bo jest przeciez zmieniany dynamicznie) czy tez tworzyc bedzie xxxx scalonych plikow dla kazdej z akcji ? Myslicie ze taki "inteligentny" parser da sie napisac ?


Tak. Zauwaz, ze o ile faktycznie czesc rzeczy musi pozostac jako "moduly" to czesc moze zostac wlaczona. W mnoim przekonaniu, dobry programista piszac obiektowa aplikacje zazwyczaj tworzy po jednym pliku na kazda klase. Jesli zatem jadro sklada sie z 10 klas (baza danych, uprawnienia, szablony, cache, costam) i kilku plikow glownych (index.php, main_lib.php) - do tego kilku klas prymitywnych, abstrakcyjnych i kilku interfejsow to w wersji produkcyjnej mozna by to zlaczyc w jeden plik, oszczedzajac kilkunasty include/require (i na dodatek wywalajac interfejsy/klasy abstrakcyjne). Oczywiscie pewnei trzeba by jakos zaznaczyc "twarde" includy, ktore maja zostac includami, ale mysle, ze na koncu zamiast 100 plikow mozna by miec plik index.php (jadro) i kilka-kilkanascie modulow ladowanych w zaleznosci od potrzeb.


--------------------
"(...)Zrozumienie wymagaloby od Ciebie odrobiny pokory. A dzis, w dobie
obalania autorytetu i udowadniania, ze doswiadczenie jest niepotrzebnym
balastem, to jest niemodne.(...)"
Go to the top of the page
+Quote Post
e-Gandalf
post 21.04.2004, 17:50:17
Post #11





Grupa: Przyjaciele php.pl
Postów: 195
Pomógł: 0
Dołączył: 7.07.2003
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


No, pisalem przeciez:

"Oczywiscie pewnei trzeba by jakos zaznaczyc "twarde" includy, ktore maja zostac includami" smile.gif


--------------------
"(...)Zrozumienie wymagaloby od Ciebie odrobiny pokory. A dzis, w dobie
obalania autorytetu i udowadniania, ze doswiadczenie jest niepotrzebnym
balastem, to jest niemodne.(...)"
Go to the top of the page
+Quote Post
Nalfein][WR
post 21.04.2004, 19:22:01
Post #12





Grupa: Zarejestrowani
Postów: 66
Pomógł: 0
Dołączył: 22.04.2003
Skąd: Żory / K-ce

Ostrzeżenie: (0%)
-----


hawk: nie, na odwrót. Zamiast usuwać require_once wycina klasy o podanych identyfikatorach z plików źródłowych i umieszcza w wynikowym. Jeśli tamte klasy potrzebują innych to należy je dołączyć manualnie w pliku konfiguracyjnym.


--------------------
Gadu-Gadu: 3909164
Go to the top of the page
+Quote Post
hawk
post 21.04.2004, 19:32:52
Post #13





Grupa: Zarejestrowani
Postów: 521
Pomógł: 0
Dołączył: 3.11.2003
Skąd: 3city

Ostrzeżenie: (0%)
-----


Cytat
To ja jeszcze wtrace swoje dwa grosze - nie wiem czy znacie moze taka aplikacje jak POBS http://pobs.mywalhalla.net/. Najprostsza rzecza jaka robi to wlasnie usuwanie bialych znakow, lecz zmienia ona takze nazwy zmiennych, funkcji itd na nieczytelne.

POBS jest ciekawą aplikacją, i nie znałem wcześniej :wink: . Ale tak na oko widać, że ma on poważne wady, spowodowane nie brakiem umiejętności twórcy, tylko tym, że POBS powstał, gdy php nie dysponował funkcjonalnością znakomicie ułatwiającą tego typu zadania.

Przykłady, wzięte ze strony programu:
- POBS ma drobne problemy z wycinaniem komentarzy, a tokenizer czyni to dziecinnie prostym
- POBS myli czasami nazwy stałych z tagami HTML, a tokenizer nie ma z tym problemu
- POBS ma duże trudności ze zmiennymi typu $$nazwa, a za pomocą tokenizera można je łatwo rozpoznać
- POBS, wycinając spacje, potrafi popsuć kod HTML, a PHP5 (jak zakładam) zrobi to dobrze

O obsuscatorze nie myślałem, ale może kiedyś...
Go to the top of the page
+Quote Post
enceladus
post 21.04.2004, 19:57:09
Post #14





Grupa: Zarejestrowani
Postów: 127
Pomógł: 0
Dołączył: 19.11.2003
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Dyskusja przybrała taką formę, że mogę śmiało stwierdzić że pewne postawione tu wymagania spełnia MMCache: kompiluje plik tekstowy php do bytecodu a podczas tego procesu kod jest oczyszczany. Jedynie nie parsuje include-ów.

Update: Oczywiście wymaga ingerencji w apache'a


--------------------
Enceladus
Warsztat: bez warsztatu
Aktua
Go to the top of the page
+Quote Post
hawk
post 21.04.2004, 23:07:46
Post #15





Grupa: Zarejestrowani
Postów: 521
Pomógł: 0
Dołączył: 3.11.2003
Skąd: 3city

Ostrzeżenie: (0%)
-----


@Nalfein:
Aaaaaa, sprytne smile.gif . Chociaż wtedy jest pewne ryzyko, że "zgubi się" jakieś define(...) i takie, umieszczone poza klasą. Ale w PHP5, mając nowe słowo kluczowe const, stosuję raczej zasadę "jeden plik = jednak klasa i nic poza klasą".

@enceladus:
MMCache też robi z tego tyle plików, ile było na początku. Chociaż nie znam zasad działania na tyle dobrze, aby stwierdzić, czy weźmie pliki z bytecodem z dysku, czy będzie je trzymał w pamięci. Ciekawe, jaka dla MMCache jest różnica pomiędzy 10 plikami, a 1 plikiem powstałym ze sklejenia tamtych. W sensie szybkości, oczywiście.
Go to the top of the page
+Quote Post
LoPMX
post 10.07.2004, 20:48:52
Post #16





Grupa: Zarejestrowani
Postów: 15
Pomógł: 0
Dołączył: 25.11.2003
Skąd: Białe Błota

Ostrzeżenie: (0%)
-----


Wydaje mi sie, ze lepie byloy taki preprocesor wykorzystac do wydawania release aplikacji. powiedzmy wersja release i debug. wypuszczajac wersje release, preprocesor: obcina komentarze, dalej usuwa wszystko np. pomeidzy #ifdef DEBUG / #endif. Powiedzmy w tym bloku bylyby jakies dodatkowe logi itd potrzebne programiscie a nie w koncowym produkcie.


--------------------
Go to the top of the page
+Quote Post
Jabol
post 10.07.2004, 21:05:38
Post #17





Grupa: Przyjaciele php.pl
Postów: 1 467
Pomógł: 13
Dołączył: 22.02.2003

Ostrzeżenie: (0%)
-----


a może coś jak w C? Można by było nawet # zostawić jako rozpoznawacz komend preprocesora

Kod
<?php
#ifdef VERSJA_FINALNA
#include "klasa.class.php"
#else
require_once "klasa.interfejs.php";
require_once "klasa.class.php";
#endif // VERSJA_FINALNA
?>
i potem tylko
$ convert --in plik.php --out finalna.php -D VERSJA_FINALNA
Albo napisać język do opisu różnych akcji. Coś np. jak
Kod
outfile $klasa "finalna/$1.class.php"
from "klasa.class.php" import * without [includes('*.interface.*')] to $klasa('klasa')
Albo coś w tym stylu i potem tylko interpreter.

Drugi sposób ma tą wadę, że trzeba by było napisać jeszcze conajmniej podstawowy parser php.
Go to the top of the page
+Quote Post
bela
post 28.03.2005, 02:45:39
Post #18


Administrator PHPedia.pl


Grupa: Developerzy
Postów: 1 102
Pomógł: 2
Dołączył: 14.09.2003

Ostrzeżenie: (0%)
-----


Stary topic, ale co tam, nie będę nowego zakładać :]

Co sądzicie o czymś takim ? :]
  1. <?php
  2. function dump($dump) {
  3. print('<pre>');
  4. var_dump($dump);
  5. print('</pre>');
  6. }
  7.  
  8. $files = array(
  9.  'dirs' => array(''),
  10.  'disabled_dirs' => array(''),
  11.  'files' => array(''),
  12.  'disabled_files' => array(''),
  13. );
  14. //dump($files);
  15.  
  16. function getFiles($dir) {
  17. $aFiles = array();
  18. foreach($dir as $d) {
  19. $rd = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( $d ), true );
  20. foreach ($rd as $file) {
  21. if(!$file->isDir() && end(explode('.', $file)) == &#092;"php\") {
  22. $aFiles[] = $file->getPathname();
  23. }
  24. }
  25. }
  26. return $aFiles;
  27. }
  28.  
  29. $rf = array_diff(getFiles($files['dirs']), getFiles($files['disabled_dirs']));
  30. $rf = array_merge($rf, $files['files']);
  31. $rf = array_merge(array_diff($rf, $files['disabled_files']));
  32. //dump($rf);
  33.  
  34. $bigFile = null;
  35. foreach($rf as $file) {
  36. $buff = php_strip_whitespace($file);
  37. // highlight_string($buff);
  38. $buff = preg_replace( array('/^(<?php|<?)/', '/?>$/'), array('', ''), $buff);
  39. //dump($buff);
  40. $bigFile .= $buff;
  41.  
  42. }
  43. $bigFile = '<?php '. $bigFile . ' ?>';
  44. //highlight_string($bigFile);
  45. file_put_contents('merged.php', $bigFile);
  46. ?>


Konfiguracja poprzez tablice $files


--------------------
Go to the top of the page
+Quote Post
hawk
post 29.03.2005, 15:20:10
Post #19





Grupa: Zarejestrowani
Postów: 521
Pomógł: 0
Dołączył: 3.11.2003
Skąd: 3city

Ostrzeżenie: (0%)
-----


Fajny przykład, i dobrze pasuje do dyskutowanego ostatnio autoloadera winksmiley.jpg. Ja bym z tego oczywiście zrobił klasę. I zrobiłbym system pluginów do tej klasy, pobierających tekst pliku i zwracających przetworzony tekst pliku. Np. plugin usuwający komentarze, wycinający whitespace, itd. I takie pluginy można łączyć w łańcuszek - co po kolei ma być zrobione.

Albo inny pomysł - łańcuch przetwarzania powinien mieć postać: input -> processing -> output. Tzn. niech będzie interfejs odpowiedzialny za dostarczanie contentu - np. pobierając z pliku, pobierając z listy plików, itd. Drugi interfejs/klasa to główne przetwarzanie i obróbka zagregowanego contentu. A na koniec interfejs zapisujący wynik obróbki. Taki pipeline pozwala na elastyczne dopasowywanie do potrzeb i dopisywanie nowej funkcjonalności.

Najlepiej byłoby opracować coś takiego i wydać razem z autoloaderem...

edit: Coraz bardziej podoba mi się pipeline. Można nawet pójść trochę w stronę Cocoona: zrobić sobie drzewko przetwarzania, gdzie na wejściu (liść) jest input, na wyjściu (korzeń) output, a w środku cokolwiek - agregacja, filtrowanie, wycinanie komentarzy, itd.
Go to the top of the page
+Quote Post
bela
post 10.04.2005, 01:01:57
Post #20


Administrator PHPedia.pl


Grupa: Developerzy
Postów: 1 102
Pomógł: 2
Dołączył: 14.09.2003

Ostrzeżenie: (0%)
-----


Cytat(hawk @ 2005-03-29 15:20:10)
Fajny przykład, i dobrze pasuje do dyskutowanego ostatnio autoloadera winksmiley.jpg. Ja bym z tego oczywiście zrobił klasę. I zrobiłbym system pluginów do tej klasy, pobierających tekst pliku i zwracających przetworzony tekst pliku. Np. plugin usuwający komentarze, wycinający whitespace, itd. I takie pluginy można łączyć w łańcuszek - co po kolei ma być zrobione.

No ba, już jest gotowe winksmiley.jpg
  1. <?php
  2. class PreProcessor {
  3. private $plugins;
  4. private $config;
  5. private $fileContent;
  6. private $files;
  7. public function __construct() {
  8. }
  9.  
  10. public function start () {
  11. $this->files = $this->getF($this->config);
  12. $this->loadFiles();
  13. $this->processPlugins();
  14. }
  15.  
  16. private function getFiles($dir) {
  17. $aFiles = array();
  18. foreach($dir as $d) {
  19. $rd = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( $d ), true );
  20. foreach ($rd as $file) {
  21. if(!$file->isDir() && end(explode('.', $file)) == &#092;"php\") {
  22. $aFiles[] = $file->getPathname();
  23. }
  24. }
  25. }
  26. return $aFiles;
  27. }
  28.  
  29. public function setConfig($aConfig) {
  30. $this->config = $aConfig;
  31. }
  32.  
  33. public function getConfig () {
  34. return $this->config;
  35. }
  36.  
  37. public function setPlugins($aPlugins) {
  38. $this->plugins = $aPlugins;
  39. }
  40.  
  41. public function getPlugins () {
  42. return $this->plugins;
  43. }
  44.  
  45. private function getF($aF) {
  46. $rf = array_diff($this->getFiles($this->config['dirs']), $this->getFiles($this->config['disabled_dirs']));
  47. $rf = array_merge($rf, $this->config['files']);
  48. $rf = array_merge(array_diff($rf, $this->config['disabled_files']));
  49. return $rf;
  50. }
  51.  
  52. private function processPlugins() {
  53. foreach($this->plugins as $k => $v) {
  54. $plugin = new $v;
  55. $this->fileContent = $plugin->process($this->fileContent);
  56. }
  57. }
  58.  
  59. private function loadFiles() {
  60. foreach($this->files as $k => $v) {
  61. $this->fileContent[$v] = file_get_contents($v);
  62. }
  63. }
  64.  
  65. private function getFileContent() {
  66. return $this->fileContent;
  67. }
  68.  
  69. public function setFileContent($content) {
  70. $this->fileContent = $content;
  71. }
  72.  
  73. public function save($dir = null) {
  74. foreach($this->fileContent as $k => $v) {
  75. file_put_contents($dir . $k, $v);
  76. }
  77. }
  78. }
  79.  
  80. class comments {
  81. function __construct() {
  82. }
  83.  
  84. function process($files) {
  85. foreach($files as $k => $v) {
  86. $files[$k] = php_strip_whitespace($k);
  87. }
  88. return $files;
  89. }
  90. }
  91.  
  92. function dump($dump) {
  93. print('<pre>');
  94. var_dump($dump);
  95. print('</pre>');
  96. }
  97.  
  98. $files = array(
  99.  'dirs' => array(''),
  100.  'disabled_dirs' => array(''),
  101.  'files' => array(''),
  102.  'disabled_files' => array(''),
  103. );
  104.  
  105. $pre = new PreProcessor();
  106. $pre->setConfig($files);
  107. $pre->setPlugins(array('comments'));
  108. $pre->start();
  109. $pre->save('new/');
  110. print 'Hehe, udalo sie preprocesorawac kod;)';
  111. ?>


Cytat
Albo inny pomysł - łańcuch przetwarzania powinien mieć postać: input -> processing -> output. Tzn. niech będzie interfejs odpowiedzialny za dostarczanie contentu - np. pobierając z pliku, pobierając z listy plików, itd. Drugi interfejs/klasa to główne przetwarzanie i obróbka zagregowanego contentu. A na koniec interfejs zapisujący wynik obróbki. Taki pipeline pozwala na elastyczne dopasowywanie do potrzeb i dopisywanie nowej funkcjonalności.

Najlepiej byłoby opracować coś takiego i wydać razem z autoloaderem...

edit: Coraz bardziej podoba mi się pipeline. Można nawet pójść trochę w stronę Cocoona: zrobić sobie drzewko przetwarzania, gdzie na wejściu (liść) jest input, na wyjściu (korzeń) output, a w środku cokolwiek - agregacja, filtrowanie, wycinanie komentarzy, itd.

Możesz bardziej łopatologicznie napisać ;]


--------------------
Go to the top of the page
+Quote Post

2 Stron V   1 2 >
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.11.2019 - 08:22