kkwx képe

sikerült megoldanom néhány problémát: több formot csináltam, adatbázis fel/letöltés, validálás, submit... de a hozzáférés-kezelés valahogy nem akar működni :S

ez a kódom:

function room_reserver_perm() {
  return array('access reservation form', 'administrate own reservastions', 'administration');
}
 
function room_reserver_menu() {
  $items = array();
 
  $items['reservation'] = array(
    'title' => 'Foglalás',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('room_reserver_myform'),
    'type' => MENU_NORMAL_ITEM,
    'access arguments' => array('access reservation form'), 
  );
  $items['reservations'] = array(
    'title' => 'Foglalás',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('room_reserver_reserve'),
    'type' => MENU_NORMAL_ITEM,
    'access arguments' => array('administrate own reservastions'), 
  );
 
  return $items;
}
 
 
function room_reserver_myform() {
 
  $form = array();
  $form['#submit'] = array('room_reserver_myform_submit');
 
$form['nev'] = array(
    '#type'=> 'textfield',
    '#title' => t('Név'),
    '#required' => TRUE,
    '#description' => t('Adja meg a nevét!'),
  );
 
$form['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Foglalás elküldése'),
  );
  return $form;
}

Meg is jelennek a beállított pontok ('access reservation form', 'administrate own reservastions', 'administration') a Jogosultságoknál, de nincs jelentősége, hogy be vannak-e kapcsolva, mert alapból ki van kapcsolva mind és mégis megjelenik az űrlap mindenkinek :(. Tudna valaki segíteni, hogy mi lehet a gond?

0
0
Lavjaman képe

A megírt form-odat valahol meg kell jelenítened.
Pl: csinálsz egy hook_menu()-t az alábbi struktúrával:

/**
 * Implementation of hook_menu().
 */
function reserve_menu() {
  $items = array();
 
  $items['reservation'] = array(
    'title' => 'Foglalás',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('reserve_myform'),
    'type' => MENU_NORMAL_ITEM,
    'access arguments' => array('access content'),
  );
 
  return $item;
}

Ahhoz, hogy működjön a frissen létrehozott menü, látogasd meg mentés után az admin/build/modules oldalt.

btw: sok lehetőséged van a form-ok kezelésére. Pl: system_settings_form függvény, bár esetedben érdemes saját submit függvényt írni hozzá.

a jogosultságkezeléssel kapcsolatban, pedig olvass utánna a hook_access függvénynek.

0
0

*----*----*

$node ? 'alma' : 'bor'

*----*----*

tamoca képe

Hello,

Nekem több kérdés is felmerül, mivel csináltam már ilyet más rendszerhez.

Egyrészt ez a csv-s kommunikáció napi szinten kell,Igen naponta akár
többször, de a feladás idejére ki kell lépniük a rendszerből, vagy este , vagy
munka után, ez nem gond, de lehessen időzíteni ha az ügyfélnek van amúgy szervere
ami megy éjjel is.
mivel a termékek raktárkészlete, ára folyamatosan
változik, és egy nem 30, csak 10.000 termékszámnál ez a művelet elég sokáig
szokott tartani,valóban sokáig tart az importálás folyamata nagy memória
kell , de van megfelelő tárhelyszolgáltató, az export az megvan egy pillanat
alatt ,az ügyviteli szoftver fel is tölti ftp-re ami egy beállított hely a
tárhelyen és hozzáférne a Drupal, de az ügyfél csak az ftp mappájához fér hozzá
a weboldal többi részéhez nem
mivel a szövegfilet fel kell olvasni,
esetleg átmeneti táblába berakni, és utána sql updatek ezrei futnak le.

Másik alapkérdés, hogy és mi az az ügyviteli program mely támogatja az exportot
automatizáltan?saját progi és lehet a kereskedő által egy egérkattintással
manuálisan is ahogy akarja , de jó lenne ha éjjel automatikusan mehetne, persze
ha nagy a változás napközben akkor hadd eressze rá a frissítést ha akarja


Mert amikkel eddig dolgom volt, szinte mind vmi dbase alapú szutyok volt, de
akadt foxpro-s foxprois.. de legkevésbé sem volr sql80%
ban megvan , de a feladás egyforma lesz majd az is lehet ugyanez a struktúra,
tehát ha alá van téve az új rendszer az mindegy a weboldalnak
alapú,
és igen nehéz belőle adatokat kinyerni naponta akár több alkalommal is, teljesen
automatikusan.

És akkor ez egy irány, hogy a bolti rendszer megfrissíti az áruházat, ami adatok
alatt ugye, csak cikkszám, db, ár, megnevezés értendő, mivel avan és
feladható ha változik
termékleírás, az ügyviteli szoftver helyi
mappájában a képek jpg-k és a nevük megegyezik a cikkszámmal csak át kell méretezni
gondolom igame_cache-vel
fénykép(ek)-et nem támogatják ezek a raktári/számlázó
rendszerek, így ezt kézzel kell egyenként megtenni, és szükségesigen
amit beemelne vevő rendelésnek és a vevőtörzsbe is ha új az ügyfél

egy vissza-irány, lehetőség szerint szinte realtime, ha megrendelés történik
a shop-ban akkor az a termék az ügyviteli rendszerbe megjelenjen foglalásba,
vagy netán, már számla előkészítés, vagy rendelés formájában.

Nagyon sok baj van ezen a téren,igen , az ügyviteli és a webáruház nem
egy adatbázis a frissítés közt nem jön létre a foglalás ez előfordulhat, de
megfelelő odafigyeléssel a bejövő megrendelés foglalja a készletet

mivel ha van olyan termék, amiből 1db van, akkor azt rendszerint eladják a boltban,
és közben a shop-on keresztül is, majd jön a telefonálgatás, mérgelődés.

Én most vettem fel a kapcsolatot egy számlázó/raktár rendszer fejlesztő céggel
emiatt, hogy dolgozzunk összedolgozzunk össze, mivel a legtöbb
gond ott van, hogy ezek a cégek elzárkóznak a webshop-ok felé történő kommunikációtólmi
nem
. Ez a cég végre vette a lapot és jó irányba fejlesztenek, sima
http get-en keresztül jönnek mennek az adatok, így ha pl. eladnak vmit a boltban,
meghívják az áruházat megadott url-en és átadják neki ezt, így már nem tudják
eladni 2x a terméket és a, rendelés feldolgozás is kezd kialakulni.

Tehát érdemes ezt jól körüljárni, mert csv-kkel ez a kérdés nehezen kezelhető
le, inkább a SOAP, vagy ha az túl bonyolultnak tűnik, sima http get-ekkel megoldani,
mert az azonnal meg tud történni, nincs késleltetés.

folytassuk...

0
0

tamoca

Sk8erPeter képe

Tényleg most is úgy érezted, hogy "Ezért kár volt koptatni a billentyűzetet" (downvote)? Hmm, pedig a kérdéseidre válaszoltam, hogy legalább megpróbáljam alátámasztani azt, amit írtam. Bár lehet, hogy a -1 nálad azt jelenti, hogy csak nem értesz egyet. :) Egyébként azt állítani, hogy "levegőben lóg" az érvelésem, picit most a Te részedről hangzik sértőn, miután konkrétumokat mondtam, hogy megpróbáljam alátámasztani azt, amit korábban állítottam, nem csak elfutottam a vita elől. Az már másik kérdés, hogy más állásponton vagyunk. (Ami nem is baj.)
No mindegy, térjünk a lényegre.

