Nella CMS – než bude offiko fórum

kdyz sosnu dev verzi z githubu a zkusim ji tak hned vyhodi error
tak me jen zajima jestli to je umysl nebo mam psat co to vyhazuje

resp mela by byt nella po nastaveni configu a importovani db funkcni?

EDIT:
tak to je zase moje demence, ale mozna by bylo fajn pri prvnim hledani modulu pri neexistenci jedineho zaznamu vyhodit nejakou exception
ted je tam v Nella.php:173

<?php
if (!isset($cache['classes']))
		{
			$cache->save('classes', $cls, array(
				'expire' => "+2days",
				'tags' => array("modules", "routes")
			));
		}
?>

kdyz nejsou moduly tak neni $cls

Editoval despiq (1. 2. 2010 11:48)

v6ak napsal(a):

Pravda, co jiného po programátorech můžeš chtít, aby po tobě chtěli?

To by ses divil že i programátoři nemusejí nutně chtít jenom framework.

despiq napsal(a):

kdyz sosnu dev verzi z githubu a zkusim ji tak hned vyhodi error
tak me jen zajima jestli to je umysl nebo mam psat co to vyhazuje

Je dobré když stahuješ DEV verzi přečíst si README… :-)

ted je tam v Nella.php:173 … kdyz nejsou moduly tak neni $cls

Fixed

mue napsal(a):

Ad směrování:
CMS Framework je potřeba mít určitě, aby zastřešoval jednotlivé moduly(články, ankety..) a případnou komunikaci s nimi(pokud mám nainstalovaný/povolený modul anket, tak se mi při zakládání článku objeví možnost provázat jej s anketou – např.).

Jede o to jestli se držet pouze hranice frameworku nebo jí překročit (viz další možnosti)

Rozdělení pro BFU/velké CMS Tohle dělení se dá udělat právě přes moduly (můžu mít „lehký“ modul pro články a vedle toho „moster“ modul s milionem nastavení atd)

No ono to není zase tak úplně pravda, protože u BFU nemůžeš mít miliardu možností (jinak by se stratil), které jsou naopak u „velkého“ CMSka potřeba.

Důležíté je ovšem kam chce sám autor Nellu směrovat. Pokud na blogy a menší stránky, tak určitě BFU verzi.

Autor se právě ptá kam potencionální uživatelé chtějí aby Nella byla směrována.

Pokud na větší a firemní weby, tak kombinace CMS Framework + základní sada lehce konfigurovatelných a upravitelných modulů.

Což je ve výsledku to co nazívám „velkým“ CMS. S tím že by existovalo něco jako https://addons.nette.org akorát s moduly pro CMSko

samozřejmě snadné vytvoření nového modulu(pokud je jeho cílem aby Nellu využívaly i webdesignerská studia). My u každého zákazníka (projektu) vždy nějaký modul upravujeme dle jeho požadavků, takže by se na to mělo myslet již v návrhu.

Tohle je už na základní úrovni „vyřešeno“ dnes. Mluvil jsem o tom při přednášce na Poslední Sobotě.

Díky za názory/nápady/nalezené chybky a těším se na smršť dalších.

Editoval vrtak-cz (1. 2. 2010 18:16)

Ondřej Mirtes napsal(a):

Na Nellu se podívám, až k ní budu mít přístup (na GitHubu vidím akorát readme a licence)

Stačí se přepnout do DEV větve (upozorňuji že se jedná o pre-alpha verzi)

Dobře, možná to byla trošku nadsázka, ale minimálně tendence to IMHO vyjadřuje dobře.
Řešení jako BFU CMS a velké CMS bych nechal spíš v podobě distribucí ala Linux. Koneckonců, když moduly budou mít jasné hranice, bude se i lépe týmovat (hlavně spontánněji – radši forkuješ, nebo píšeš modul?) a i spravovat.

Když bych chtěl nové CMSko na kterém můžu stavit weby… hmm… klientů (což je mi jako freelancerovy model nejbližší). Tak bych chtěl vyřešenou administraci článků, stránek + počítám, že už kvůli té administraci by tam byla správa rolí. Pak několik přibalených modulů např. pro správu souborů. A zbytek je v podstatě volný; můžeš modul vytvořit a dát ho do nějakého NellaStore ;o)

Ale to záleží na tom, jestli máš Nellu navrženou jako „poslepuj si sám v administraci“ :o) Jestli ne, tak by asi bylo třeba uvažovat jinak :o)
(Pro ty moduly: Osobně se mi třeba líbí systém eventu ve wordpressu, ale vždycky mi to přišlo tak trochu nedořešené – např. že nejsou všechny zastřešené pod nějakou třídou, ale to už je OT).

Editoval OndrejSlamecka (1. 2. 2010 22:12)

Par dalsich poznatku

