Tworzenie struktury bazy danych na podstawie arkusza XML, budowa zapytania oraz bacenda do zarządzania tabelą |
Tworzenie struktury bazy danych na podstawie arkusza XML, budowa zapytania oraz bacenda do zarządzania tabelą |
9.04.2007, 09:26:49
Post
#1
|
|
Grupa: Developerzy Postów: 823 Pomógł: 12 Dołączył: 18.12.2005 Ostrzeżenie: (0%) |
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:
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 -------------------- Portfolio: Vgroup.pl | athlan.pl | Test.php.pl - sprawdź się z wiedzy o PHP i ułóż własne pytania!
Pomogłem? Kliknij pod postem. |
|
|
9.04.2007, 10:12:11
Post
#2
|
|
Grupa: Zarejestrowani Postów: 800 Pomógł: 0 Dołączył: 26.11.2005 Skąd: Nowy Sącz Ostrzeżenie: (0%) |
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. -------------------- Jah Music Is On My Mind !
|
|
|
9.04.2007, 14:22:30
Post
#3
|
|
Grupa: Developerzy Postów: 823 Pomógł: 12 Dołączył: 18.12.2005 Ostrzeżenie: (0%) |
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? -------------------- Portfolio: Vgroup.pl | athlan.pl | Test.php.pl - sprawdź się z wiedzy o PHP i ułóż własne pytania!
Pomogłem? Kliknij pod postem. |
|
|
9.04.2007, 14:41:33
Post
#4
|
|
Grupa: Zarejestrowani Postów: 246 Pomógł: 31 Dołączył: 13.11.2006 Skąd: się znamy? Ostrzeżenie: (0%) |
~turgon: z tego co widzę Athlan nie pisał o żadnym problemie...
Symfony dysponuje trzema rodzajami generatorów backend'a:
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 -------------------- Goldenline: Łukasz Rodziewicz
|
|
|
13.04.2007, 22:20:01
Post
#5
|
|
Grupa: Developerzy Postów: 823 Pomógł: 12 Dołączył: 18.12.2005 Ostrzeżenie: (0%) |
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? -------------------- Portfolio: Vgroup.pl | athlan.pl | Test.php.pl - sprawdź się z wiedzy o PHP i ułóż własne pytania!
Pomogłem? Kliknij pod postem. |
|
|
13.04.2007, 22:32:03
Post
#6
|
|
Grupa: Przyjaciele php.pl Postów: 7 494 Pomógł: 302 Dołączył: 31.03.2004 Ostrzeżenie: (0%) |
Możliwośc czystego php są większe (...) 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ł. |
|
|
13.04.2007, 22:52:54
Post
#7
|
|
Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) |
Cytat Niby tak, ale wygodniej trzymać konfigurację w XML. Dlaczego niby to jest wygodniejsze - bo ladniej wyglada ? -------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
14.04.2007, 06:20:10
Post
#8
|
|
Grupa: Developerzy Postów: 823 Pomógł: 12 Dołączył: 18.12.2005 Ostrzeżenie: (0%) |
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 -------------------- Portfolio: Vgroup.pl | athlan.pl | Test.php.pl - sprawdź się z wiedzy o PHP i ułóż własne pytania!
Pomogłem? Kliknij pod postem. |
|
|
14.04.2007, 10:26:46
Post
#9
|
|
Grupa: Zarejestrowani Postów: 493 Pomógł: 0 Dołączył: 14.06.2003 Skąd: Tomaszów Lubelski/Rzeszów Ostrzeżenie: (0%) |
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
-------------------- |
|
|
15.04.2007, 10:16:29
Post
#10
|
|
Grupa: Zarejestrowani Postów: 359 Pomógł: 1 Dołączył: 16.04.2006 Skąd: Łódź Ostrzeżenie: (0%) |
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ć ?
|
|
|
20.04.2007, 01:46:50
Post
#11
|
|
Grupa: Zarejestrowani Postów: 493 Pomógł: 0 Dołączył: 14.06.2003 Skąd: Tomaszów Lubelski/Rzeszów Ostrzeżenie: (0%) |
co jest takiego strasznego w tym złączaniu tabel? Bo jakos nie widze tu trudnosci...
-------------------- |
|
|
20.04.2007, 17:23:41
Post
#12
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
Propel. (...) 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ć ? 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. -------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
Wersja Lo-Fi | Aktualny czas: 24.04.2024 - 22:35 |