általad javasolt megoldás nem a memóriát, sok minden más erőforrást használ túlzottan, hisz nem kéne azokat használni, ha a memóriában lenne minden adat. Használja a merevlemezt, plusz processzor erőforrást, és még talán hálózati kapcsolatot is.

Túlzottan használja az erőforrásokat egy adatbázishoz kapcsolódás+query esetén? Komolyan ezt boncolgatjuk, amikor Drupalról beszélünk? Rég probléma, ha szűk keresztmetszetet jelent az adatbázis használata. Én is feltennék egy fontos költői kérdést: honnan tudjuk, mennyi memória áll rendelkezésére a felhasználónak (PHP memory_limit)?
Értem, most itt, ennél az egyetlen feladatnál spóroljuk le az adatbázis-szerverhez nyúlás idejét, annak erőforrás-használatát, azt a pár milliszekundum alatt lefutó query-t, és helyette nyugodt szívvel tömködjük a memóriát többezer adattal igazából feleslegesen, menjünk végig szépen a nagy tömbünkön, annak minden elemén egy ciklussal ahelyett, hogy egy több helyen is ÚJRAFELHASZNÁLHATÓ megoldást választanánk - pont, mint amilyet például az addressfield_hu kínál. Na de vegyük az utóbbi esetet is: adatbázisban lesznek az adataink, és többféle módon tudunk ezek között szűrni. A településlista, irányítószámlista, ehhez kapcsolódó dolgok újrafelhasználhatónak számítanak, ebben egyetértünk, ugye? (Remélem, legalább ebben.) Bár erre a fájlos megoldást támogatók részéről lehetne egy reakció élből, hogy ilyen alapon végül is be lehetne nyomni külön fájlba is ezt a többezer adatot az irányítószámokkal, településekkel, egy remek mágikus függvénybe, aztán valami rendkívül kreatív megoldással megpróbálni újrafelhasználhatóvá tenni azt.
DE még mindig nem láttam a hozzászólásaidban az igazi ellenérvet arra, amit én javasoltam alternatívaként, hogy ugyan használjuk már azt az eszközt erre, ami pontosan ilyen jellegű feladatokra való - adatok tárolására, adatok közötti, lehetőleg optimalizált szűrésre, keresésre, tárolásra. Az adatbázismotor éppen erre lett kitalálva: többezer adatban és akár egymillió adat között is lehet vele megfelelő indexelés esetén milliszekundumok alatt megszülető eredményt találni (hogy ne járna ez erőforrás-használattal?), ugyanezt nyilvánvalóan nem lehet elmondani a PHP-ról. Nem erre lett kitalálva.
A gondolatmeneted alapján - nincs ugyanis ugye elméleti határ, mint írtad: van-e értelme egyáltalán ilyenről beszélni? - akár többtízezres, többszázezres adatmennyiség is benyomható lenne beparse-olandó PHP-kódba, végül is az tök jó, hogy ott van a memóriában, ha esetleg épp kell. De nyilván Te sem így értetted (feltételezem), csak mondom, hogy a Te érvelésedből pedig ezt a téves következtetést is levonhatná akár a beszélgetésünket olvasó fórumozó. (Mitől függ a határ? Van határ?)
Akkor pedig az általad említett "túlzott", adatbázis-használatból eredő plusz erőforrás-használat is jócskán alulmarad ahhoz képest, amennyit a PHP-kód a futása során kajálni fog.
Amúgy létezik query cache is, ha már itt tartunk. :))) (Persze ez nem ment meg minket az adatbázis-szerverhez kapcsolódástól.)

