🚀 go-pugleaf

Dnia 05.08.2010 Stefan <stefan.py@onet.pl> napisał/a:
> Mam mały dylemat, bowiem jak umieszczam w projekcie django jakiś 
> dodatkowy kod, który np. robi mi miniaturki z obrazków, to umieszczam go 
> w katalogu głównym aplikacji i potem importuje sobie tam gdzie chce. Czy 
> jest jakiś katalog dedykowany dla dodatkowych "pluginów" w django, tak 
> jak np. vendors w CakePHP?

Dobrym pomysłem jest rozbijać wszystko w Django na możliwie małe aplikacje. Taki
moduł do skalowania obrazków, mimo że może nie mieć widoków ani modeli, też
potraktowałbym jak osobną aplikację.

-- 
Piotr Husiatyński

On 5 Sie, 18:49, Piotr Husiatynski <hu...@gmail.com> wrote:
> Dnia 05.08.2010 Stefan <stefan...@onet.pl> napisał/a:
>
> > Mam mały dylemat, bowiem jak umieszczam w projekcie django jakiś
> > dodatkowy kod, który np. robi mi miniaturki z obrazków, to umieszczam go
> > w katalogu głównym aplikacji i potem importuje sobie tam gdzie chce. Czy
> > jest jakiś katalog dedykowany dla dodatkowych "pluginów" w django, tak
> > jak np. vendors w CakePHP?
>
> Dobrym pomysłem jest rozbijać wszystko w Django na możliwie małe aplikacje. Taki
> moduł do skalowania obrazków, mimo że może nie mieć widoków ani modeli, też
> potraktowałbym jak osobną aplikację.
>
> --
> Piotr Husiatyński

Stefan
mozna rowniez stworzyc w katalogu glownym projektu, katalog: utils i
tam wrzucac dodatkowe katalogi i pliki np:

- katalog_glowny_projektu:
- - - utils
- - - - - - image
- - - - - - text
- - - - - - html

oczywiscie  ma byc to traktowane jako modul wiec w kazdym katalogu ma
pojawic sie plik: __init__.py

pozdrawiam

On 5 Sie, 15:13, Stefan <stefan...@onet.pl> wrote:
> Mam mały dylemat, bowiem jak umieszczam w projekcie django jakiś
> dodatkowy kod, który np. robi mi miniaturki z obrazków, to umieszczam go
> w katalogu głównym aplikacji i potem importuje sobie tam gdzie chce. Czy
> jest jakiś katalog dedykowany dla dodatkowych "pluginów" w django, tak
> jak np. vendors w CakePHP?

Jeżeli jest to plugin do django to tak jak napisano wcześniej,
w katalogu projektu.

Jeżeli są to dodatkowe biblioteki/skrypty, których używasz w django
ale nie są one od niego zależne (np biblioteka graficzna, itp)
to lepiej trzymać je obok projektu i łączyć w całość przy pomocy np
virtualenv, lub dodatkowo buildout'a.

Buildout posiada receptę dla django, która układa kod w katalogach
 * bin - kontrolery, np django (manage.py), test, pliki .fcgi i .wsgi
(wygenerowane automatycznie)
 * eggs - paczki w formacie egg
 * parts - biblioteki w postaci kodów źródłowych
 * django_projekt - projekt django (nazwa wybrana w konfiguracji)

tu jest przykładowa konfiguracja z jaką zaczynam pracę nad projektami:
 * http://github.com/onjin/django-buildout-template

