Első modul, rá kellene nézni

nevergone képe

Sziasztok...!

Elkészítettem első (komolyabb) modulomat, amely egy megadott oldalról letölt egy szöveget XPath információ alapján, és egy blokkban megjeleníti az oldalon. A modul működik, viszont mivel nem vagyok profi PHP programozó (csak mostanság kezdtem el mélyebben foglalkozni vele, pont a Drupal miatt) és most kezdtem az ismerkedést a Drupal mélyebb lelkivilágával is, ezért örülnék, ha valaki szakértőbb ránézbe, és az esetleges hibákra, hiányosságokra javítási ötletet mondana, esetleg felhívná a figyelmem pár dologra, ami szükséges.

Azon kívűl lenne két konkrétabb kérdésem is:
Ha a '#type' => 'button' segítségével gombot hozok létre az adminisztrációs felületen, milyen módon tudok ahhoz eseményt (mondjuk egy függvény végrehajtását) rendelni?
Ha az adminsztrációs oldalon elmentik a modul beállításait, valamilyen módon lehetséges egy függvény lefuttatása?

Ezek azért kellenek, mert jelenleg a megváltozott beállítások csak az időzített feladatok következő futásakor hajtódnak végre, vagy a menűből aktiválva, de ez utóbbi egy rendkívűl csúnya és kényszermegoldás.

A modul elérhetősége:
http://srv.nek.sh.unideb.hu/~never/tesztmodul/

Köszönöm a segítséget! :)

Ui.: Várható továbbfejlesztés, hogy az adminisztrációs oldalon meg lehet adni időpontokat (pl. 8 12:30 21), és a tartalmat csak a megadott időpontok után következő időzített feladatok futásakor tölti le. Ha esetleg erre is van valami ötlet, jöhet. :)

Sweetchuck képe

Hello

Érdemes betartani néhány dolgot a függvények és a változók elnevezésével kapcsolatban.

A függvény nevek mindig a modul nevével kezdődjenek, amit esetleg egy aláhúzás karakter előzhet meg.
function _tartalom_konvert()
helyett
function tesztmodule_tartalom_konvert()
vagy
function _tesztmodule_tartalom_konvert()

Ugyan ez vonatkozik a variable_set() által használt változókra, ami magával vonza azt, hogy a hook_settings_form() ürlapon használt nevek is megkapják a modul név előtagot.

http://api.drupal.org/api/5/function/hook_forms
_validate és _submit utótagok az ürlap kezelés esetében

0
0
nevergone képe

Köszönöm a választ, mindenképpen át fogom dolgozni az általad javasolt dolgok alapján.
Esetleg valakinek valami más ötlet, észrevétel, akár a működéssel kapcsolatban?

0
0
pp képe

- A link készítésére használj inkább l() függvényt.
- HTML kimenethez használd a Drupal sminkelhető függvényeit.:

function modulneve_valami(){
...
$output = '[geshifilter-html]kimenet[/geshifilter-html]';
return $output;
}

helyette:

function modulneve_valami(){
...
$output = theme('modulneve_html_kimenet');
return $output;
}
 
function theme_modulneve_html_kimenet{
$output = '[geshifilter-html]kimenet[/geshifilter-html]';
return $output;
}

így ha meg akarod változtatni a kimenetet, vagy valaki más aki használja a modulodat akkor elég annyit csinálnia, hogy ezt a függvényt lemásolja a template.php fájlba és a theme_ helyett beírja a smink nevét.

pp

0
0
nevergone képe

Köszönöm, ezek nagyon hasznos tanácsok! :)

0
0
RaptoR képe

Helló!

A 3 kérdésedre tudok válaszolni, a tesztmodul jelenleg nem jön be a megadott címen, gondolom azóta továbbfejlesztetted. :)

Először ezzel kezdem:

Ha az adminsztrációs oldalon elmentik a modul beállításait, valamilyen módon lehetséges egy függvény lefuttatása?

Igen, egy apró trükkel: tegyük fel, hogy tesztmodul_admin_beallitasok() a beállításos függvényed neve, aminek a kimenetét a system_settings_form()-mal küldöd vissza. Ekkor hozzál létre egy tesztmodul_admin_beallitasok_submit() nevű függvényt:

function tesztmodul_admin_beallitasok_submit($form_id, $form_values) {
  system_settings_form_submit($form_id, $form_values);
 
  // Ide jön amit akarsz itt futtatni
}

Így miután elmenti a Drupal a beállításokat elvégezheti a függvény a dolgát.

Ha a '#type' => 'button' segítségével gombot hozok létre az adminisztrációs felületen, milyen módon tudok ahhoz eseményt (mondjuk egy függvény végrehajtását) rendelni?

A következő módon: hozz létre több 'submit'-os gombot, pl.

  $form['bekuldes'] = array(
    '#type' => 'submit',
    '#value' => t('Beküldés'),
  );
  $form['torles'] = array(
    '#type' => 'submit',
    '#value' => t('Törlés'),
  );