Akkor beszéljünk az APC-ről. Hány osztott tárhelyes megoldásnál van szted nagy átlagban APC? A nagy átlag pedig teljesen érthető módon az osztott tárhelyes megoldást választja.
Milyen többszáz szájtról beszélünk, pontosabban miért beszélünk most többszáz szájtra alkalmazható/alkalmazandó megoldásokról, amikor itt - valószínűleg - egyetlen oldalról van csupán szó? Minél több kapacitás áll rendelkezésre, annál inkább megváltoznak az alkalmazható lehetőségek. Igen, APC-nél valószínűleg bent tartja a memóriában. Tényleg jó az, hogy ott terpeszkedik a memóriában? Attól függ! (Na, lehet, hogy ebben közös nevezőn vagyunk! :D) De továbbra is beszéljünk lehetőleg az általános esetekről, hiszen minden komolyabb környezet más és más lehetőségeket kínál. Osztott tárhely: korlátozott memória, általában a PHP-s memory_limit 128 MB vagy 256 MB körül mozog. Drupalról van szó, nem olyan sok az. Minek pazarolni? A Drupal a komplexitása miatt amúgy sem spórol szegénnyel.
Abban az egyben egészen biztos, hogy egyetértünk, hogy a megvalósítás helyessége mindig függ a környezettől és magától a feladattól. Standard megoldásokat persze épp emiatt nehéz mondani, ettől függetlenül az általános felhasználásnál nem biztos, hogy van értelme kapásból feltételezni, hogy bőven rendelkezünk szabad kapacitásokkal.
Ja, tényleg, amúgy osztott tárhelynél a MySQL-szerver általában egyébként is localhoston van. :) (Nincs távoli kapcsolódás miatti overhead.)

Konkrét elméleti határokról amúgy persze, hogy nincs értelme beszélni, de nehogy már azt tartsuk helyes megoldásnak általánosságban, hogy többezer adatot tök feleslegesen nyomjunk csak be nyugodtan a memóriába, aztán szépen egyesével lépdeljünk végig a jó nagy tömbünkön, úgyis remélhetőleg van kapacitás elég. Ha nincs, akkor meg nézhetjük át a kódot a kritikus pontok után kutatva.

Az egészbe amúgy azért ugattam bele, mert az én szememet bántotta, ez egyáltalán nem jelenti azt, hogy nálam van az erő, meg a tudás, sőt, Te nálam ezerszer tapasztaltabb vagy, de mivel ekkora adatmennyiségről van szó, semmiféle racionális érvet nem látok amellett, hogy miért is kellene ezt PHP-kódban tárolni, ha a konkrét esetet vizsgáljuk. Komolyabb kódoknál nem is láttam ilyenre precedenst, hogy komplett település- és irányítószámlistákat nyomtak volna bele nyelvfüggő (ráadásul!) implementációba.

