Witam

Ostatnio natchnęło mnie do napisania backenda podobnego do AdminGenerator jaki oferuje Symfony. Polegałby on na tym, że budujemy sobie strukturę bazy danych w formacie XML, po czym jesteśmy w stanie wygenerować z tego odpowiednie zapytanie do stworzenia bazy danych oraz formularza wraz z odpowiednim skryptem, który mógłby taką bazą zarządzać. Przykład budowy bazy danych jest następujący:

[XML] pobierz, plaintext 
<?xml version="1.0" encoding="UTF-8" ?>
 
<database>
  
  <table name="users" filds_prefix="user_" encoding="utf8_general_ci">
    <field name="id" auto_increment="on" encoding="utf8_general_ci">
      <type>int</type>
      <lenght>11</lenght>
      <default>0</default>
    </field>
    <field name="name" encoding="utf8_general_ci">
      <type>varchar</type>
      <lenght>32</lenght>
      <default>unknown</default>
      <comment>this is an user name</comment>
    </field>
    <field name="pass">
      <type>varchar</type>
      <lenght>32</lenght>
    </field>
  </table>
  
</database>
[XML] pobierz, plaintext 

Póki co to suche przemyślenia i rysowanie struktur. Ale ogólny zarys idei moge przedstawić. SimpleXML odczyta wszystkie tabele z bazy danych i przechowa je sobie jako obiekty Mapper_Table. Każde pole z tabeli zostanie zapisane i przeanalizowane przez obiekt Mapper_Field. Na podstawie zebranych informacji obiekt Mapper będzie dysponował pełnymi informacjami na temat bazy danych, co pozwoli mu prekazanie ich do wodoku i modelu w celu utworzenia/wyświetlenia zapytania oraz utworzenia formularza. Póki co mam plany w głowie, ale swoje opinie i przemyślenia już możecie przedstawiać. Z biegiem czasu będę prezentować to, co udało mi się napisać. Szeroki zakres dyskusji, obejmuje jeden z głównych korzeni mojego CMS'a, który będzie w pełni modularny.

Pozdrawiam, Athlan

Nie rozumiem w czym problem. Najprostszym sposobem, byłoby stworzenie czegoś w rodzaju generatora, która na podstawie typów pól organizowałbym odpowiednie typu pola, chyba, że ty byś w opisie definiował. Też ważnym byłoby definiowanie wartości defaultowych. Na tej podstawie parser by definiował Model, zawierający 5 metod (View, Add, Edit, Delete, ViewAll) - dodatkowe wariacje trzeba było ręcznie robić, do tego prosty kontroler, a co do szablonów to dziedziczy po jakimś standardowym, lub ma własny, dla którego podaje metodę, akcję oraz pola etc.

Mam nadzieję, że w miarę jasno to napisałem.

http://www.speedyshare.com/797797569.html

Już coś naskrobałem. Narazie demko tego, co chce mniej-więcej zrobić. Do formularzy dojdzie oczywiście tworzenie zapytań SQL. Jakieś pomysły co do sposoby przechowywania tych danych?

~turgon: z tego co widzę Athlan nie pisał o żadnym problemie...

Symfony dysponuje trzema rodzajami generatorów backend'a:

• init-crud
• generate-crud
• init-admin

Te z prefixem init są tworzone a potem przechowywane w cache. init-crud to taka łatwa do usunięcia alternatywa dla phpMyAdmin ( jak sami twórcy piszą ). generate-crud tworzy zbiór akcji wraz z prostymi tempatami do późniejszego dostosowania. Natomiast init-admin jest generowany na podstawie plików konfiguracyjnych w yaml i jest już prawie funkcjonalnym modułem administracji po odpowiednim skonfigurowaniu. Możliwości konfiguracyjne są "dość" szerokie > symfony admin generator reference card. Więcej o generatorach symfony tu.
Symfony jest mocno zintegrowane z orm ( tu dostosowany propel ) co znacząco ułatwia modyfikacje i dodawanie pól których nie ma w bazie danych. Pomyśl o tym