A $form-ot kezelő függvénynél (előző példában ez a tesztmodul_admin_beallitasok_submit($form_id, $form_values) ) a $form_values['op'] értéknél fog megjelenni annak a gombnak az értéke, amire rákattintottál, tehát ha pl. a törlés gombra kattintottál, akkor a t('Törlés') lesz a $form_values['op'] értéke. így pl.

function tesztmodul_admin_beallitasok_submit($form_id, $form_values) {
  system_settings_form_submit($form_id, $form_values);
 
  // Ide jön amit akarsz itt futtatni
  if ($form_values['op'] == t('Törlés')) {
     // Töröljünk ezt meg azt...
  }
}

Ui.: Várható továbbfejlesztés, hogy az adminisztrációs oldalon meg lehet adni időpontokat (pl. 8 12:30 21), és a tartalmat csak a megadott időpontok után következő időzített feladatok futásakor tölti le.

Ez egyszerűbb: beállítod az időpontot az admin oldalon, a tesztmodul_cron()-nál meg egy variable_get()-tel ezt lekérdezed, majd megnézed hogy elmúlt-e már az időpont. Ha még nem, akkor nem lesz semmi visszatérési értéke a függvénynek. :)

0
0
nevergone képe

Szia...!

Pont ma csináltam egy kis karbantartást a szerveren, és mivel úgy gondoltam, hogy ez már egy "lefutott" téma, és nem várható újabb hozzászólás, ezért töröltem... de ha gondolod, szívesen visszateszem.
Még nem fejlesztettem tovább, mert érdemben nem volt időm rá, illetve úgy gondoltam, hogy összegyűjtve itt az ötleteket és jótanácsokat, alaposan átdolgozom a modult, többek közt kiküszöbölve a SimpleXML használatát, amely csak az XPath miatt kell.

Köszönöm a segítségedet. :)

0
0
nevergone képe

Sziasztok!

Volt egy kis időm és energiám, továbbfejlesztettem a modult, felhasználva a Tőletek kapott segítséget. Örülnék, ha megnéznétek ezt a változatot is, hátha valamit nem(jól) oldottam meg.
Tudásában is tovább fejlődött, immáron az XPath kezeléséhez nem kell SimpleXML (vagyis PHP 5), az oldal letöltéséhez választható háromféle letöltési mód (fopen, curl, wget), illetve megadható egy időpont, a letöltés elvégzéséhez.

Hiányosságai/tervezett továbbfejlesztés:
- Ha érvénytelen időpontot adnak meg, akkor az adminisztrációs oldalon jelezni
- Ha csak időpontot adnak meg (dátumot nem), akkor minden nap az adott időpont után elvégzi a letöltést
- opcionálisan az eredmény karakterkészletének konvertálása a recode segítségével.

Nem tudom, mennyire érdemes ebben gondolkodni, de esetleg angolra lefordítva a sztringeket (szükség esetén eltávolítva a megjegyzéseket) érdemes lehet a modullal jelentkezni a hivatalos Drupal projectek között? Mert mielőtt nekiálltam volna a megírásának, körülnéztem a honlapon a modulok között, és semmi hasonlót nem találtam.

Mindenesetre a modul talán azoknak is hasznos lehet, akik most próbálkoznak a modulok készítésével, szerintem elég sok megjegyzést sikerült beleírnom a megfelelő helyekre.

A modul elérhető a következő címen:
http://koli.lame.hu/~never/xpath_import.zip

Minden építő jellegű visszajelzést szívesen fogadok, és köszönöm előre is, ha tesztelitek.

0
0
RaptoR képe

Helló!

Tesztelgetve a modulodat csak pár apróbb megjegyzésem lenne:
1. Jó lenne, ha a beállítások elmentése utáni frissítésnél ha valami gond adódik valahol, arról tájékoztatna közvetlenül (mármint drupal_set_message fv-nyel), hogy ne kelljen emellett a naplót is nézegetni.
2. A modul bekapcsolásakor ellenőrizhetné, hogy melyik letöltési mód engedélyezett, így csak azt lehetne kiválasztani, ami valóban működni is fog.
3. Az info fájl első sorában asszem egy ; -nek kell lennie, hogy a SVN bekrajon oda pár infót, bár ez jelenleg nem sok vizet zavar. :)

Amint látod, ezek csak apró megjegyzések, amire írtad eredetileg a modult, azt a célt már elérte, ha sikerül eltalálni a helyes Xpath-ot, akkor remekül működik. :)

Nem tudom, mennyire érdemes ebben gondolkodni, de esetleg angolra lefordítva a sztringeket (szükség esetén eltávolítva a megjegyzéseket) érdemes lehet a modullal jelentkezni a hivatalos Drupal projectek között?