Jaj, bocsi, még egy utolsó - talán nem levegőben lógó - érv, mielőtt elfelejtem: Szilárd az általam már idézett kódjában MINDEN esetben (!!) végigmegy az EGÉSZ tömbön, annak ÖSSZES elemén, még abban az esetben is, ha már akár a második lépésben megtalálta a kérdéses elemet. Tehát nem lép ki a ciklusból még találat esetén sem. Erőforrás-foglalás++, futási_idő++. :)))

0
0
kkwx képe

ú, mégse :(, ez nagyon jó kis modul és hasznos. fel is használnám ezt a weblapon ha nem az lenne a feladatom, hogy írjak egy modult :(, így még mindig az űrlap megjelenítésével bajlódok :(...

megírtam a modult (remélem jól), majd aktiváltam a modult a weblapon, de megjeleníteni nem tudom :(. olvastam neten, hogy a "drupal_get_form()"-al vagy a "drupal_execute()" funkciókkal lehet csinálni, de nem teljesen értem a működésüket, hogy ezeket hova írjam, miket kell meadni paramétereknek ($form_id, &$form_state...) és utána hol jelenik meg az űrlap?

Bocs ha nagyon idióta dolgokat kérdezek, csak sajnos nem nagyon találtam használható magyar leírást, pedig hasznos lenne a modulírás / űrlapcsinálásról valami ami elmagyarázná a dolgokat :( (vagy lenne egy sima űrlap modulra példám :) ), persze tudok angolul, de olyan szinten nem, hogy teljes mértékben megértsem a leírásokat...
Szóval kösz előre is minden segítséget :)

ez a kódom a modul fájlban:

function room_reserver_init() {
	// drupal_set_message(t('Drupal modulom.'));
}
function room_reserver_myform() {
  $form['firstname'] = array(
    '#type'=> 'textfield',
    '#title' => t('First name'),
    '#required' => TRUE,
  );
  $form['lastname'] = array(
    '#type'=> 'textfield',
    '#title' => t('Last name'),
    '#required' => TRUE,
  );
  $form['radio'] = array(
    '#type' => 'radio',
    '#title' => t('Sex'),
    '#default_value' => 'Male',
    '#options' => array(
      1 => 'Male',
      2 => 'Female',
    ),
    '#description' => t('Please choose an option.'),
  );
$form['submit'] = array(
  '#type' => 'submit',
  '#value' => t('Elküldés'),
);
  return $form;
}
function room_reserver_menu() {
  $items = array(); 
  $items['reservation'] = array(
    'title' => 'Foglalás',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('room_reserver_myform'),
    'type' => MENU_NORMAL_ITEM,
    'access arguments' => array('access content'),
  ); 
  return $item;
}
function room_reserver_page() {
  return drupal_get_form('room_reserver_myform');
}
0
0
Lavjaman képe

gondolom azt a hook_menu-t egy az egybe bemásoltad. Lemaradt a végén egy 's' a return-nél :)

/**
  * Implementation of hook_perm().
  */
function reserve_perm() {
  return array('access reservation form');
}
 
 
/**
  * Implementation of hook_menu().
  */
function reserve_menu() {
  $items = array();
 
  $items['reservation'] = array(
    'title' => 'Foglalás',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('room_reserver_myform'),
    'type' => MENU_NORMAL_ITEM,
    'access arguments' => array('access reservation form'), //így csak az fér hozzá, aki benne van abban a csoportban, amelyikre engedélyezed ezt a hozzáférést
  );
 
  return $items;
}
 
 
function room_reserver_myform() {
  $form = array();
  $form['#submit'] = array('room_reserver_myform_submit');
 
  $form['firstname'] = array(
    '#type'=> 'textfield',
    '#title' => t('First name'),
    '#required' => TRUE,
  );
  $form['lastname'] = array(
    '#type'=> 'textfield',
    '#title' => t('Last name'),
    '#required' => TRUE,
  );
  $form['radio'] = array(
    '#type' => 'radio',
    '#title' => t('Sex'),
    '#default_value' => 'Male',
    '#options' => array(
      1 => 'Male',
      2 => 'Female',
    ),
    '#description' => t('Please choose an option.'),
  );
 
  $form['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Elküldés'),
  );
  return $form;
}
 
function room_reserver_myform_submit($form, &$form_state) {
  //a form state-ben találhatóak az POST-olt adatok
  $values = $form_state['values'];
  //itt pedig elmendheted, ahogy kedved tartja.
  //viszont ha saját táblákkal dolgozol, akkor írj egy .install file-t is.
}
0
0

*----*----*

$node ? 'alma' : 'bor'

*----*----*