Angular table directive SQL lekérdezéshez
2016-02-16T22:00:51+01:00
2016-02-19T09:55:58+01:00
2022-07-19T06:55:30+02:00
WarmUp
Késztettem néhány SQL lekérdezést, ami angularjs alatt jelenik meg.
Most így néz ki egy-egy ilyen readonly tábla view-ja:

<table class="table table-condensed"> <thead> <tr> <th ng-repeat="col in cols">{{col}}</th> </tr> </thead> <tboby> <tr ng-repeat="row in trap.data"> <td class="small">{{row.K_NEV}}</td> <td>{{row.D1}}</td> <td>{{row.D2}}</td> </tr> </tbody> </table>
Mindegyik valami ilyesmi és mindegyiknek beleírogattam a template-be az oszlopok nevét.

A különböző table directive-ek úgy láttam, hogy mind egyedi oszlopkezelést igényelnek.
Én egy olyan directive-et szeretnék, ami a PHP-val összerakott JSON táblázatot simán megjeleníti, esetleg sorba rendez, de az se fontos. Az egyes táblák  max 50 sorosak, ezért nem kell a lapozás sem.
Az lenne a lényege, hogy a PHP oldalon futtatok egy lekérdezést és azt json_encode()-al elküldöm, akkor a kliens oldalon egy szimpla pl. 'read-only-table' directivvel meg tudjam jeleníteni.

Eddig még nem írtam ilyen directive-et, de ha van kész, akkor inkább abból indulnék ki.
Hogy néz ki egy ilyen directive ?
Mutasd a teljes hozzászólást!
Kiskoromban is sokszor mondta Apu, hogy "Amit nem tudok összerakni, azt inkább ne szedjem szét".
Egy teljes napot azon görcsöltem, hogy az SQL lekérdezésből csináljak egy olyan JSON objektumot, amit a kliens oldalon ugyanolyan sorrendben össze tudok forgatni egy táblázatba. Jó bonyolult directivet kellett volna írni hozzá. Az angulár forrását tanulmányozva úgy láttam, hogy az ng-repeat sem a legegyszerűbb gyári directive.

A legegyszerűbb ebben az esetben ugyanis az, ha a táblázatot PHP oldalon készítem el és egészben küldöm el mint dinamikus template. Szóval sima HTML táblázat AJAX-os templateként. A route meg elintézi, hogy a kliens oldali url alapján a megfelelő tartalmú táblázat kerüljön be a view-ba.

.state('table', { url: '/table?param', templateUrl: function($stateParams) { return '../api/table?param=' + $stateParams.param; } })
Ebben az esetben az ui-view helyére egyszerűen berakja a táblázatot és kész.

RTFM
Mutasd a teljes hozzászólást!

  • Ha jól értem mit is szeretnél és a tábla szerkezete állandó (ugyanannyi és azonos fejlécű oszlop), akkor lehet a kiindulási alap a következő...
    Ha nem, akkor a zavarásért...
    Mutasd a teljes hozzászólást!
  • Köszi a mintát.

    Igazából a ui-route-os rész lehet, hogy jobban leírja az elképzelést.

    A route először így nézett ki:

    .state('report1', { url: '/report1', templateUrl: 'app/report/report1.html', controller: 'report1_controller' }) .state('report2', { url: '/report2', templateUrl: 'app/report/report2.html', controller: 'report2_controller' })
    Innen meg tudtam csinálni a következő lépést, ami egy egységes template-et tartalmaz, hiszen
    mindegyik oldal ugyanúgy jeleníti meg a táblázatot és a controller tartalmazza az api hivatkozást.

    .state('report1', { url: '/report1', templateUrl: 'app/report/table.html', controller: 'report1_controller' }) .state('report2', { url: '/report2', templateUrl: 'app/report/table.html', controller: 'report2_controller' })
    Innen jönne talán a következő lépés a resolve segítségével, amikor a route írja le, hogy mit is kell lekérni a backendtől:

    .state('report1', { url: '/report1', templateUrl: 'app/report/table.html', resolve: { data: function(dataService){ return dataService.getData('api/report1')} } }) .state('report2', { url: '/report2', resolve: { data: function(dataService){ return dataService.getData('api/report2')} })

    De legszebben mégis talán így nézne ki:

    .state('report1', { url: '/report1', template: '<myTable="api/report1">', }) .state('report2', { url: '/report2', template: '<myTable="api/report2">', })
    A tábla szerkezete minden lekérdezésnél egyedi, mindig más mezők szerepelnek benne, viszont az SQL query ilyen szempontból jól kezelhető a select column as 'Title'  from table segítségével.
    Pont az lenne a lényeg, hogy PHP oldalon a selectbe berakom a lekérdezést egy API routhoz, az angular felén pedig egy új routot írok, meg a menübe egy új elemet hozzá és már meg is jelenik az új elem az alkalmazásban.

    Eddig, még nem volt szükségem custom directive-re, de talán pont ez az a pont, ahol megcsillanhatna az angulár szépsége :)
    Mutasd a teljes hozzászólást!
  • Miután végigizzadtam a directive írás bugyrainak az első fejezetét és megmártóztam a gyári directivek forráskódjában, a végén csak megtaláltam azt a kódot, amit reggel elkezdtem írni (természetesen az enyém még nem lett befejezve :( )
    Mutasd a teljes hozzászólást!
  • Kiskoromban is sokszor mondta Apu, hogy "Amit nem tudok összerakni, azt inkább ne szedjem szét".
    Egy teljes napot azon görcsöltem, hogy az SQL lekérdezésből csináljak egy olyan JSON objektumot, amit a kliens oldalon ugyanolyan sorrendben össze tudok forgatni egy táblázatba. Jó bonyolult directivet kellett volna írni hozzá. Az angulár forrását tanulmányozva úgy láttam, hogy az ng-repeat sem a legegyszerűbb gyári directive.

    A legegyszerűbb ebben az esetben ugyanis az, ha a táblázatot PHP oldalon készítem el és egészben küldöm el mint dinamikus template. Szóval sima HTML táblázat AJAX-os templateként. A route meg elintézi, hogy a kliens oldali url alapján a megfelelő tartalmú táblázat kerüljön be a view-ba.

    .state('table', { url: '/table?param', templateUrl: function($stateParams) { return '../api/table?param=' + $stateParams.param; } })
    Ebben az esetben az ui-view helyére egyszerűen berakja a táblázatot és kész.

    RTFM
    Mutasd a teljes hozzászólást!
  • Legközelebb majd szóljatok, hogy ne gondoljam még ennyire se túl a dolgokat.
    A dinamikus template-eket alapból&nbsp;az angulár gyorstárazza, vagyis, ha azon az úton indul az emberfia, akkor bizony a $routeProvider-hez is hozzá kell piszkálni.

    Helyes válasz:

    <ng-include src="string">
    Mutasd a teljes hozzászólást!
abcd