News-Modul

[paulbr]

Da gibbed ja einiges was geändert werden muss!

Wenn ich das richtig verstanden habe, wird die cs_rel_news_comments nicht mehr benötigt,
da direkt auf die comments zugegriffen wird.
Also muss die comments tabelle geändert durch eine 'ref_id' ergänzt werden, da ja 1 news
durchaus viele comments haben könnte.
Ein weiteres feld 'category' wird dann auch benötigt, da comments ja nicht nur news haben.
In dem ref_id feld befindet sich dann entsprechend die news_id | article_id ... je nachdem für
was der comment abgegeben wurde.

Hmm, nein funktioniert auch net, da beim referenzieren ja nur die id-felder gesetzt werden.
Eine kategorie kann da vermutlich nicht übergeben werden. Es sei den im leftJoin in der Repository.

Denke am besten wird sein, wenn man die comments trennt, also news_comments | article_comments ...

Ich hab mit der NewsRepository mal ein bischen rumgespielt:

Code:

namespace Repositories;
use Doctrine\ORM\EntityRepository;
use DoctrineExtensions\Paginate\Paginate;

class NewsRepository extends EntityRepository
{
    public function findAllNews($currentPage, $resultsPerPage)
    {
        $q = $this->_em->createQueryBuilder();
        $q->select('
                            n,
                            partial u.{user_id, nick, email, country},
                            partial c.{cat_id, name, description, image, icon, color},
                            nc,
                            partial ncu.{user_id, nick, email, country}
                        ');
        $q->from( 'Entities\News', 'n' );
        $q->leftJoin( 'n.news_authored_by', 'u' );
        $q->leftJoin( 'n.category', 'c' );
        $q->leftJoin( 'n.comments', 'nc' );
        $q->leftJoin( 'nc.comment_authored_by', 'ncu' );
        $q->where( 'c.module_id = 7' );
        $q->orderBy( 'n.news_id', 'DESC' );

        $query = $q->getQuery();
        $result = $query->getArrayResult();

        #$count = Paginate::getTotalQueryResults($q);
        #$paginateQuery = Paginate::getPaginateQuery($q, $currentPage, $resultsPerPage);
        #$result = $paginateQuery->getResult();

        #\Clansuite_Debug::printR( $result );

        return $result;
   }

Die news werden alle korrekt zurückgegeben inkl. den user daten, einzig die comments funktionieren
hier nicht, da die referenzierung nicht stimmt und auch die 'nr_news_comments' existiert nicht.
Im moment wird die news_id mit der commit_id referenziert, was nicht funktionieren kann, da beide ID's autoincrements sind.

Code:

...
[5] => Array
  (
    [news_id] => 23
    [news_title] => Testeintrag 3 - Lore Ipsum
    [news_body] => Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque imperdiet tristique justo ac pretium. Fusce odio nisl, dictum sed vestibulum in, tristique malesuada lacus. Suspendisse potenti. Proin bibendum placerat neque ut placerat. Nunc felis ligula, ullamcorper sed congue ut, pulvinar ut sapien. Nullam sem purus, adipiscing ut consectetur at, ornare eget magna. Vivamus ut eros vitae neque aliquam vulputate et molestie arcu. Etiam et metus id risus pulvinar pretium? Sed vulputate venenatis consectetur. Mauris id odio risus. Maecenas lacinia iaculis nisi vel egestas. Suspendisse potenti. Quisque vel dui in lectus ultrices vehicula. Donec convallis tortor et leo vehicula non placerat mi varius. Morbi ac pharetra lorem. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Fusce cursus pulvinar nisl. Nunc a nisi vel purus sagittis bibendum!

    [cat_id] => 2
    [user_id] => 2
    [created_at] => 2009
    [updated_at] => 2010
    [news_status] => 4
    [news_authored_by] => Array
    (
        [user_id] => 2
        [email] => user2@clansuite.com
        [nick] => user2
        [country] => de
    )

    [category] => Array
    (
        [cat_id] => 2
        [name] => Allgemein
        [description] => Thema Allgemein
        [image] => http://www.clansuite-dev.com/uploads/images/gallery/kunst.jpg
        [icon] => http://www.clansuite-dev.com/uploads/images/gallery/raetsel_1.jpg
        [color] => #000000
    )

    [comments] => Array
    (
    )
  )
...

Die Pagination macht hier auch nur teilweise was sie soll
Allerdings liegt das nicht an der pagination selbst, sondern an den Sonderzeichen denke ich mal:
Das result der $paginateQuery liest die news nur teilweise aus, also nicht alle.

Code:

Debugging NewsRepository.php on line 46:
\Clansuite_Debug::printR( $paginateQuery );

Type: object
Value: Doctrine\ORM\Query Object
(
    [_state:Doctrine\ORM\Query:private] => 2
    [_dql:Doctrine\ORM\Query:private] => SELECT
                            n,
                            partial u.{user_id, nick, email, country},
                            partial c.{cat_id, name, description, image, icon, color},
                            nc,
                            partial ncu.{user_id, nick, email, country}
                         FROM Entities\News n LEFT JOIN n.news_authored_by u LEFT JOIN n.category c LEFT JOIN n.comments nc LEFT JOIN nc.comment_authored_by ncu WHERE c.module_id = 7 ORDER BY n.news_id DESC
    [_parserResult:Doctrine\ORM\Query:private] =>
    [_firstResult:Doctrine\ORM\Query:private] =>
    [_maxResults:Doctrine\ORM\Query:private] =>
    [_queryCache:Doctrine\ORM\Query:private] =>
    [_expireQueryCache:Doctrine\ORM\Query:private] =>
    [_queryCacheTTL:Doctrine\ORM\Query:private] =>
    [_useQueryCache:Doctrine\ORM\Query:private] => 1
    [_params:protected] => Array
        (
            [pgid_1] => 21
            [pgid_2] => 22
            [pgid_3] => 23
            [pgid_4] => 24
            [pgid_5] => 71
        )
...

    [pgid_1] => 21
    [pgid_2] => 22
    [pgid_3] => 23
    [pgid_4] => 24
    [pgid_5] => 71

Die news bis ID = 71 verwenden normale Zeichen und html tags, die nächste news danach (ID = 98) ist die mit den cyrillic zeichen, da wird abgebrochen.
Vermutlich fehlt hier auch noch irgendwo das utf8.
Ohne Pagination werden alle news korrekt zurückgegeben.

Um das zu testen muss in der DB die 'cs_news' erst überarbeitet werden, da dort news ohne user_id
und category vorhanden sind. Also vor dem test diese news erst manuell ausbessern, sonst
gibbed anstatt den news nur Fehlermeldungen auf dem Bildschirm.

Viel Spass beim ausprobieren

gruss
paul

--------------

EDIT:

Der Pager funktioniert, er liefert soweit die Ergebnisse.
War ein fehler von mir, er sollte ja nur gem. config 5 ergebnisse pro seite zurücj liefern

[paulbr]

Ok es liegt definitiv an den comments.

Ich habe die cs_comments mal nach cs_news_comments kopiert,
ein feld: news_id eingefügt und den 2 comments eine news_id verpasst.

Die Entities\Comment um das feld erweitert und nun funktioniert es.

Bei der Pagination, wird allerdings nur die erste seite zurückgegeben.
In smarty funktioniert diese daher nicht.
Ich glaube irgendwo bei doctrine gelesen zu haben, das in d2 die Doctrine_Pager_Layout
wie in d1 vorhanden noch nicht kann.
Die müssten wir wohl vorläufig selbst erstellen?

gruss
paul

[Jens-A. Koch]

Bei der Pagination, wird allerdings nur die erste seite zurückgegeben.
In smarty funktioniert diese daher nicht.
Ich glaube irgendwo bei doctrine gelesen zu haben, das in d2 die Doctrine_Pager_Layout
wie in d1 vorhanden noch nicht kann.
Die müssten wir wohl vorläufig selbst erstellen?

Smarty kommt als Fehlerquelle nicht in Betracht. Mit dem Datagrid ist das so wie bei den Forms:
Am Ende wird dort einfach {$form} bzw. {$datagrid} ins Template geschrieben und bei Ausgabe erfolgt die Ersetzung mit dem fertigen Html-Block aus dem Form-/Datagridhandler.

Ja, richtig, sowas wie Doctrine_Pager_Layout bzw. Doctrine_Pager ist nur für D1 verfügbar.
Die Pager-Funktionalität hab ich daher in die Datagrid Klasse integriert.
An der Pagination hab ich im Januar zuletzt gearbeitet.
Die Query-Bildung und Pagination erfolgen dynamisch durch Angabe des Repositories bzw. der Entity.
So kommt beispielsweise Clansuite_Module_News_Admin -> action_admin_show() ohne
vorher geschriebenen Query aus (index.php?mod=news&sub=admin).

Es ist möglich, den Paginationsteil aus dem Datagrid in eine neue Klasse zu überführen.
Das müsste ich dann wohl in Angriff nehmen, damit es auch außerhalb des Datagrid verfügbar ist.
Auch aus Gründen der Wiederverwendbarkeit bietet sich eine Aufteilung in Query-Building, Table-Rendering, Pagination an.

Ungelöst ist bislang das Paginations-Problem mit dem Anhängen der Parameter (wie "p" page, sort etc) an die URL. Daher werden auch die Links für die Pager-Navigation und die einzelnen Artikel nicht korrekt gebildet (bspw. ?p=1&p=3 / ?mod=news&sub=admin&p=2&action=edit&id=22).

Wo ich gerade "index.php?mod=news&sub=admin" offen habe: dort fehlte ein float:left.
Und zwar wollte ich dort die Pagination auf gleiche Höhe bzw. in eine Zeile mit dem Seiten-Dropdown bekommen. Gleich mal eingefügt...

auch die 'nr_news_comments' existiert nicht

nr_news_comments ist kein Feld, sondern ne Db-Kalkulation auf Basis des Subqueries
= "Anzahl der Comments für die jeweilige News".

Zu den Comments-Relationen des News Moduls kann ich im Moment nicht viel sagen,
außer das es ne OneToMany (News:Comments) Relation ist. Für Kategorien oder User
gibts diese Relation ja auch. Da werden wohl wirklich nur die ids gefehlt haben.

[paulbr]

Ungelöst ist bislang das Paginations-Problem mit dem Anhängen der Parameter (wie "p" page, sort etc) an die URL. Daher werden auch die Links für die Pager-Navigation und die einzelnen Artikel nicht korrekt gebildet (bspw. ?p=1&p=3 / ?mod=news&sub=admin&p=2&action=edit&id=22).

Man kann doch einfach eine Filterform über den listen einfügen.

Dann die Post aus der Filterform auslesen und als parameter an die URL anhängen.
In action_admin_show dann erst prüfen ob die Filterform submitted wurde, wenn ja
den Query string zusammenbauen:
 ?mod=news&sub=admin&action=show&p=2....

Das gleiche bei edit, den parameter: 'p=2' als hidden mit ins editform geben so kann man mit dem
redirect zurück auf die page 2 der Liste springen.

Bei mod-rewrite kann man auch feste parameter nutzen, die man im router auflösen kann:
   p-     ist page (e.g. p-25 wäre dann page = 25)
   id-    ist immer eine id ( eg. id-12345 wäre dann id = 12345)
   co--  ist cookie (e.g. co--7aafb74dbe23ea352308be7b071db836)

im querystring kann man das dann auflösen genau wie mod=???

/news/admin/show/p-25  = ?mod=news&sub=admin&action=show&p=25

/news/admin/edit/p-25/id-12345  = ?mod=news&sub=admin&action=edit&p=25&id=12345
/news/admin/edit/id-12345/p-25  = ?mod=news&sub=admin&action=edit&id=12345&p=25

Die Reihenfolge spielt hier ja keine Rolle weil der identifier 'p-' und 'id-' ja ausschlaggebend sind.

Filter+Sort kriterien sind so ebenfalls möglich zu übergeben, man muss sich hier nur eine vernünftige
identifier lösung überlegen.

Man könnte auch generell ein cookie setzen, darin dann alle parameter für Filterung unterbringen.
in der URL dann ebend ...&co--7aafb74dbe23ea352308be7b071db836
Was sogar vernünftiger ist, da es durchaus viele Filteroptionen geben kann.

So hat man für die Pagination doch alle daten für den Querystring.

Beispiel: Um die Liste /news/admin/show inkl. diverse Filteroptionen darzustellen
  /news/admin/show/p-25/co--7aafb74dbe23ea352308be7b071db836

Die function news_admin_show weiss nun anhand der parameter:
  p-25  das die page 25 ist
  co--... das hier ein Cookie mit dem namen: 7aafb74dbe23ea352308be7b071db836 ausgelesen werden muss.

In dem Cookie stehen dann die Filteroptionen, welche man jetzt auf die Filterform vorbelegen kann.

Man muss ja nicht in jedem Modul für die Pagination alles neu definieren.
Kann man ja als funktionen definieren z.B.:
  - clearListFilter($name)
  - addListFilter($name, $key, $value)
  - getListFilter($name)
    welche dann ein array mit den Filteroptionen zurückgibt um die Filter vorzubelegen
    oder vom Pager direkt verwendet wird und dann die Get parameter zum vorbelegen nutzen

Die Filter-Funktionen könnte man z.B. mit in die eigenständige Clansuite_Pager Integrieren.

gruss
paul

[Jens-A. Koch]

URL-Bildung Pagination
Das Problem mit der URL-Bildung liegt zwischen getBaseURL() und appendUrl().
Derzeit wird die BaseURL von außen ins Datagrid gesetzt (und wenn da schon ein "p" drin ist, dann ist das auch die Basis fürs Anhängen.).
Zur Lösung: Da fehlt einfach nur ein parse_url() um die bereits bestehenden Parameter der URL zu bekommen und ein neues http_build_url() (ist ja schon im Framework), um sie ohne Dopplungen wieder zusammenzusetzen.

Zu den verfügbaren Identifiern für Pagination und Sorting

- getListFilter($name)
    welche dann ein array mit den Filteroptionen zurückgibt um die Filter vorzubelegen
    oder vom Pager direkt verwendet wird und dann die Get parameter zum vorbelegen nutzen

Ich glaube, wenn ich das Konzept "Filterform" richtig verstanden habe,
dann sind Teile davon bereits im Datagrid enthalten.
Die verfügbaren Parameter liegen alle in $_requestParameterAliasMap vor.
D.h. intern arbeitet das System nicht mit Abkürzungen, sondern mit vollen Namen.
Extern, d.h. über die URL mit den Kürzeln, sonst wird die URL zu lang.

   /**
     * Lookpup/Mapping Array
     * For mapping internal variable names to their shorthand names.
     *
     * This determines the incoming and offgoing url parameter names
     * for Sorting, Pagingation, Search and Reset.
     * Structure: array( InternalName => ExternalShorthand )
     *
     * Example URL: ?sortC=Title&sortO=DESC&p=2&rpp=10
     *
     * @var array
     */
    private $_requestParameterAliasMap = array(
        'SortColumn'        => 'sortC',
        'SortOrder'         => 'sortO',
        'Page'              => 'p',
        'ResultsPerPage'    => 'rpp',
        'SearchForValue'    => 'searchfor',
        'SearchColumn'      => 'searchc',
        'Reset'             => 'reset'
    );

Routingregeln

/news/admin/show/p-25  = ?mod=news&sub=admin&action=show&p=25

/news/admin/edit/p-25/id-12345  = ?mod=news&sub=admin&action=edit&p=25&id=12345
/news/admin/edit/id-12345/p-25  = ?mod=news&sub=admin&action=edit&id=12345&p=25

Die Angabe von p (Page) kann hier entfallen, id (news_id) reicht.

Beides könnte man bereits über den Router und eine entsprechende Routing-Regel lösen.
Ein Regexp der Art "[a-z]{2-4}-[0-9]{2}" würde zum Matchen für alle Parameter reichen.

Einsatz von Cookies

Man könnte auch generell ein cookie setzen, darin dann alle parameter für Filterung unterbringen.
in der URL dann ebend ...&co--7aafb74dbe23ea352308be7b071db836
Was sogar vernünftiger ist, da es durchaus viele Filteroptionen geben kann.

Bitte sehr, sehr defensiv mit Cookies umgehen und das Setzen von Cookies eher vermeiden.
So wenige Cookies wie nötig setzen. Unbedingt gebraucht wird nur der Cookie zur Sessionidentifikation. Rest kann auch anders gelöst werden.
Eine vergleichbare Regel gibts für Sessiondaten: So wenig Sessiondaten wie nötig.

Welche Filteroptionen kommen noch in Betracht?
Falls dir noch welche einfallen, dann würde ich die als Paramterangaben mit in das $_requestParameterAliasMap Array aufnehmen.

Gruß Jens

[paulbr]

/news/admin/edit/p-25/id-12345  = ?mod=news&sub=admin&action=edit&p=25&id=12345
/news/admin/edit/id-12345/p-25  = ?mod=news&sub=admin&action=edit&id=12345&p=25

Das Beispiel war eher dafür gedacht, wenn man aus einer Liste, z.b. auf page 5, einen Eintrag editieren
möchte, damit man danach wieder in der Liste auf der page 5 landet und nicht auf der page 1.

Ich glaube, wenn ich das Konzept "Filterform" richtig verstanden habe,
dann sind Teile davon bereits im Datagrid enthalten.

Das setzt voraus das man immer Datagrid verwendet, also nicht nur im Adminbreich.

Welche Filteroptionen kommen noch in Betracht?

...
        'SearchForValue'    => 'searchfor',
        'SearchColumn'      => 'searchc',
        'SearchMode'      => 'searchmod',
...
Searchart kann sein:
   - Volltextsuche like 'suchwort' | '%suchwort%' | '%suchwort' | 'suchwort%'
      in verschiedenen textfeldern (e.g. Titel | Descripcion | ....)
   - Normale Suche 'searchc=searchfor'


SearchMode kann sein: d[=|<|>] oder: n[=|<|>] oder: t[e|l|r|v]
default ist immer '='

Mode = d  ist Datum Suche
Mode = n  ist Integer Suche
Mode = t  ist Text Suche
           parameter: e = exakte wortsuche
                           l  = %suchwort
                           r  = suchwort%
                           v  = %suchwort%

Ich weiss jetzt nicht wie SearchColumn und SearchForValue ausgelegt sind.
Aber auch hier muss die Flexibilität da sein.
z.B.
  searchfor='test'    -> einzelwort
  searchfor='wort1,wort2,wort3'  -> array mit suchbegriffen

  searchc='title'    -> Suche in 1 column
  searchc='title,descripcion,keywords'    -> Suche über mehreren columns

Beispiel für datum:
  searchfor='09.05.2011'
  searchc='date'
  searchmod='d'      (würde alle DS zurückgeben bei denen date = 09.05.2001 ist)
  searchmod='d[<]'  (würde alle DS zurückgeben bei denen date < 09.05.2001 ist)
  searchmod='d[>]'  (würde alle DS zurückgeben bei denen date > 09.05.2001 ist)

Andere Alternative wäre:
        'SearchMode'       => 'searchmod',  (d|n|t)
        'SearchOperator'  => 'searchop',

Vergleichs-Operatoren:       = , < , <= , => , >
Verknüpfungs-Operatoren:  a , o , n    (and, or, not)
Like-Operator (lk):             lke , lkl , lkr , lkv

gruss
paul

[Jens-A. Koch]

Na es geht darum im Datagrid zu schauen, was wir rausholen können, ohne es neu implementieren zu müssen.

Erweiterung - bessere Suchparameter
Die Erweiterung um bessere Suchmöglichkeiten gefällt mir gut. In diese Richtung ist noch nicht gedacht oder entwickelt worden. Derzeit setzen wir nur das einfache LIKE ein, weitere Operatoren werden nicht berücksichtigt. Dein Vorschlag ist daher eine gute Ergänzung. Ich denke da nicht nur an die angesprochenen Operatoren, sondern auch an MATCH AGAINST und evtl. Volltextsuche.

Um das zu realisieren, müssen wir an verschiedenen Stellen ran.
Erstmal ein weiteres Formularelement für die Sucheingaben.
So ein Filterformular kann auch gut mit Dropdowns für die Operatoren arbeiten.
Das sind dann POST Werte des Suchformulars.

Dazu eine Klasse für Suche, welche einen vorhandenen Query ergänzen kann.
Letztlich ist der Ansatzpunkt wieder im Bereich Query-Bildung zu suchen.

Da kann man nun drüber streiten, ob die Suche mittels Operatoren auch über GET laufen soll,
oder eher über POST. Ich bin dafür, die einfache Suche über GET und die Filterformular-Suche über POST laufen zu lassen. Andere Vorschläge willkommen...müssen wir sehn, wie sich die Sache entwickelt ...

URL Parameter

Das Beispiel war eher dafür gedacht, wenn man aus einer Liste, z.b. auf page 5, einen Eintrag editieren möchte, damit man danach wieder in der Liste auf der page 5 landet und nicht auf der page 1.

Ja, das geht schon. Aber warum nach zwei Ressourcen in einem GET-Request fragen? Die jetztige Lösung ist anders: Die Edit-Links enthalten nur die ID. Um nach dem Edit wieder auf die Ausgangsseite zu kommen, wird auf den Referer zurückgegriffen. Ohne Referer ist es /admin/show bzw. p=1.

Aufgaben aus diesem Thread
Kurze Zusammenfassung in Ticket-Form, damit nichts verloren geht.
http://trac.clansuite.com/ticket/205 - NewsComments prüfen
http://trac.clansuite.com/ticket/206 - Pagination aus Datagrid isolieren
http://trac.clansuite.com/ticket/207 - Parameter der Pagination
http://trac.clansuite.com/ticket/208 - Verfeinerung der Suchmöglichkeiten über "LIKE" hinaus

Gruß Jens

[paulbr]

Es geht auch noch einfacher, indem man einfach nur ein Suchfeld angibt.

Ich hatte vor einigen Jahren mal eine Suche für ein Kundenprojekt gemacht.

Erklärung:
Suchbegriffe werden durch leerzeichen getrennt eingegeben.

+ Ein Suchwort findet alle Branchen-Eintragungen mit diesem Wort.
+ Zwei Suchwörter ohne Anführungszeichen (Beispiel: Maurer Fliesenleger),
    findet alle Branchen-Eintragungen in denen mindestens einer der Begriffe vorkommt.
+ Zwei oder mehr Suchwörter, die mit Anführungszeichen umschlossen werden
   (Beispiel: "Handwerker" "Fliesenleger"), finden alle Branchen-Eintragungen,
    in denen genau diese Suchbegriffe vorkommen. Diese Wörter werden intern also wie ein Suchwort behandelt.
+ Wird ein Minuszeichen vor das Wort gesetzt, findet er alle Branchen-Eintragungen, in denen dieser Begriff
   *nicht* vorkommt (Beispiel: "Handwerker" -Elektriker). Bei dieser Eingabe werden alle Handwerker mit
    Ausnahme der Elektriker gefunden.
+ Es werden immer der Firmenname, die Stichwörter und die Beschreibung durchsucht.

Code:

$searchtext = trim($searchtext);
if( $searchtext !== '' ) $fstext = true; else $fstext = false;

$aSearch = explode( ' ', $searchtext );
if( count( $aSearch ) >0 )
{
    foreach( $aSearch as $item ) {
        $item = trim($item);
        if( substr( $item, 0, 1 ) =='"' ) {
            $item = str_replace( '"', '', $item);
            $aLikeOptions['exact'][] = $item;
        }
        elseif( substr( $item, 0, 1 ) =='-' ) {
            $aLikeOptions['not'][] = substr($item, 1);
        }
        elseif( trim($item) !== '' ) {
            $aLikeOptions['like'][] = trim($item);
        }
    }
}

if( true===$fstext )
{
  // -------- Search '%searchtext%' -----------
  $searchLike = '';
  if( array_key_exists( 'like', $aLikeOptions) && count($aLikeOptions['like'] ) >0 ) {
      foreach( $aLikeOptions['like'] as $item) {
          $searchLike .= "firma LIKE '%$item%' OR stichwort LIKE '%$item%' OR text LIKE '%$item%'" .' OR ';
      }
      $searchLike = substr($searchLike, 0, strlen($searchLike)-4);
  }

  // -------- Search 'searchtext' -----------
  $searchExakt = '';
  if( array_key_exists( 'exact', $aLikeOptions) && count($aLikeOptions['exact'] ) >0 ) {
      foreach( $aLikeOptions['exact'] as $item) {
          $searchExakt .= "firma LIKE '$item' OR stichwort LIKE '$item' OR text LIKE '$item'" .' OR ';
      }
      $searchExakt = substr($searchExakt, 0, strlen($searchExakt)-4);
  }

  // -------- Search '-searchtext' -----------
  $searchNot = '';
  if( array_key_exists( 'not', $aLikeOptions) && count($aLikeOptions['not'] ) >0 ) {
      foreach( $aLikeOptions['not'] as $item) {
          $searchNot .= "firma NOT LIKE '$item' AND stichwort NOT LIKE '$item' AND text NOT LIKE '$item'" .' AND ';
      }
      $searchNot = substr($searchNot, 0, strlen($searchNot)-4);
  }

}

Die where auf Doctrine könnte dann so eingebunden werden:
...
if( $searchLike != '' ) $qb->andWhere( $searchLike );
if( $searchExakt != '' ) $qb->orWhere( $searchExakt );
if( $searchNot != '' ) $qb->andWhere( $searchNot );

Operatoren denke ich sind Notwendig damit man mit dem Filterform möglichst jede
Filterung bzw. suche abdecken kann.

...die einfache Suche über GET und die Filterformular-Suche über POST...

Ja das macht Sinn, denn eine Schnellsuche ist ja nur ein textfeld zur eingabe der keywords.
Hingegen ein Filterformular dient ja dazu eine grosse Ergebniss-Liste einzugrenzen.

Allerdings muss man auch berücksichtigen, das für die pagination trotzdem alle kriterien als GET
angehängt werden müssen.
Es sollten da schon möglichst kurze parameter definiert werden.

Eine andere Möglichkeit wäre die, das man den parameter-string base64 decodiert.
z.B. ?mod=news&sub=admin&action=show&q=cD0yM3xycHA9MTB8c2VhcmNoYz....

Der query (q=) wäre in dem verkürtzt dargestellten beispiel:
p=23|rpp=10|searchc=title,descripcion|searchfor=wort1,wort2,wort3|sortC=title|sortO=desc

Muss nur wieder decodiert und gesplittet werden.

gruss
paul