slovicko: publish/unpublish misto publicate/unpublicate

zajimalo by me co je Slug

minuly cas od save je saved
minuly cas od mark je marked

pri klikani na delete nebo publish se nejdriv zobrazi nejake js okno s adresou, to by tam asi byt nemelo

a ted k zakladnim modulum
tlacitko add new vpravo nahore mi prijde trosku schovane, dal bych ho i nekam bliz do predpokladane cesty oci
pridavani usera vyhodi fatal error, ted nevim jestli moji vinou

<?php
Class 'Nella\Core\Auth\Models\Users' not found
File: F:\www\nella\libs\Nella\Core\Auth\Backend.php   Line: 561
?>

na gitu ten model taky nevidim

image list je fajn ale nejak ho propojit s ckeditorem by bylo jeste hezci, pripadne alespon zobrazit cestu ktera se musi zkopirovat do ckeditoru, i kdyz to je dost krkolomne a strcit tam nejaky fancybox
nicmene predpokladam ze by se to melo strcit spis do modulu pages aby to bylo v ramci jednoho modulu
v editaci stranky je to jasne az po tlacitko save, pod ni uz to jasne neni bylo by hezke dam tam alespon nadpis napr: Older versions

na Dashboardu by se mi libilo mit moznost si vzit nejakou funkci a strcit ji do boxu na dashboard, tak abych mohl na dashboardu prohlize napr stranky, zaroven obrazky, zaroven strukturu webu nebo treba nejaky komentare proste mit vse na prohlizeni co budu chtit hned na predni strance a mit to ve stylu web 2.0 boxiku ktere jdou pretahovat cili jquery ui nebo neco jineho noa ukladat to do db ke kazdemu userovi aby si to nemusel pokazde znovu nastavovat

nechci pusobit jako ze si napovidam jak to chci a ty to udelas, ber to pouze jako muj nazor ktery muzes ale take vubec nemusis vzit v podtaz a tim mam na mysli vsechny me poznamky k nelle

moc si cenim tve prace a rad se budu podilet na tvorbe modulu

Hoj, tak jsem si konečně našel trochu času a jak jsem slíbil na PS, tak píšu:

Předně, kam Nellu směřovat:
CMS pro BFU i Klasické „velké“ CMS už tu máme, takže bych se rozhodně ubíral směrem, kde může Nette pomoci a to je vlastní vývoj nových modulů. Takže za mě, něco mezi CMS Frameworkem a Klasickým CMS. Co tím myslím? Při zálkadní instalaci jej půjde použít jako blog, nebo jednoduchý firemní web, pokud bude cokoliv potřeba dodělat, bude jednoduché si dopsat vlastní modul. Tady všechno záleží na dobrém návrhu, aby dopsat modul bylo opravdu snadné (Nette to celkem usnadňuje, ale bude to potřeba velmi dobře rozmyslet, aby to bylo dostatečně univerzální, ale zase ne moc).

No a teď co bych chtěl za funkce. Spravuji několik webů postavených na Drupalu, takže za mě to budou požadavky, na které jsem si zvykl na Drupalu + věci, které bych chtěl vyřešit lépe.

Uživatelská oprávnění

Na většině webů mám pouze pár rolí (max 5), ale často je tam mnoho uživatelů, takže nápad, který zazněl na PS, že se oprávnění budou přiřazovat kopírováním od nějakého existujícího uživatele mě nenaplňuje štěstím, protože poměrně častý požadavek je, že celé roli upravuji oprávnění. Naopak jsem se nesetkal s požadavkem, že by bylo práva pro jednotlivé uživatele dělit natolik jemně, že by role překážely. Takže já hlasuju pro role. Co se týče dědění rolí, o kterých jsem taky na PS mluvil, tak jsem si to nechal trochu rozležet v hlavě a došel jsem k názoru, že to je kanón na vrabce (kolik těch rolí budeme mít?), takže já to rozhodně nepotřebuju.

Správa obsahu

Tady nevyhnutelně potřebuju, aby byla možnost několika druhů vstupů (např. Filtrované HTML, plné HTML a PHP – jako to má Drupal). Vím, že to přináší několik problémů, ale v situacích, se kterými jsem se setkal to bylo často potřeba. Co se týká používání přímo PHP přes eval() – vím, že to je prasárna, ale například vypsání data na stránce pro mě neznamená vyvíjet nový modul, ale pouze přepnout typ vstupu.

Dále potřebuju, aby šlo realizovat několik modelů uživatelských oprávnění.

1. uživatel může vše
2. uživatel může přidávat stránky a editovat pouze své. (Zde by se hodila volba, zda je může zveřejnit, nebo pouze vytvořit)
3. uživatel může dělat vše v sekci na kterou má právo (ve firmě je z každého úseku vybrán člověk (nebo více), který se stará o sekci na webu)

