hekk vagy Views modul
Ha az Aktív fórum témák blokkban a linkek fölé viszed az egeret, akkor mutatja, hogy hány hozzászólás érkezett eddig az adott témához (ez a link 'title' attribútuma).
Azt hittem, hogy valahogy ki lehet emelni ezt a 'title' értéket a cím után zárójelbe, de nagyon be van csomagolva, meg kellene hekkelni hozzá a Forum modult. Nem hinném, hogy megéri.
Ha fent van nálad a Views modul, akkor egyszerűen tudsz készíteni egy táblázatot, ahol a Fields résznél megadod, hogy a táblázat első oszlopában szerepeljen a cím (Node Title), második oszlopában pedig a Comment Count (hozzászólások száma).
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
jogos
Ezzel szemben, ha már eleve látod, hogy 6 különböző .tpl.php-t kell módosítanod, akkor 6 különböző helyet is fogsz tesztelni. Ekkor szerintem jóval nagyobb az esélye annak, hogy jó munkát adsz ki a kezeid közül. Nyilván megvannak a praktikáid, hogy ezeket a problémákat kikerüld.
A praktika annyi, hogy nagyon részletesen kommentezem a template.php-t. Rögtön látom, hogy 6 helyen volt módosítás, és még azt is, hogy pontosan micsoda.
De visszakanyarodva az eredeti problémára, nekem az volt a bajom, hogy egy figyelmeztetéseket dobó megoldást legszebbnek neveztünk.
Igen, ez jogos.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
views relationships
1. van-e hátránya ennek a szerintem szép, logikus megoldásnak?
1 helyett 2 tartalmat kell kihúzni az adatbázisból. Nagy terhelésű oldalon ez esetleg problémát jelenthet.
2. View-ban hogyan tudok a beágyazott kép tartalomtípus mezőire hivatkozni?
Az Advanced > Relationships résznél nézz szét, ott tudod megmondani a Views-nak, hogy a kapcsolódó kép típusú tartalmat is hívja be a nézetbe. Amikor új mezőt, szűrőt, stb. veszel fel, akkor lesz választási lehetőséged, hogy pl. egy cím mező az alap tartalom, vagy a relationship útján behívott kapcsolt tartalom címét jelenítse meg.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Pozitív javaslataid vannak
Sok esetben ami felhasználóbarát megoldásnak tűnik máshol buk el, lásd ez esetben. Én megértem, hogy az Adminok az DO példát követik, mert azt könnyebb karban tartni vagy biztosabb útvonalat jelent a fix azonosító miatt. Csak halvány lövésünk lehet, hogy mennyire nagy monstrum a DHU. Persze emiatt le kell mondani mindarról amit javasoltál, ami néha tényleg jól jönne.
Sebaj, ha háromból legalább egy javaslatot be lehet építeni és azzal megkönnyíteni a portál használatát (lásd pl. a egyedi tartalom szűrés vagy az editor kérdése), már megérte ide beírni. Köszi!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hm
A világmegváltásház nem tudok hozzászólni. Amit elvársz, irreális, de nem baj. Ha van konkrét problémád, amit -- úgy gondolod -- Drupallal szépen meg lehetne oldani, akkor várom leveled.
Lehet, hogy a weblaboron augusztusban írtál, azt én nem láttam.
A nyílt forrású fejlesztés az úgy megy, hogy nekem van valami problémám a munkámban. Pl. a Drupal nem kezeli elég jól a több nyelvű weboldalakat, ezért beszállok az i18n modul fejlesztésébe. A munkám ingyen közreadom, mert tudom, hogy ha így teszek, akkor a többiek továbbfejleszthetik az én művem, és ezért nekem jó lesz. Nem vagyunk szerzetesek, akik egy magasabb Jó érdekében cselekszünk. Mindennapi megélhetésünkért dolgozó, hétköznapi emberek vagyunk.
Igen, lett volna időnk augusztus óta. Erre a kérdésre felelj: ha ezzel foglalkozom, és nem a fizetős munkáimmal, akkor miből élek azóta?
A dokumentáció gyakran háttérbe szorul. És nem azért, mert azt akarjuk, hogy csak mi ismerjük a trükköket. Egyszerűen nincs meg a megírására a mozgatóerő. Ha ez a hepped, fizesd meg! Ott az FSF alapítvány, ha rajtuk keresztül folyatod a pénzed, akkor adózásilag is jól jársz...
Hogy lásd, nem minden közvetlen pénzkérdés, nézzük meg, miért éri meg a PHP konferencián előadni. Mert szeretném referenciának odatenni, hogy bizony, ilyen nívós mezőnybe is belefértem, mint előadó. Mérlegeltem az erre fordított időmet (ez a költség) és a referenciát (ez a haszon) és úgy döntöttem, megéri. Magyarázd már el, miért éri meg azon dolgozni, amit te elvársz?
A szabad szoftverek nem azt jelentik, hogy eljövend a Kánaán, hol a bőség kosarából mindenki egyaránt vehet...
Az arcodból meg vegyél vissza, miért feltételezed, hogy itt bárkinek van ideje a weblabor összes postját elolvasni? Ezt még Goba sem hiszem, hogy megtenné, hiába ő az egyik admin odaát.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Struktúrált tartalom
Persze, világos, csak sajnos még nagyon az elején tartok a web-programozás és drupallal való ismerkedésben is, és valószínűleg sokszor rossz irányból közelítek (maga a programozás nem idegen, nagyon régóta csinálom, csak eddig nem webes környezetben).
Ami az itteni konkrét problémát illeti, talán egyszerűbb, ha megmutatom, hogy miből indulok ki, hol tartok, és hová szeretnék eljutni:
- kiindulás: http://www.felhout.hu/ppg/szakc/ppgesemeny.html
- holtartok: http://www.felhout.hu/drupal/node/10
- a cél egyszer majd: http://usppamembers.org/incidents/incident_list_public1.cfm
A "hol tartok" egyelőre csak teszt (az egész honlap az), nem publikus, a "cél" eléréséhez viszont magát a tartalmat is újra fel kell dolgozni, ami az egyéb munkák mellett (a régi honlap komplett átvitele drupal alá) egyelőre kis priorítással bír. Viszont ha gyorsan összedobható egy ilyen adatbeviteli és megjelenítési felület, akkor előre tenném, mert abból jól látszana a joomlaval próbálkozó haverom számára, hogy a drupal lesz a nyerő, koncentráljon inkább erre.
Szóval szerény ismereteim szerint ehhez csinálni kellene ugye flexinode-dal, vagy cck-val valamijen adatstrukltúrát, űrlapokat és megjelenítő felületet. Jól gondolom? Eddig azért nem mertem belevágni ebbe, mert még az alaprendszerrel se vagyok teljesen tisztában. Nagyon megköszönném, ha tudnátok adni egy rövidke "sorvezetőt", hogy milyen lépésekben olvassak utána a dolgoknak, hogy gyorsan eljuthassak a célig, vagy az is elég, ha azt mondjátok, hogy ez ezen a szinten túl bonyolult, hagyjam inkább későbbre.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Megrendelő vs. vállalkozó
A 'megrendelői viselkedés kultúrájához':
A szoftveres szakmának sem a belső működése, sem a megítélése nem olyan érett, mint pl. a mérnöki szakmáké. Az, aki szoftvert szeretne megrendelni egy hozzáértőtől, voltaképpen semmijen 'megrendelői tradícióra' nem tud támaszkodni, hiszen ilyen tevékenység tömeges formában alig egy generáció óta létezik. De még a fejlesztő se tud igazán hagyományokra, megbízható tapasztalati bázisra támaszkodni.
Igazság szerint nem tudjuk, hogyan kell egy nagyobb szoftveres projektet úgy tervezni, hogy biztosan ne legyen csúszás a határidővel / költségekkel. Nem tudjuk, hogy egy kicsinek látszó feladat valóban kicsi-e, csak ha már elkezdjük megoldani (lásd a topic eredeti témáját). Nem tudunk olyan specit ill. tervet írni, hogy a megvalósítást 'szakmunkások' szabott idő alatt tudják megoldani.
A laikus megrendelő meg főleg nem tudhatja ezeket. Ezért szerintem egyszerűen inadekvát az a hozzáállás, hogy 'tessék, ezt csináld meg, de aztán rendesen', mivel a kért termék még fejben sem létezik. Hiába várod, kedves Béla, hogy 'rendesen szolgáljanak ki engem a pénzemért', hisz magad sem tudod, mitől is lennél elégedett a végén. Szoros együttműködésben lehet csak jól kezelni egy ilyen ügyet, valahogy úgy, ahogy 'uborka' csinálja a belsőépítészetet, vagy az építészmérnök a háztervezést.
Az egyetlen, amit valóban elvárhatsz, hogy tisztán, korrekten kommunikáljanak veled. Lehet, hogy a második két fejlesztő igéretet tett, amit nem tartott be, és nem is kommunikálta le ezt korrekt módon. Ha így van, ez az ő személyes problémájuk, és erről a panaszod jogos. Egyébként ez nem ritka ebben a szakmában (sem).
De abban biztos vagyok, hogy egy ilyen feladat nem kezelhető a hardverboltos sablon szerint. Hiába lobogtatod a pénzedet, hiába vagy öntudatos, hogy te vagy az ügyfél, ha az ügy másik feléről nem veszel tudomást, és te magad nem veszel részt a megoldásban.
Content Access / ACL
Egy híroldalon dolgozom. Van egy tartalom típusom, neve Cikk; benne rengeteg CCK filed. A teaser nézetek megvalósítását a kiváló Views modul végzi, melyből már szintén van egynéhány; ugyanakkor ezek már kötődnek a Cikk tartalom típushoz, hiszen vannak view-k a címlapon, oldalt, rovatoldalakon, stb. Ezeket nem szeretném már megbolygatni.
Ugyanakkor a Cikk tartalom típusom által beküldött tartalmak a CCK fieldek sokasága miatt már nem alkalmas arra, hogy úgy ahogy van cikk-ként megjeleníthető, ill. szalonképes legyen, hiszen a cím, szöveg, stb. mellett vannak benne különböző promóciós célokat szolgáló field-ek is. Ezért bevezettem a Cikk2-t, amely már csak azokat a mezőket tartalmazza, melyeket meg akarok jeleníteni: cikk címe, szövege, és kb. ennyi. Nem mintha elegáns megoldásnak tartanám, de jobb ötletem egyenlőre nem volt.
Amit konkrétan szeretnék, az az, hogy a Cikk tipusú tartalmakhoz való hozzáférést URL-ek alapján korlátozzam, hiszen ezeket nem szeretném, hogy mások is láthassák, mert amit mások is lássanak, arra ott lesz a Cikk2.
A Content Access / ACL modulok szintén kiválóak, és kifogástalanul működnek nálam is, de az a baj, hogy a már meglévő Cikk tartalom típus alapján létrehozott view-kat is eltűnteti. Ez pedig nem a kívánt eredmény...
A Path Access modulban megadható az URL, így "mondhatom" pl. azt, hogy hozzáférés tíltva: 'tiltott-tartalmak/*'
Valamennyi Cikk tartalom típust berakhatnék a 'tiltott-tartalmak' URL alá, így a path_access letíltaná elvileg az útvonalat. Ez azért lenne jó, mert így a már meglévő Views modul által létrehozott listáim, más szóval az eddigi munkám, nem tűnne el, vagyis a címoldali teaser-ek maradnak, az oldal view-blokkok maradnak, stb.
Gábor
moroder
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Örülök, hogy ilyen szép témát
Örülök, hogy ilyen szép témát választott a hallgatód, összességében jól összerakott munka, néhány észrevétel:
5. Költsége: A webáruház költségigénye ezzel szemben elenyésző számunkra. Nem
kell új raktárakat kialakítani, a meglévő árukészletet lehet ajánlani az interneten. Nem
szükséges új személyzet, nincs eladó, nincs új pénztáros, nem kell új bolthelységet
kialakítani vagy vásárolni. Röviden összefoglalva: Kis befektetéssel járó értékesítési lehetőség éjjel-nappal, mindenkinek.
Ez nagyon nem igaz. Igenis kell új személyzet, aki a termékeket az internetre feltölti. Ez külön kompetenciát igényel, és egy komoly boltnál ez rengeteg idő (fényképezés, fényképek retusálása, termékadatok összevadászása), kellhet külön ügyfélszolgálat, aki a megnövekedett érdeklődést ki tudja szolgálni. Igen komoly költség ez.
Lehetőségünk van szállítási költség hozzáadására, illetve online fizetést is biztosíthatunk, amennyiben erre van szükségünk.
A gond az, hogy a tengerentúlon elterjedt fizetési módok közül választhatunk, magyar viszonylatban használt lehetőségek pedig nincsenek implementálva.
A webáruház karbantartója ugyanaz az adminisztrátor lesz, aki az oldalt létrehozta.
Ő fogja módosítani a szükséges beállításokat, és az új termékek, hírek, fórumok, stb.
felvitele is az ő feladata lesz.
Erre általában egy külön jogosultságú csoportot érdemes létrehozni.
Nem esett szó olyan kérdésekről, mint
- kinek éri meg webáruházat üzemeltetni?
- EU-n belüli kereskedelem uniós adószám esetében
- szállítási költség változása régiók, súly, érték, űrméret tekintetében
- számlakészítés
- összekapcsolás a bolt saját készletnyílvántartásával
- összekapcsolás a magyarországi online fizetési lehetőségekkel
- összekapcsolás a futárszolgálatok nyomkövetési rendszerével
Nem tudom, mennyire tekinthető befejezettnek a szakdolgozat, szívesen olvasnék erről is egy e-kereskedelmi szakdolgozatban.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
nem lehet
Szerencsére nem lehet rávenni az engine-t, hogy egy másik webhelyen lévő képet, amihez neki semmi köze, átméretezzen..:)
A normálisabb böngészőket viszont rá lehet venni arra, hogy a letöltött képeket legfeljebb x méretben jelenítsék meg, erre való a CSS max-width tulajdonsága. Példa: Scalable Figures and Captions with CSS and HTML.
Sajnos az IE6-ban nincs max-width támogatás (IE7-ben van).
Egyébként elég udvariatlan dolog mások szerverén lévő képeket behívni és az erőforrásaikon élősködni.