NuLL natchnął mnie, abym nie przechowywał konfiguracji w xml, tylko w php. Wgłębiająć sie w problem mozna stwierdzić, że to:
PHP: http://cpaste.com/352/php
będzie lepsze od tego:
XML: http://cpaste.com/353/xml

Możliwośc czystego php są większe, tak jak w przypadku z templatami w php i samarty, szybsze i więcej opcji (zauważmy, że smarty są pisane w php, a nie php w smarty )

Pola prechowywane by były w obiektach, możnaby było dopisac do nuch kryteria oraz komunikaty, które są wyświetlane po ich nie spełnieniu (php ma ta przewagę, że łatwiej dać np langi).

Co Wy o tym sądzicie?

To zależy
Niby tak, ale wygodniej trzymać konfigurację w XML.

Jeżeli wygodnie Ci mieć konfigurację w PHP i jednocześnie nie chcesz tracić elastyczności i przenośności jaką daje XML to trzymaj ją nadal w plikach .xml i dopisz banalny parser, który będzie Ci generował je do plików PHP a potem cacheował.

To jest najlepsze wyjście i ja bym się tego trzymał.

Dlaczego niby to jest wygodniejsze - bo ladniej wyglada ?

Ok, do czego zmierzam przez ten cały topick. Będę próbował zbudować CMS, który na podstawie własnie takiej struktury będzie budował instalator dla bazy danych i obsługiwał akcje add/edit/delete (dynamicznie tworzony model). Na podstawie taiej mapy będzie również budował odpowiednie zapytania oraz formularze, które będą mu potrzebne do zebrania danych oraz ich walidacji, przy czym jeżeli okażą się nieprawisłowe, wywali błąd. Wszystko super, ale ciągle po kolei natykam się na pewne problemy, z którymi w końcu daję radę, także za pomocą tej aplikacji będę mógł stworzyc klientowi kategorie, newsy i artykuły w 5 minut (tylo napisze sobie taką mapkę). Oczywiście każdy przycisk będzie miał templat brany z CMS'a, jeżeli mam ochotę sobie go jakoś inaczej przedstwaić, wówczas przypisuje mu mój templat znajdujący się w katalogu modułu. Czy użuwaliście takich rozwiązań oprócz tego co podał empathon? Jeżeli tak, to chętnie bym zobaczył, może podczas projektowania cos mnie natchnie do nowych możliwości

Athlan

xml jest o niebo wygodniejszy. Na poczatku byłem troche niechetny do tego, ale jak chciałem w samym php opisac dostepy do akcji to zwątpiłem. W xml'u wszystko wygodne i czytelne

Athlan, ok pomysł świetny, ale nie tak prosty jak sie wydaje Programiści wadli w sumie na napisanie czegoś takiego (prawie bo tworzy tylko sam model) i stworzyli projekt Propel. Nie mówię tutaj o tym, że próbujesz coś klonować tylko o tym, że nawet w tak potężnym narzędziu rozwijanym już od dość dawna istnieją pewne problemy (jak twierdzi splatch, Null - kiedyś rozmowa na irc'u. Sam nie wiem bo aż tak bardzo się nie wgłębiałem) związane z łączeniem Tabel (dość dużych tabel) - mowa tu o wszelkiego rodzaju JOIN'ach ;] Więc myślę, że to będzie największym problemem i co zamierzasz z tym zrobić ?

co jest takiego strasznego w tym złączaniu tabel? Bo jakos nie widze tu trudnosci...

Problemem nie są złączenia jako takie ale ich głębokość. Propel nie potrafi obsłużyć złączeń drugiego rzędu. To znaczy, że Author -> Book działa bez problemu, ale Author -> Book -> Comments generuje już dodatkowe zapytania (dla każdej książki!). Źródłem tych problemów jest konstrukcja Propela i metody hydrate, która jest generowana w każdej klasie. Operuje ona na obiekcie klasy ResultSet i przy pomocy indeksów numerycznych pobiera wartości kolumn, plus ewentualnie appenduje obiekty do innych relacji.

Obsługa dużych złączeń w ORMach jest wykonalna. Problemem może być tylko złożoność algorytmów użytych do tego a co za tym idzie i wydajność całości. Standardowo jest to O(n) = n*m, gdzie n to ilość rekordów a m ilość kolumn.