On 5 Sie, 21:07, Sławek Tuleja <slawek.tul...@gmail.com> wrote:
> On 5 Sie, 18:49, Piotr Husiatynski <hu...@gmail.com> wrote:
>
> > Dnia 05.08.2010 Stefan <stefan...@onet.pl> napisał/a:
>
> > > Mam mały dylemat, bowiem jak umieszczam w projekcie django jakiś
> > > dodatkowy kod, który np. robi mi miniaturki z obrazków, to umieszczam go
> > > w katalogu głównym aplikacji i potem importuje sobie tam gdzie chce. Czy
> > > jest jakiś katalog dedykowany dla dodatkowych "pluginów" w django, tak
> > > jak np. vendors w CakePHP?
>
> > Dobrym pomysłem jest rozbijać wszystko w Django na możliwie małe aplikacje. Taki
> > moduł do skalowania obrazków, mimo że może nie mieć widoków ani modeli, też
> > potraktowałbym jak osobną aplikację.
>
> > --
> > Piotr Husiatyński
>
> Stefan
> mozna rowniez stworzyc w katalogu glownym projektu, katalog: utils i
> tam wrzucac dodatkowe katalogi i pliki np:
>
> - katalog_glowny_projektu:
> - - - utils
> - - - - - - image
> - - - - - - text
> - - - - - - html
>
> oczywiscie  ma byc to traktowane jako modul wiec w kazdym katalogu ma
> pojawic sie plik: __init__.py
>

Taki moduł dobrze jest jednak przedstawić django jako aplikację
(dopisać do installed_apps). W ten sposób utrzymamy możliwość spójnego
odpalania testów. Oczywiście, jeśli mowa o zewnętrznej bibliotece to
instalujesz ją zgodnie z zasadami sztuki (python setup.py install /
easy_install / pip install) - przy czym, jeśli tego jeszcze nie
robisz, bardzo fajnym pomysłem jest skorzystanie z virtualenv.

pozdrawiam,
Konrad

[OFF TOPIC]

> tu jest przykładowa konfiguracja z jaką zaczynam pracę nad projektami:
>  *http://github.com/onjin/django-buildout-template
0
Wow, fajny projekt. Na pewno mi się to kiedyś przyda.

Widzę, że pakujesz virtualenva do katalogu env. Też tak robiłem przed
jakiś czas, ale niedawno nawrócono mnie (:P) na virtualenv w kropce.
Co prawda dostajemy 3 katalogi (bin, lib, include) zamiast jednego,
ale nie trzeba się martwić czy aktywowaliśmy środowisko, tylko
wystarczy napisać bin/python (czy raczej bin/django do większości
zastosowań)

pozdrawiam,
Konrad

On 6 Sie, 13:24, konryd <kon...@gmail.com> wrote:
> [OFF TOPIC]
>
> > tu jest przykładowa konfiguracja z jaką zaczynam pracę nad projektami:
> >  *http://github.com/onjin/django-buildout-template
>
> 0
> Wow, fajny projekt. Na pewno mi się to kiedyś przyda.
>
> Widzę, że pakujesz virtualenva do katalogu env. Też tak robiłem przed
> jakiś czas, ale niedawno nawrócono mnie (:P) na virtualenv w kropce.
> Co prawda dostajemy 3 katalogi (bin, lib, include) zamiast jednego,
> ale nie trzeba się martwić czy aktywowaliśmy środowisko, tylko
> wystarczy napisać bin/python (czy raczej bin/django do większości
> zastosowań)

fajne, :) nie wpadłem na '.';

choć ostatnio zacząłem używać virtualenvwrapper +
virtualenvwrapper.project
i wszystkie env mam w ~/.venv skorelowane z katalogami projektów.

env i tak nie jest wrzucany do repo, żyje tylko lokalnie dla danego
build'a.

ale . fajna :)

Widzę że w django każdy ma własny sposób na strukturę katalogów w 
projekcie, nie ma czegoś "uniwersalnego" jak w przypadku np. Ruby On 
Rails gdzie od początku wiadomo co i gdzie ma się znaleźć.

On 12 Sie, 07:40, Stefan <stefan...@onet.pl> wrote:
> Widzę że w django każdy ma własny sposób na strukturę katalogów w
> projekcie, nie ma czegoś "uniwersalnego" jak w przypadku np. Ruby On
> Rails gdzie od początku wiadomo co i gdzie ma się znaleźć.

Tak, wedlug starej zasady python'a The Zen of Python:
There should be one-- and preferably only one --obvious way to do it.
;)