Přímo u editace stránky by měla být volba zda a kam ji zřadit do stromu menu.

Všechny stránky musí být bezpodmínečně verzovány.

Bloky

Nevím, jak to bude nazváno v Nelle, ale je dobré, aby i uživatel mohl měnit pozici jednotlivých bloků na stránce (do předem vyhrazených částí – např. halvička, levé menu, tělo, pravé menu, patička), aby když se rozhodně, že chce menu místo vpravo doleva, aby se nemuselo šahat do zdrojáků. Hezky je to třeba v Drupalu, nebo ještě lépe to měl pepakriz v CMS, které ukazoval na PS.

Vzhled

Zde bych potřeboval nějaký systém přepínatelných vzhledů webu, aby se u každé stránky/sekce dal zvolit vlastní vzhled (buď stačí CSS, nebo lépe celý .phtml soubor)

Vyhledávání

Alespoň trochu rozumné.

Pár nesetříděných bodů k budoucímu zamyšlení

• Multijazyčnost celé aplikace / jednotlivých stránek
• Log všeho
• + možná přibudou další…

Neříkám, že všechno tam musí být, nebo že to všechno musí programovat vrtak-cz, jsou to jenom funkce, které já na webech často používám a přijdou mi užitečné.

Každopádně díky za Nellu :)

P.S.: Tak to byl můj nejdelší příspěvek tady.

To plné HTML, PHP apod. je IMHO zralé na vlastní modul. PHP lze řešit i jinak než přes eval, ale chtělo by to ukládat mimo DB.
K serializaci:

1. Nikdy dopředu neznáš všechny třídy čeho jsou schopny. Třeba si představ třídu pracující s dočasným souborem, který je v destruktoru smazán. Pokud by se někdo dostal k DB a třída by byla „správně“ naprogramována, mohl by smazat libovolný soubor.
2. Pokud serializace nebude omezena na určitý okruh tříd (např. v Javě jsem viděl v jedné knihovně omezení na jeden ClassLoader), znamená to určité riziko.
3. Mám totiž takovou zásadu, že obsah DB by měl mít co nejmenší možnosti ovlivnit věci mimo DB (HTML výstup, PHP skripty, …). Je na každém, jaké riziko uzná za vhodné (pokud někdo chce modul na PHP články, tak prosím, ale nedával bych ho do jádra).

Ještě dodám jeden svůj nápad: administrace modulů (nahrání, povolení, zakázání, …) apod. není u frameworku IMHO důležitá. Pokud někdo bude chtít udělat CMS distribuci, ať tam na to přidá modul, ale v základu to být nemusí.

Mám na vás pár otázek a tak jsem udělal dvě ankety http://twtpoll.com/0m90f4 a http://twtpoll.com/5fu3rh prosím hlasuje zabere to pár vteřin.

vrtak-cz napsal(a):

Druhy vstupu

Tohle jsem si taky nechal rozležet v hlavě a jo asi by to šlo, ale rozhodně se mě nechce tam dělat ten eval , takže asi bude spíš možnost Latte a některých jeho maker.

Eval používají i Latte pro spouštění kódu v omezeném kontextu :) Každopádně mi to je jedno, jak to bude fungovat, když tím půjde docílit toho co potřebuju.

Revize

Je už teď. Pořád jsem si ale lámal hlavu s mazáním. Až mě napadl Globální Trash (serializovane objekty/pole v DB asi)

Pozor na závislosti mezi objekty. Třeba obnovení stránky by mělo buď obnovit i záznam v menu, nebo ho aspoň vyNULLovat.

Bloky

Tohle mě leží v hlavě asi nejvíc. Bohužel jsem neměl možnost s Pepou pokecat protože nás vykoply. (Pepo pokud tohle čteš ozvy se odkud jsi když tak se extra sejdeme na pivo)

Zkus se podívat, jak to mají v Drupalu. Pepa to měl tak, že se jednotlivé bloky daly přetahoval přímo Drag&Dropem po stránce (do vyhrazených částí), dále se mohly vnořovat (to Drupal neumí, takže neumím odhadnout jaký bude index užitečnosti / náročnosti implementace) a přímo u každého bloku vyvolat JavaScriptem editaci parametrů.

Vyhledávání

Tohle je průser největší… Nevím jak na to systémově… Kvuli modulům… (Komponenta na Google Custom search mě nepřipadá jako řešení problému)

To ani mně. Šlo by to udělat třeba tak, že každý obsahový objekt by musel implementovat nějakou metodu, která vrátí textový obsah (třeba využít __ToString) a potom nějaký modul může tyhle textové informace indexovat a vyhledávat v nich.

Log

Bude ale rozmýšlím jemnost kvůli filtrování