Ez jó kérdés, az biztos, hogy sok nyűgöd lesz vele. :) Másrészt viszont Drupal.org-os modulfejlesztőnek lenni szerintem "elismert cím", nomeg biztos sok hasznos tapasztalatot szereznél közen. Ha belevágnál van pár továbbfejlesztési ötletem, amiket valószínüleg az első "feature request"-ek között kapnál:
1. Saját tapasztalatomból kiindulva a legnehezebb dolog az Xpath helyes beírása, ide szerintem írj egy alapvető leírást pár példával, linkekkel további példákra és a Firebugra. Egyik modulnál láttam egy elegáns megoldást: a dokumentációt (pár bekezdés volt) egy összecsukható fieldset-be rakta az adott mező alá, így anélkül lehetett olvasni egy kis segítséget a modulhoz, hogy el kellett volna hagyni az oldalt; csak klikkelni kellett egyet és megjelent. :)
2. Lehessen tetszőleges számú "importot" csinálni külön beálításokkal.
3. Későbbi tervek között szerepelhet az mondjuk, hogy az importált adatokat elmenti a modul, hogy vissza lehessen nézni őket.
4. Egy formai javaslat: amikor már elég nagyra nőtt a modul, és készítesz hozzá egy api.drupal.org-os oldalt, akkor sokat segít, ha Doxygen által ismert formátumban dokumentálod a forrást. Nálam meglepő módon sokkal áttekinthetőbbé tette saját moduloknál a forrást, amikor átálltam erre, lehet azért mert a Quata Plus szerkesztő is ismeri ezt, és szépen kiszínezte a kommenten belül is a különböző elemeket. :)

0
0
nevergone képe

Szia...!

Köszönöm a visszajelzést, bosszantó apró hibákra és hasznos továbbfejlesztési lehetőségekre világítottál rá. Ugyan vannak dolgok, amelyek megvalósításáról egyelőre fogalmam sincs (pl. lehessen tetszőleges számú "importot" csinálni külön beállításokkal), de utánanézek, esetleg megpróbálom értelmezni más modulok forrását.

A hivatalos Drupal projectek közé való felvételére pedig azért gondoltam, mert mielőtt nekiálltam volna az egésznek, körülnéztem a modulok között, és semmi hasonlót nem találtam.

A Doxygen valóban hasznos, mikor nagyobbra nő a project, bevallom eddig fel sem merült bennem (soha nem használtam még), de elolvasva a hozzá kapcsolódó dokumentációkat, nem is olyan bonyolult.

Természetesen, ha esetleg másnak, másféle észrevételei vannak, azt is szívesen várom. :)

0
0
RaptoR képe

Ugyan vannak dolgok, amelyek megvalósításáról egyelőre fogalmam sincs (pl. lehessen tetszőleges számú "importot" csinálni külön beállításokkal) (,,.)

Eddig ugye a variable táblába mentetted az adatokat, mintha egy sima Drupal beállítás lenne. Hogy több importot is tudj kezelni létre kell hozni egy külön táblát erre a célra, és oda menteni a beállításokat külön-külön importonként. Ez nem kis átalakítást jelent a modulodban, de hosszútávon megtérül. :)

0
0
nevergone képe

Alapvetően azért ezt választottam első modulnak, mert olyat szerettem volna, amiben van kihívás, a Drupalból több dolgot is megismerhetek belőle (hook függvények, admin-felület, blokkok kezelése, stb.), viszont nem olyan bonyolult, hogy elvesszek a részletekben.

A külön tábla azért is hasznos, mert nem tudom, mennyire fogja vissza a Drupal teljesítményét, ha egy nagyobb méretű szöveges adatot helyezek el a variable táblában, illetve egy adott méret felett nem is engedi eltárolni. Azt hiszem, az általad javasolt megoldást érdemes lesz most megcsinálnom, amíg nem lesz bonyolultabb a modul. Ha komolyabban akarom venni a modult, nem csak amolyan "játékból fejlesztünk egyet", akkor erre mindenképpen szükség van.
Köszönöm az ötletet. :)

0
0
nevergone képe

Gondolkodtam a dolgon, és szerintem úgy lenne jó (szerintem Te is így gondoltad), ha a modul egyszerre több XPath -ot (esetleg mindegyiknek külön beállítást a későbbiekben) tudna kezelni, melyeket külön blokkokban helyezne el.
Itt jön a kérdés: egy modul hozhat -e létre több blokkot, és ha igen, milyen módon tudja ezeket külön kezelni?

0
0
RaptoR képe

A hook_block 2. paramétere, a $delta mondja meg a modulnak, hogy melyik blokkot kell visszaadnia.

$blocks[0]['info'] = t ('XPath import');
// A 2. így néz ki:
$blocks[1]['info'] = t ('XPath import');

A modul címét persze valahogy dinamikusra kellene megoldanod, hogy meg lehessen különböztetni a blokkokat egymástól. A hook_block többi részénél (view, config stb.) meg ahol kell $delta szerint meg kell különböztetni a blokkokat egymástól. Az user.module-ban van egy jó példa erre, mivel ott 4 blokkot definiálnak egyből. :)

0
0
nevergone képe

Köszönöm a válaszodat, pont erre az információra volt szükségem. A dokumentációt olvasva nem volt teljesen világos a delta szerepe a blokkoknál, de így már világos. :)

0
0