On 12 Sie, 07:40, Stefan <stefan...@onet.pl> wrote:
> Widzę że w django każdy ma własny sposób na strukturę katalogów w
> projekcie, nie ma czegoś "uniwersalnego" jak w przypadku np. Ruby On
> Rails gdzie od początku wiadomo co i gdzie ma się znaleźć.

jeśli chodzi o strukturę aplikacji w django to jest ustalona,
models.py, admin.py, templates/ templatetags/, itp.
Same aplikacje mogą być integralną częścią projektu, lub zostać
dostarczone przez osobną paczkę.

Nie wiem czy Rails'y pozwalają uruchomić aplikację dostarczoną przez
osobny gem - to by była analogia do podejścia w django/python. Ale na
pewno biblioteka używana przez Railsy może być w osobnym gemie,
zainstalowana per system lub per user czyli tez analogicznie w
pythonie może to być paczka w systemie lub w virtualenv/buildout.

On 12 Sie, 01:40, Stefan <stefan...@onet.pl> wrote:
> Widzę że w django każdy ma własny sposób na strukturę katalogów w
> projekcie, nie ma czegoś "uniwersalnego" jak w przypadku np. Ruby On
> Rails gdzie od początku wiadomo co i gdzie ma się znaleźć.

Czyżby jakiś mały flamik się szykował? ;)

Pozdrawiam

MJ

On 13 Sie, 10:36, Michał Jędryka <michal.jedr...@gmail.com> wrote:
> On 12 Sie, 01:40, Stefan <stefan...@onet.pl> wrote:
>
> > Widzę że w django każdy ma własny sposób na strukturę katalogów w
> > projekcie, nie ma czegoś "uniwersalnego" jak w przypadku np. Ruby On
> > Rails gdzie od początku wiadomo co i gdzie ma się znaleźć.
>
> Czyżby jakiś mały flamik się szykował? ;)

Proszę, nie.

Rzeczywiście jest odczucie, że Railsy bardziej narzucają strukturę
katalogów. Dokładnie opisują gdzie mają być modele, gdzie
wido^H^H^Hkontrolery, gdzie testy (jednostkowe/funkcjonalne/
integracyjne) i gdzie szablony. Funkcjonalności niezależne (dajmy na
to, obsługa OAuth) znajdują się albo w osobnych gemach albo w
pluginach (które też mają ściśle określone miejsce w projekcie).

Teraz Dajngo: określa gdzie mają być modele, ale nie mówi czy to ma
być jeden plik, czy pakiet. Określa gdzie mają być testy, ale nie
wnika w ich strukturę w żaden sposób (musi tylko być w stanie
wyciągnąć TestCase'y z modułu). Django określa gdzie mają być
dodatkowe bajery typu template_tagi, context_procesory, polecenia
management. Django *prawie* nie określa położenia szablonów, bo
zezwala na ułożenie ich pod lokacją określoną w settingsach, w
katalogach aplikacji, czy gdzie sobie ktoś życzy. Konsekwecją tego
jest fakt, że trzeba do tych settingsów zajrzeć żeby wiedzieć gdzie są
htmle, ale robi się to raz. Oczywiście aplikacje django mogą korzystać
z zewnętrznych bibliotek (PIL).

Różnica sprowadza się do podejścia "jeden projekt z pluginami" kontra
"garść aplikacji zebranych do kupy". Nie widzę zasadniczej przewagi
któregoś z nich nad drugim.

W dniu 2010-08-13 10:36, Michał Jędryka pisze:
> Czyżby jakiś mały flamik się szykował?;)

Żaden flamik. Po prostu zastanawiał mnie fakt, gdzie ładować statyczne 
pliki (js, css, pics) bo gdy się odpala serwer testowy, no to trzeba 
zdefiniować ścieżkę do tych plików, chyba że chce się mieć katalog z 
plikami w tym samym katalogu co pliki aplikacji.

No a właśnie w Railsach jest katalog public w którym się właśnie 
wszystkie te pliki umieszcza no i to jest niejako narzucone z góry.

Btw nie jestem jakimś fanboyem, po prostu miałem naleciałości z Railsów 
no ale ostatnio zakochałem się w Pythonie i Django - stąd moje niejako 
tendencyjne pytania :)