Ideálně logovat datum, modul, vážnost, text a uživatele.

Když už, tak bych to viděl na nějaké ISearchableModule. Metoda search($text) je otázka, možná by bylo lepší přispívat do nějaké tabulky.

No jo, ale pak spojovat ty výsledky hledání dohromady podle relevance… Neříkám, že je to nemožné, ale co výkon?

Ona je tu taky otázka, jak moc bude hledáno mimo články.

nAS napsal(a):

Každý modul může slovům přidělovat relevanci a v administraci se nastaví globální relevance pro moduly, s kterou se to vynásobí.

Jasně, ale jak to bude výkonné? (Zvlášť na pozdějších stránkách!) Dobře, pokud zobrazím první stránku vyhledávání a jednotlivé moduly mi to budou vracet seřazené v proudu, můžu to celkem rychle třídit slučováním (lineární náročnost). Jenže, jak to budeš dělat na druhé stránce?

nAS napsal(a):

Předpokládám, že na tom CMS by mělo být možné postavit fotogalerii, nebo eshop, takže dost :)

To pak jo.

Tak jsem nad tím popřemýšlel a myslím, že je mi to jasné:

• Není možné vyhledávat v jakémkoli textu – představte si, že by vyhledávač našel table v nějakém článku (uloženém jako HTML). Dál je možná vhodné hledat i ve štítkách. Toť můj názor.
• Ne každý asi bude chtít vyhledávání, někomu třeba postačí zmíněné GCS. Pak je zbytečné indexovat.

Z toho se mi celkem jednoznačně rýsuje API:

• Prohledatelné bude uloženo ve speciální indexované tabulce.
• Každý modul bude mít možnost zaregistrovat jeden nebo více SearchModule (pracovní název rozhraní, SearchModule nedědí z IModule!)
• Každý SearchModule by umožňoval
• * Získat všechny indexovatelné položky (pro případ zapnutí indexování).
• * Zaregistrovat nějaký handler na CRUD s indexovatelnými položkami (pokud nechci hledání, indexování může být vypnuté a tento handler nebude zaregistrován)
• * Získat jeho jednoznačné ID.
• * Přeložit id položky na URL (viz níže)
• Struktura tabulky by byla modulům zapouzdřená výše zmíněným API.
• Indexová tabulka by obsahovala titulek, obsah, id hledacího modulu, nějaké svoje id (asi string).
• Při hledání by nebylo potřeba cokoli spojovat. Titulek a náhled by mohl být načten z DB a (aspoň ze začátku) nemusel by být dále jakkoli zpracováván. URL by byla zjištěna z ID v databázi. Konkrétní struktura ID by závisela na konkrétním modulu. Modul je možné vyhledat díky jeho ID.
• Nella by obsahovala hledací API, ale nemusela by obsahovat hledací engine.

Jinak, jak to vidíš s jazyky? Bude možné mít článek (apod.) ve více jazycích? Pokud jo, je to určitá komplikace, třeba i s indexy.

Karel Klíma:

Já mám něco podbného, ale jednotlivé moduly v sobě obsahují Presentery jen pro administraci. A sadu komponent, které se dají použít ve frontendu. Samotný frontend je pak vlastně jeden modul. Díky tomu odpadá složitější dělení (jeden modul nemusí mít dva submoduly na front a back). Navíc se ty komponenty z těch modulů načtou automaticky po nainstalovaní modulu.

Celý frontend pak stačí zapsat třeba takhle, presenter je prazdný, jen dědí z base, kde se automaticky načítají ty komponenty a oprávnění.

{widget header}
<body>
    <div id="central">
        <div id="verticalmenu">
        {widget content:menu 0,1}
	{widget user:loginForm}
        </div>
        <div class="menu">
            {widget content:menu 'set',5}
        </div>
        <div id="content">
            <div>
            {widget content:page}
            </div>
        </div>
    </div>

Jestli je to optimální nevím, ale v podstatě sem k tomu dospěl, až po vytvoření systému jako máte vy, který mi přišel velmi koplikovaný, až nepřehledný.

Editoval Ani (19. 2. 2010 21:44)

Zkus udělat pull z remote dev větve.

Git si evidentně naklonuje jen master větev…

Vrtak ma zivot na.ruby :D

Nella má momentálně neveřejný vývoj, na GitHubu je jen skeleton… A žádná oficiální dokumentace zatím neexistuje (pokud vím).

Můžu se zeptat, jak to s vývojem nelly vypadá?
Kdy bude vypuštěna verze pro stažení – jiná než stáhnou git repositář?

Editoval BombajS (19. 2. 2011 20:43)

Ahoj, plánuješ k Nella frameworku nějakou dokumentaci? Rozhoduju se, jestli pokračovat v psaní vlastního CMF, nebo si počkat na Nellu :-)