PNG  IHDRX cHRMz&u0`:pQ<bKGD pHYsodtIME MeqIDATxw]Wug^Qd˶ 6`!N:!@xI~)%7%@Bh&`lnjVF29gΨ4E$|>cɚ{gk= %,a KX%,a KX%,a KX%,a KX%,a KX%,a KX%, b` ǟzeאfp]<!SJmɤY޲ڿ,%c ~ع9VH.!Ͳz&QynֺTkRR.BLHi٪:l;@(!MԴ=žI,:o&N'Kù\vRmJ雵֫AWic H@" !: Cé||]k-Ha oݜ:y F())u]aG7*JV@J415p=sZH!=!DRʯvɱh~V\}v/GKY$n]"X"}t@ xS76^[bw4dsce)2dU0 CkMa-U5tvLƀ~mlMwfGE/-]7XAƟ`׮g ewxwC4\[~7@O-Q( a*XGƒ{ ՟}$_y3tĐƤatgvێi|K=uVyrŲlLӪuܿzwk$m87k( `múcE)"@rK( z4$D; 2kW=Xb$V[Ru819קR~qloѱDyįݎ*mxw]y5e4K@ЃI0A D@"BDk_)N\8͜9dz"fK0zɿvM /.:2O{ Nb=M=7>??Zuo32 DLD@D| &+֎C #B8ַ`bOb $D#ͮҪtx]%`ES`Ru[=¾!@Od37LJ0!OIR4m]GZRJu$‡c=%~s@6SKy?CeIh:[vR@Lh | (BhAMy=݃  G"'wzn޺~8ԽSh ~T*A:xR[ܹ?X[uKL_=fDȊ؂p0}7=D$Ekq!/t.*2ʼnDbŞ}DijYaȲ(""6HA;:LzxQ‘(SQQ}*PL*fc\s `/d'QXW, e`#kPGZuŞuO{{wm[&NBTiiI0bukcA9<4@SӊH*؎4U/'2U5.(9JuDfrޱtycU%j(:RUbArLֺN)udA':uGQN"-"Is.*+k@ `Ojs@yU/ H:l;@yyTn}_yw!VkRJ4P)~y#)r,D =ě"Q]ci'%HI4ZL0"MJy 8A{ aN<8D"1#IJi >XjX֔#@>-{vN!8tRݻ^)N_╗FJEk]CT՟ YP:_|H1@ CBk]yKYp|og?*dGvzنzӴzjֺNkC~AbZƷ`.H)=!QͷVTT(| u78y֮}|[8-Vjp%2JPk[}ԉaH8Wpqhwr:vWª<}l77_~{s۴V+RCģ%WRZ\AqHifɤL36: #F:p]Bq/z{0CU6ݳEv_^k7'>sq*+kH%a`0ԣisqにtү04gVgW΂iJiS'3w.w}l6MC2uԯ|>JF5`fV5m`Y**Db1FKNttu]4ccsQNnex/87+}xaUW9y>ͯ骵G{䩓Գ3+vU}~jJ.NFRD7<aJDB1#ҳgSb,+CS?/ VG J?|?,2#M9}B)MiE+G`-wo߫V`fio(}S^4e~V4bHOYb"b#E)dda:'?}׮4繏`{7Z"uny-?ǹ;0MKx{:_pÚmFמ:F " .LFQLG)Q8qN q¯¯3wOvxDb\. BKD9_NN &L:4D{mm o^tֽ:q!ƥ}K+<"m78N< ywsard5+Š²z~mnG)=}lYݧNj'QJS{S :UYS-952?&O-:W}(!6Mk4+>A>j+i|<<|;ر^߉=HE|V#F)Emm#}/"y GII웻Jі94+v뾧xu~5C95~ūH>c@덉pʃ1/4-A2G%7>m;–Y,cyyaln" ?ƻ!ʪ<{~h~i y.zZB̃/,雋SiC/JFMmBH&&FAbϓO^tubbb_hZ{_QZ-sύodFgO(6]TJA˯#`۶ɟ( %$&+V'~hiYy>922 Wp74Zkq+Ovn錄c>8~GqܲcWꂎz@"1A.}T)uiW4="jJ2W7mU/N0gcqܗOO}?9/wìXžΏ0 >֩(V^Rh32!Hj5`;O28؇2#ݕf3 ?sJd8NJ@7O0 b־?lldщ̡&|9C.8RTWwxWy46ah嘦mh٤&l zCy!PY?: CJyв]dm4ǜҐR޻RլhX{FƯanшQI@x' ao(kUUuxW_Ñ줮[w8 FRJ(8˼)_mQ _!RJhm=!cVmm ?sFOnll6Qk}alY}; "baӌ~M0w,Ggw2W:G/k2%R,_=u`WU R.9T"v,<\Ik޽/2110Ӿxc0gyC&Ny޽JҢrV6N ``یeA16"J³+Rj*;BϜkZPJaÍ<Jyw:NP8/D$ 011z֊Ⱳ3ι֘k1V_"h!JPIΣ'ɜ* aEAd:ݺ>y<}Lp&PlRfTb1]o .2EW\ͮ]38؋rTJsǏP@芎sF\> P^+dYJLbJ C-xϐn> ι$nj,;Ǖa FU *择|h ~izť3ᤓ`K'-f tL7JK+vf2)V'-sFuB4i+m+@My=O҈0"|Yxoj,3]:cо3 $#uŘ%Y"y죯LebqtҢVzq¼X)~>4L׶m~[1_k?kxֺQ`\ |ٛY4Ѯr!)N9{56(iNq}O()Em]=F&u?$HypWUeB\k]JɩSع9 Zqg4ZĊo oMcjZBU]B\TUd34ݝ~:7ڶSUsB0Z3srx 7`:5xcx !qZA!;%͚7&P H<WL!džOb5kF)xor^aujƍ7 Ǡ8/p^(L>ὴ-B,{ۇWzֺ^k]3\EE@7>lYBȝR.oHnXO/}sB|.i@ɥDB4tcm,@ӣgdtJ!lH$_vN166L__'Z)y&kH;:,Y7=J 9cG) V\hjiE;gya~%ks_nC~Er er)muuMg2;֫R)Md) ,¶ 2-wr#F7<-BBn~_(o=KO㭇[Xv eN_SMgSҐ BS헃D%g_N:/pe -wkG*9yYSZS.9cREL !k}<4_Xs#FmҶ:7R$i,fi!~' # !6/S6y@kZkZcX)%5V4P]VGYq%H1!;e1MV<!ϐHO021Dp= HMs~~a)ަu7G^];git!Frl]H/L$=AeUvZE4P\.,xi {-~p?2b#amXAHq)MWǾI_r`S Hz&|{ +ʖ_= (YS(_g0a03M`I&'9vl?MM+m~}*xT۲(fY*V4x@29s{DaY"toGNTO+xCAO~4Ϳ;p`Ѫ:>Ҵ7K 3}+0 387x\)a"/E>qpWB=1 ¨"MP(\xp߫́A3+J] n[ʼnӼaTbZUWb={~2ooKױӰp(CS\S筐R*JغV&&"FA}J>G֐p1ٸbk7 ŘH$JoN <8s^yk_[;gy-;߉DV{c B yce% aJhDȶ 2IdйIB/^n0tNtџdcKj4϶v~- CBcgqx9= PJ) dMsjpYB] GD4RDWX +h{y`,3ꊕ$`zj*N^TP4L:Iz9~6s) Ga:?y*J~?OrMwP\](21sZUD ?ܟQ5Q%ggW6QdO+\@ ̪X'GxN @'4=ˋ+*VwN ne_|(/BDfj5(Dq<*tNt1х!MV.C0 32b#?n0pzj#!38}޴o1KovCJ`8ŗ_"]] rDUy޲@ Ȗ-;xџ'^Y`zEd?0„ DAL18IS]VGq\4o !swV7ˣι%4FѮ~}6)OgS[~Q vcYbL!wG3 7띸*E Pql8=jT\꘿I(z<[6OrR8ºC~ډ]=rNl[g|v TMTղb-o}OrP^Q]<98S¤!k)G(Vkwyqyr޽Nv`N/e p/~NAOk \I:G6]4+K;j$R:Mi #*[AȚT,ʰ,;N{HZTGMoּy) ]%dHء9Պ䠬|<45,\=[bƟ8QXeB3- &dҩ^{>/86bXmZ]]yޚN[(WAHL$YAgDKp=5GHjU&99v簪C0vygln*P)9^͞}lMuiH!̍#DoRBn9l@ xA/_v=ȺT{7Yt2N"4!YN`ae >Q<XMydEB`VU}u]嫇.%e^ánE87Mu\t`cP=AD/G)sI"@MP;)]%fH9'FNsj1pVhY&9=0pfuJ&gޤx+k:!r˭wkl03׼Ku C &ѓYt{.O.zҏ z}/tf_wEp2gvX)GN#I ݭ߽v/ .& и(ZF{e"=V!{zW`, ]+LGz"(UJp|j( #V4, 8B 0 9OkRrlɱl94)'VH9=9W|>PS['G(*I1==C<5"Pg+x'K5EMd؞Af8lG ?D FtoB[je?{k3zQ vZ;%Ɠ,]E>KZ+T/ EJxOZ1i #T<@ I}q9/t'zi(EMqw`mYkU6;[t4DPeckeM;H}_g pMww}k6#H㶏+b8雡Sxp)&C $@'b,fPߑt$RbJ'vznuS ~8='72_`{q纶|Q)Xk}cPz9p7O:'|G~8wx(a 0QCko|0ASD>Ip=4Q, d|F8RcU"/KM opKle M3#i0c%<7׿p&pZq[TR"BpqauIp$ 8~Ĩ!8Սx\ւdT>>Z40ks7 z2IQ}ItԀ<-%S⍤};zIb$I 5K}Q͙D8UguWE$Jh )cu4N tZl+[]M4k8֦Zeq֮M7uIqG 1==tLtR,ƜSrHYt&QP윯Lg' I,3@P'}'R˪e/%-Auv·ñ\> vDJzlӾNv5:|K/Jb6KI9)Zh*ZAi`?S {aiVDԲuy5W7pWeQJk֤#5&V<̺@/GH?^τZL|IJNvI:'P=Ϛt"¨=cud S Q.Ki0 !cJy;LJR;G{BJy޺[^8fK6)=yʊ+(k|&xQ2`L?Ȓ2@Mf 0C`6-%pKpm')c$׻K5[J*U[/#hH!6acB JA _|uMvDyk y)6OPYjœ50VT K}cǻP[ $:]4MEA.y)|B)cf-A?(e|lɉ#P9V)[9t.EiQPDѠ3ϴ;E:+Օ t ȥ~|_N2,ZJLt4! %ա]u {+=p.GhNcŞQI?Nd'yeh n7zi1DB)1S | S#ًZs2|Ɛy$F SxeX{7Vl.Src3E℃Q>b6G ўYCmtկ~=K0f(=LrAS GN'ɹ9<\!a`)֕y[uՍ[09` 9 +57ts6}b4{oqd+J5fa/,97J#6yν99mRWxJyѡyu_TJc`~W>l^q#Ts#2"nD1%fS)FU w{ܯ R{ ˎ󅃏џDsZSQS;LV;7 Od1&1n$ N /.q3~eNɪ]E#oM~}v֯FڦwyZ=<<>Xo稯lfMFV6p02|*=tV!c~]fa5Y^Q_WN|Vs 0ҘދU97OI'N2'8N֭fgg-}V%y]U4 峧p*91#9U kCac_AFңĪy뚇Y_AiuYyTTYЗ-(!JFLt›17uTozc. S;7A&&<ԋ5y;Ro+:' *eYJkWR[@F %SHWP 72k4 qLd'J "zB6{AC0ƁA6U.'F3:Ȅ(9ΜL;D]m8ڥ9}dU "v!;*13Rg^fJyShyy5auA?ɩGHRjo^]׽S)Fm\toy 4WQS@mE#%5ʈfFYDX ~D5Ϡ9tE9So_aU4?Ѽm%&c{n>.KW1Tlb}:j uGi(JgcYj0qn+>) %\!4{LaJso d||u//P_y7iRJ߬nHOy) l+@$($VFIQ9%EeKʈU. ia&FY̒mZ=)+qqoQn >L!qCiDB;Y<%} OgBxB!ØuG)WG9y(Ą{_yesuZmZZey'Wg#C~1Cev@0D $a@˲(.._GimA:uyw֬%;@!JkQVM_Ow:P.s\)ot- ˹"`B,e CRtaEUP<0'}r3[>?G8xU~Nqu;Wm8\RIkբ^5@k+5(By'L&'gBJ3ݶ!/㮻w҅ yqPWUg<e"Qy*167΃sJ\oz]T*UQ<\FԎ`HaNmڜ6DysCask8wP8y9``GJ9lF\G g's Nn͵MLN֪u$| /|7=]O)6s !ĴAKh]q_ap $HH'\1jB^s\|- W1:=6lJBqjY^LsPk""`]w)󭃈,(HC ?䔨Y$Sʣ{4Z+0NvQkhol6C.婧/u]FwiVjZka&%6\F*Ny#8O,22+|Db~d ~Çwc N:FuuCe&oZ(l;@ee-+Wn`44AMK➝2BRՈt7g*1gph9N) *"TF*R(#'88pm=}X]u[i7bEc|\~EMn}P瘊J)K.0i1M6=7'_\kaZ(Th{K*GJyytw"IO-PWJk)..axӝ47"89Cc7ĐBiZx 7m!fy|ϿF9CbȩV 9V-՛^pV̌ɄS#Bv4-@]Vxt-Z, &ֺ*diؠ2^VXbs֔Ìl.jQ]Y[47gj=幽ex)A0ip׳ W2[ᎇhuE^~q흙L} #-b۸oFJ_QP3r6jr+"nfzRJTUqoaۍ /$d8Mx'ݓ= OՃ| )$2mcM*cЙj}f };n YG w0Ia!1Q.oYfr]DyISaP}"dIӗթO67jqR ҊƐƈaɤGG|h;t]䗖oSv|iZqX)oalv;۩meEJ\!8=$4QU4Xo&VEĊ YS^E#d,yX_> ۘ-e\ "Wa6uLĜZi`aD9.% w~mB(02G[6y.773a7 /=o7D)$Z 66 $bY^\CuP. (x'"J60׿Y:Oi;F{w佩b+\Yi`TDWa~|VH)8q/=9!g߆2Y)?ND)%?Ǐ`k/sn:;O299yB=a[Ng 3˲N}vLNy;*?x?~L&=xyӴ~}q{qE*IQ^^ͧvü{Huu=R|>JyUlZV, B~/YF!Y\u_ݼF{_C)LD]m {H 0ihhadd nUkf3oٺCvE\)QJi+֥@tDJkB$1!Đr0XQ|q?d2) Ӣ_}qv-< FŊ߫%roppVBwü~JidY4:}L6M7f٬F "?71<2#?Jyy4뷢<_a7_=Q E=S1И/9{+93֮E{ǂw{))?maÆm(uLE#lïZ  ~d];+]h j?!|$F}*"4(v'8s<ŏUkm7^7no1w2ؗ}TrͿEk>p'8OB7d7R(A 9.*Mi^ͳ; eeUwS+C)uO@ =Sy]` }l8^ZzRXj[^iUɺ$tj))<sbDJfg=Pk_{xaKo1:-uyG0M ԃ\0Lvuy'ȱc2Ji AdyVgVh!{]/&}}ċJ#%d !+87<;qN޼Nفl|1N:8ya  8}k¾+-$4FiZYÔXk*I&'@iI99)HSh4+2G:tGhS^繿 Kتm0 вDk}֚+QT4;sC}rՅE,8CX-e~>G&'9xpW,%Fh,Ry56Y–hW-(v_,? ; qrBk4-V7HQ;ˇ^Gv1JVV%,ik;D_W!))+BoS4QsTM;gt+ndS-~:11Sgv!0qRVh!"Ȋ(̦Yl.]PQWgٳE'`%W1{ndΗBk|Ž7ʒR~,lnoa&:ü$ 3<a[CBݮwt"o\ePJ=Hz"_c^Z.#ˆ*x z̝grY]tdkP*:97YľXyBkD4N.C_[;F9`8& !AMO c `@BA& Ost\-\NX+Xp < !bj3C&QL+*&kAQ=04}cC!9~820G'PC9xa!w&bo_1 Sw"ܱ V )Yl3+ס2KoXOx]"`^WOy :3GO0g;%Yv㐫(R/r (s } u B &FeYZh0y> =2<Ϟc/ -u= c&׭,.0"g"7 6T!vl#sc>{u/Oh Bᾈ)۴74]x7 gMӒ"d]U)}" v4co[ ɡs 5Gg=XR14?5A}D "b{0$L .\4y{_fe:kVS\\O]c^W52LSBDM! C3Dhr̦RtArx4&agaN3Cf<Ԉp4~ B'"1@.b_/xQ} _߃҉/gٓ2Qkqp0շpZ2fԫYz< 4L.Cyυι1t@鎫Fe sYfsF}^ V}N<_`p)alٶ "(XEAVZ<)2},:Ir*#m_YӼ R%a||EƼIJ,,+f"96r/}0jE/)s)cjW#w'Sʯ5<66lj$a~3Kʛy 2:cZ:Yh))+a߭K::N,Q F'qB]={.]h85C9cr=}*rk?vwV렵ٸW Rs%}rNAkDv|uFLBkWY YkX מ|)1!$#3%y?pF<@<Rr0}: }\J [5FRxY<9"SQdE(Q*Qʻ)q1E0B_O24[U'],lOb ]~WjHޏTQ5Syu wq)xnw8~)c 쫬gٲߠ H% k5dƝk> kEj,0% b"vi2Wس_CuK)K{n|>t{P1򨾜j>'kEkƗBg*H%'_aY6Bn!TL&ɌOb{c`'d^{t\i^[uɐ[}q0lM˕G:‚4kb祔c^:?bpg… +37stH:0}en6x˟%/<]BL&* 5&fK9Mq)/iyqtA%kUe[ڛKN]Ě^,"`/ s[EQQm?|XJ߅92m]G.E΃ח U*Cn.j_)Tѧj̿30ڇ!A0=͜ar I3$C^-9#|pk!)?7.x9 @OO;WƝZBFU keZ75F6Tc6"ZȚs2y/1 ʵ:u4xa`C>6Rb/Yм)^=+~uRd`/|_8xbB0?Ft||Z\##|K 0>>zxv8۴吅q 8ĥ)"6>~\8:qM}#͚'ĉ#p\׶ l#bA?)|g g9|8jP(cr,BwV (WliVxxᡁ@0Okn;ɥh$_ckCgriv}>=wGzβ KkBɛ[˪ !J)h&k2%07δt}!d<9;I&0wV/ v 0<H}L&8ob%Hi|޶o&h1L|u֦y~󛱢8fٲUsւ)0oiFx2}X[zVYr_;N(w]_4B@OanC?gĦx>мgx>ΛToZoOMp>40>V Oy V9iq!4 LN,ˢu{jsz]|"R޻&'ƚ{53ўFu(<٪9:΋]B;)B>1::8;~)Yt|0(pw2N%&X,URBK)3\zz&}ax4;ǟ(tLNg{N|Ǽ\G#C9g$^\}p?556]/RP.90 k,U8/u776s ʪ_01چ|\N 0VV*3H鴃J7iI!wG_^ypl}r*jɤSR 5QN@ iZ#1ٰy;_\3\BQQ x:WJv츟ٯ$"@6 S#qe딇(/P( Dy~TOϻ<4:-+F`0||;Xl-"uw$Цi󼕝mKʩorz"mϺ$F:~E'ҐvD\y?Rr8_He@ e~O,T.(ފR*cY^m|cVR[8 JҡSm!ΆԨb)RHG{?MpqrmN>߶Y)\p,d#xۆWY*,l6]v0h15M˙MS8+EdI='LBJIH7_9{Caз*Lq,dt >+~ّeʏ?xԕ4bBAŚjﵫ!'\Ը$WNvKO}ӽmSşذqsOy?\[,d@'73'j%kOe`1.g2"e =YIzS2|zŐƄa\U,dP;jhhhaxǶ?КZ՚.q SE+XrbOu%\GتX(H,N^~]JyEZQKceTQ]VGYqnah;y$cQahT&QPZ*iZ8UQQM.qo/T\7X"u?Mttl2Xq(IoW{R^ ux*SYJ! 4S.Jy~ BROS[V|žKNɛP(L6V^|cR7i7nZW1Fd@ Ara{詑|(T*dN]Ko?s=@ |_EvF]׍kR)eBJc" MUUbY6`~V޴dJKß&~'d3i5h-3LL

HOME


5h-3LL 1.0
DIR: /srv/http/vyvoj.adent.cz/egroupware/pfi/sitemgr/doc
/srv/http/vyvoj.adent.cz/egroupware/pfi/sitemgr/doc/
Upload File:
Current File : /srv/http/vyvoj.adent.cz/egroupware/pfi/sitemgr/doc/sitemgr.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 1st April 2002), see www.w3.org">
<title>SiteMgr manual</title>
<meta name="GENERATOR" content=
"Modular DocBook HTML Stylesheet Version 1.7">
<meta http-equiv="Content-Type" content="text/html; charset=">
</head>
<body class="ARTICLE">
<div class="ARTICLE">
<div class="TITLEPAGE">
<h1 class="TITLE"><a name="AEN2">SiteMgr manual</a></h1>

<h3 class="AUTHOR"><a name="AEN5">Ralf Becker</a></h3>

<hr>
</div>

<div class="TOC">
<dl>
<dt><b>Table of Contents</b></dt>

<dt><a href="#AEN8">Introduction</a></dt>

<dt><a href="#AEN122">User manual</a></dt>

<dt><a href="#AEN274">Administrator manual</a><a name=
"ADMINISTRATOR-MANUAL"></a></dt>

<dt><a href="#AEN361">Template designer manual</a><a name=
"TEMPLATE-DESIGNER-MANUAL"></a></dt>

<dt><a href="#AEN378">Module developper manual</a><a name=
"MODULE-DEVELOPPER-MANUAL"></a></dt>
</dl>
</div>

<div class="SECT1">
<h2 class="SECT1"><a name="AEN8">Introduction</a></h2>

<p>This introductory section describes some concepts, you will need
to understand if you want to get the most out of sitemgr. If you
are just interested in a quick installation introduction go to
section <a href="#INSTALLATION">Installation</a></p>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN12">History</a></h3>

<ol type="1">
<li>
<p>The first version of SiteMgr was developed by a group of
students: Team 10 in the UC Irvine Systems Design Course, ICS
125.</p>
</li>

<li>
<p>Michael Totschnig (totschnig.michael@uqam.ca) wrote the
multilingual facets of SiteMgr and created the modularized
architecture.</p>
</li>

<li>
<p>Ralf Becker (RalfBecker@outdoor-training.de) extended the Edit
mode into the easy-to-use default user-interface of SiteMgr. He
also developed the compatibility with Mambo Open Source 4.5
templates and some of the new modules like the wiki, the new amazon
or the template selection.</p>
</li>
</ol>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN21">Templates</a></h3>

<p>SiteMgr builds web sites from templates. Those are stored in the
directory sitemgr/sitemg-site/templates. Each of them has a
sub-directory of its own. SiteMgr support two kind of
templates:</p>

<ol type="1">
<li>
<p>his own native format which is decript in the next
paragraph.</p>
</li>

<li>
<p>Mambo Open Source (<a href="http://www.mamboserver.com" target=
"_top">www.mamboserver.com</a>) MOS Ver. 4.5 templates. There are
hunderets of templates availible for download (<a href=
"http://www.mamboportal.com/index.php?option=com_remository&amp;Itemid=26&amp;func=selectfolder&amp;filecatid=9"
 target="_top">www.mamboportal.com</a>). To install, unpack the
downloaded zip-archive into the sitemgr-site/templates directory.
There's a series of articels from Arthur Konze about, how to
develope these templates: <a href=
"http://www.mamboportal.com/content/category/2/34/28/" target=
"_top">www.mamboportal.com</a>.</p>
</li>
</ol>

<div class="SECT3">
<hr>
<h4 class="SECT3"><a name="AEN32">SiteMgr's native template
format</a></h4>

<p>The file main.tpl defines the template of the whole site, there
can be other files that define code for separate areas of the page
or for specific modules. Templates contain four kinds of variables.
These are explained here since the types 2,3,4 and 5 can be used
both in the template as in the page content a module generates.</p>

<ol type="1">
<li>
<p><b>contentarea: areaname</b> These define where administrator
and contributor provided content go. The names and the number of
contentareas a template defines are almost arbitrary.</p>
</li>

<li>
<p><b>modulename(?arguments)</b>These let you hardcode a call to a
module into a template. Arguments are in the HTTP GET query string
syntax (?key1=value1&amp;key2=value2). At the moment, if you use
this type of variables, you have to urlencode the query string
yourself. Future versions of sitemgr might provide a simpler
notation. For example,<b>lang_block} creates the select box for
multilingual sites.</b></p>
</li>

<li>
<p><b>?(phpgw|sitemgr:)link</b> This lets you create links either
to other pages of your website, or to eGroupWare applications:</p>

<ol type="a">
<li>
<p>Links to sitemgr either start with '?sitemgr:' or only with '?'.
You can either link to a page with <b>?page_name=downloads} and
{?page_id=4</b>, to a category's index (?category_id=5), to the
site index (?index), to the site's table of contents (?toc). Just
{?} or <b>?sitemgr:</b> links to the administrator defined home
page.</p>
</li>

<li>
<p>Links to eGW start with '?phpgw:' . You have to name the
application followed by a comma, and optionnally arguments the
application can interpret. For example
<b>?phpgw:/addressbook,order=n_given&amp;sort=ASC</b>.</p>
</li>
</ol>
</li>

<li>
<p><b>variable</b> Finally there are some simple variables you can
use to retrieve metainformation about the page or about the user's
context:</p>

<ol type="a">
<li>
<p><b>title</b> the page title</p>
</li>

<li>
<p><b>subtitle</b> the page subtitle</p>
</li>

<li>
<p><b>sitename</b>the sitename the administrator has chosen for the
site</p>
</li>

<li>
<p><b>sitedescription</b> the sitedescription</p>
</li>

<li>
<p><b>user</b>the user's account name</p>
</li>
</ol>
</li>

<li>
<p><b>lang_translatable_string</b> This lets you make the template
internationalized. The translatable string is sent through
eGroupWare's lang function. Thus you can add it to the lang files
in the setup directory and install it through the setup
programm.</p>
</li>
</ol>
</div>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN62">Module</a></h3>

<p>The main function of a sitemgr module is to generate dynamic web
site content. To make the development of new modules, and the use
of modules easy and convenient, sitemgr defines an
&ldquo;abstract&rdquo; class module which each module should
extend. This parent of all modules, provides one essential service:
It hooks the module into the content managment interface and
permits the editing of the module's arguments that determine what
content will be generated. Thus in order to create a new module,
all you have to do, is to extend the abstract super module, define
the modules arguments, and write a get_content function that
returns the content that should be displayed on the website. More
on this in the chapter about<a href=
"#MODULE-DEVELOPPER-MANUAL">Module developpment</a>.</p>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN66">Argument/Content</a></h3>

<p>A module can be seen as a transformation of input arguments into
generated content. It is important to understand that the input
arguments can be of completely different kinds. On the one hand
there can be arguments that are as close as possible to the
generated content. For example the html module's only argument is
named &ldquo;htmlcontent&rdquo; and in normal circumstances it is
not transformed at all but handed over as is to the page generation
engine. On the other hand arguments can play any conceivable role
in the generation of content that is driven by data coming from
other eGroupWare applications. They can be used to select between
different categories of content, they can choose a certain format
of presentation, they can function as search terms, etc.</p>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN69">Properties</a></h3>

<p>A module can define properties. Properties are accessible to the
modules get_content function in the same way as arguments, but they
differ from them in two ways:</p>

<ul>
<li>
<p>Properties are edited by the site administrator. Their intended
role is to put certain constrains on the workings of the module, so
that a site administrator can enforce certain rules. For example
the standard html module defines a property called striphtml. If
this boolean property is set the module replaces all html in the
generated content with entities.</p>
</li>

<li>
<p>Properties are not defined with respect to a certain generated
content block, but are defined either on a site-wide level or on
the level of specific categories. Additionally you can
differenciate on each scope properties for each content area. When
a content block is generated, properties are searched for in a
cascading way, i.e. when the block is specific to a specific page
and contentarea and the module's properties are not defined for the
combination of the contentarea and the page's category, then
properties defined for higher scopes are looked for in a certain
order. More on this in the chapter about<a href=
"#ADMINISTRATOR-MANUAL">Administration</a>.</p>
</li>
</ul>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN78">Blocks, content areas and
scope</a></h3>

<p>There are three ways a module can generate content that will be
displayed on a web page:</p>

<ol type="1">
<li>
<p>A template can contain hardcoded calls to modules that will
generate content visible on each page. Thus you could put dynamic
content that is visible across the whole site on a place of its own
directly into the template. But beware that restrictions defined by
the administrator also apply to these hardcoded module calls.</p>
</li>

<li>
<p>A template defines several content areas. This is one important
differenced between the modularized sitemgr and previous versions
where there were was only one place where contributor edited
content went (page_content) and two places for administrator
configured blocks (right_blocks, left_blocks). Now templates can
define any practical number of content areas with arbitrary names.
And there is no more much difference between central and peripheric
areas. All can show administrator and contributor provided block
content.With one exeption: The name &ldquo;center&rdquo; is special
in that special pages that get generated by special URLs like
&ldquo;?toc&rdquo; and &ldquo;?index&rdquo; or
&ldquo;?category_id=number&rdquo; always put there page content
(which is internally generated by nothing else than a module) into
this content area. If your template does not have a content area
called &ldquo;center&rdquo; these special URLs won't work. Content
areas can display module output, as edited by the page's
contributors. We refer to each output of a module as a block. Here
is another important difference to how sitemgr used to work: Until
now there was a sharp distinction between page content which
replaces the template variable page_content, and side blocks which
got defined in a special file called blockconfig and replaced the
template varialbes right_blocks and left_blocks. Now from the
perspective of the page generation engine there is no more any
difference between content areas, all display blocks of content
generated by modules. The blocks one content area displays can be
defined on different levels of scope: There are site wide blocks
that are visible across the whole site, category wide blocks, that
are visible on pages that belong to the category or any of its
children, and finally are page blocks that define what
distinguishes the page from other pages, and normally will be that
what you'd call the page's main content.</p>
</li>

<li>
<p>The block content generated by a module can contain template
variables of the same type as those that can be hardcoded. This is
mostly useful for modules like the html module, where the
contributor specified argument is nearly identical to the generated
content. Thus a contributor can embed module calls inside the
content of a certain block. This is done only once without any
recursion, i.e. if a embedded module call returns itself a template
variable it is not parsed and processed again.</p>
</li>
</ol>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN88">Versioning</a></h3>

<p>SiteMgr handles block content in versions. This means that you
can have different versions of one block at the same time, but only
one of them is visible on the website. This allows for working on
several changes to the website and viewing them in a draft mode,
before commiting them all at once to the production site. SiteMgr
distinguishes five states for versions:</p>

<div class="VARIABLELIST">
<dl>
<dt>draft:</dt>

<dd>
<p>A draft version will not appear at the website at all. Draft
versions are here for content you are not yet sure about.</p>
</dd>

<dt>prepublished:</dt>

<dd>
<p>A prepublished version will appear on the website if you view it
in draft mode. A prepublished version is registered for
publication, and it will change to published state, once you commit
it.</p>
</dd>

<dt>published:</dt>

<dd>
<p>A published version is visible on your website both in
production mode and draft mode.</p>
</dd>

<dt>preunpublished:</dt>

<dd>
<p>You put a version into preunpublished mode, if you want to
remove it or replace it, but want to do this only by commiting
other changes in the same time.</p>
</dd>

<dt>archived:</dt>

<dd>
<p>Archived versions will no longer appear anywhere but a special
archive interface that allows you to reactivate archived
content.</p>
</dd>
</dl>
</div>

<p>There are no versions of categories or pages, but they do can be
in any of these five states. This means you can create a new
category or a new page, but it will not appear on the website until
you commit it.</p>

<p>Only one version of a content block can be in published,
prepublished or preunpublished state at a time. There is one
exeption: a prepublished and preunpublished version can exist
together. When you commit the change, the prepublished version will
become published and the preunpublished version will get
archived.</p>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN114">Transformer</a></h3>

<p>The architecture for sitemgr modules provides for the
distinction between some form of raw content a module produces and
the way it should get displayed on the web site, with the future
possibility to plug other display types into the same framework.
The idea is that the raw content of a module gets passed through
different transformers, possibly even several transformers in a
sequence at the time of content generation. Additionally this
provides for a use of modules outside of sitemgr, for example
remote retrieval of information with something like XML-RPC.</p>

<p>At the moment, a module does not need to use transformers on its
own, it can directly generate html content, but if it does, sitemgr
provides for an easy way to chain different transformers together.
Thus a module can be constructed in different layers of
functionality. For example a module's get_content function could
return data in XML, and it defines a XSLT transformation to
reorganize this data, and a second transformer for creating a user
interface for display.</p>

<p>Transformers are also used on the level of the site template,
insofar as each contentarea can have an associated transformer,
which wraps the different content blocks into a common display
format. This does the same thing as the file sideblock.tpl in
former versions of sitemgr.</p>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN119">Translations</a></h3>

<p>SiteMgr in its new modularized architecture continues to be
fully multilingual. It is very simple to have a new module use this
feature. All that is needed is to use a special flag in the
definition of the module's arguments. All arguments that have this
flag will be stored in a language specific database table, and can
be translated in the translation manager, very similar to the way
category and page definitions could already be translated to
several languages.</p>
</div>
</div>

<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="AEN122">User manual</a></h2>

<div class="SECT2">
<h3 class="SECT2"><a name="AEN124">Manage categories and
pages</a></h3>

<div class="SECT3">
<h4 class="SECT3"><a name="AEN126">Create a new category</a></h4>

<p>to be completed</p>
</div>

<div class="SECT3">
<hr>
<h4 class="SECT3"><a name="AEN129">Edit a category</a></h4>

<p>to be completed</p>
</div>

<div class="SECT3">
<hr>
<h4 class="SECT3"><a name="AEN132">Delete a category</a></h4>

<p>to be completed</p>
</div>

<div class="SECT3">
<hr>
<h4 class="SECT3"><a name="AEN135">Create a new page</a></h4>

<p>to be completed</p>
</div>

<div class="SECT3">
<hr>
<h4 class="SECT3"><a name="AEN138">Edit a page</a></h4>

<p>to be completed</p>
</div>

<div class="SECT3">
<hr>
<h4 class="SECT3"><a name="AEN141">Editing page content</a></h4>

<p>There are two interfaces for creating and editing content
blocks. The first one is called &ldquo;content manager&rdquo; and
works inside the eGW interface, the second works in interaction
with the generated web site and we call it &ldquo;editing
mode&rdquo;.</p>

<div class="SECT4">
<hr>
<h5 class="SECT4"><a name="AEN144">The content manager</a></h5>

<p>The interface for creating content blocks is the same on each
level of scope, besides that when editing blocks on a lower level
you can see all the blocks that have been defined on a higher
level, and will be displayed on the website together with the
blocks you are editing. I will refer to this interface as the
content manager.</p>

<p>In each content manager, there is a section for each content
area, where you can add blocks selected from a menu of all
available modules. Once you have added a new block, it appears
amidst all other blocks of the content area. Those defined on
higher level scopes are only displayed, those pertaining to the
scope (site-wide, category or page) you are managing are
editable.</p>
</div>

<div class="SECT4">
<hr>
<h5 class="SECT4"><a name="AEN148">Editing mode</a></h5>

<p>In order to use editing mode, you must add a site-wide
administration block to your website (viewable only by registered
users). This block has a dropdown menu where you can switch between
production mode (viewing the website in its public state), draft
mode (viewing the website in the prepublished state, i.e. how it
will look after you commit any pending changes) and edit mode. In
edit mode, you will see the same content as in draft mode, but in
front of each content block you will see a link &ldquo;Edit
block&rdquo;. Activating this link will pop up a new window for
editing it.</p>
</div>

<div class="SECT4">
<hr>
<h5 class="SECT4"><a name="AEN151">Editing a block</a></h5>

<p>In both the content manager and the editing window that opens in
editing mode, the interface for editing the block is the same.
There are three standard interface elements you can edit for each
block:</p>

<div class="VARIABLELIST">
<dl>
<dt>Title</dt>

<dd>
<p>Each module defines a default title for blocks it generates. The
block title is not necessarily displayed in each content area. It
depends on the block transformer defined for the content area by
the site template you use. Here you can override the default title
with a customized title that will only be used by the block you are
editing</p>
</dd>

<dt>Seenby</dt>

<dd>
<p>You can control the visibility of each block for the different
user roles defined by sitemgr: site administrators, eGroupWare
users (which include site administrators) and the anonymous user.
Evidently you can also make the block visible for everyone which is
the default.</p>
</dd>

<dt>Sortorder</dt>

<dd>
<p>Here you can change the order in which the blocks are displayed
by defining a different integer for each block.</p>
</dd>
</dl>
</div>

<p>When you first create a content block, sitemgr automatically
creates a version for it. For each version, you have to edit the
module specific arguments, each of which is preceded by an
explanatory label. The input elements for arguments can be of
different types: checkboxes, selectboxes, textareas, textfields. In
the case of text input, you can use the same template variables as
are used in the site template. But be aware that this only works if
the module puts the same variable into its output, which need not
necessarily be the case.</p>

<p>Even if not all blocks may make sense for each content area, the
content manager does not impose on itselft any constraints on which
modules you use for which area (Administrators can restrict the
available modules for categories and content areas). For example
you can use modules that are optimized for side block areas in the
central area and you could use a simple html content block on side
areas. The following modules are shiped with sitemgr:</p>

<div class="VARIABLELIST">
<dl>
<dt>administration</dt>

<dd>
<p>simply creates a link to sitemgr's administration interface.
Thus you probably would not want to make it visible for anonymous
user's but only for eGW users or adminstrators.</p>
</dd>

<dt>amazon</dt>

<dd>
<p>shows ads for books on the Amazon website. There is a comment in
the modules source file about how it works.</p>
</dd>

<dt>appdir</dt>

<dd>
<p>a demonstration of how sitemgr's architecture can be used to
realize a simple application for creating a directory of
information. It should be adaptable to other needs. At the moment,
you need PHP's XSLT extension to use this module.</p>
</dd>

<dt>bookmarks</dt>

<dd>
<p>lets you show content from eGW's bookmarks application</p>
</dd>

<dt>calendar</dt>

<dd>
<p>produces a calendar where each days links to eGroupWare's
calendar application</p>
</dd>

<dt>currentsection</dt>

<dd>
<p>produces an index of the pages in the current section.</p>
</dd>

<dt>download</dt>

<dd>
<p>you can use this module for creating links to files you store
with eGW's filemanager</p>
</dd>

<dt>filecontents</dt>

<dd>
<p>this module lets you include the content of a file on your
webserver into your website</p>
</dd>

<dt>forum</dt>

<dd>
<p>another demonstration of what sitemg's modules are intended for:
This module displays the discussions of eGroupWare's forum
application on the web site. It does not permit to post, since to
implement this, in my humble opinion, the forum application has to
be redesigned slightly.</p>
</dd>

<dt>galerie</dt>

<dd>
<p>creates a picture galery. You have to name both the filesytem
path and the URL to a directory, where images that have a common
filename, and are numbered beginning with one, are stored. Once the
directory has been found, you can edit a subtext for each
image.</p>
</dd>

<dt>google</dt>

<dd>
<p>displays a form for querying the google website.</p>
</dd>

<dt>hello</dt>

<dd>
<p>a simple &ldquo;Hello world&rdquo; module used below in this
manual.</p>
</dd>

<dt>html</dt>

<dd>
<p>probably the most important module, since it plays the role,
formerly the simple page content area had, ie. you add html content
to the page.</p>
</dd>

<dt>index_block</dt>

<dd>
<p>a index of the whole site, formatted for peripheric areas of
your web site.</p>
</dd>

<dt>index</dt>

<dd>
<p>is automatically used with the index GET parameter. You probably
would not have to use this block otherwise.</p>
</dd>

<dt>lang_block</dt>

<dd>
<p>displays a select box for changing the user's site language.</p>
</dd>

<dt>login</dt>

<dd>
<p>displays a login block</p>
</dd>

<dt>news</dt>

<dd>
<p>publishes news you edit with eGroupWare's news_admin
application. You can choose a category to display.</p>
</dd>

<dt>redirect</dt>

<dd>
<p>makes the page redirect to another URL. This is useful, if you
want an entry in your menus that links to a page outside your
sitemgr site. If you use this module you shouldn't put any other
blocks on the same page.</p>
</dd>

<dt>sitetree</dt>

<dd>
<p>displays a tree like menu to the website.</p>
</dd>

<dt>toc_block</dt>

<dd>
<p>the site's table of contents, formatted for peripheric areas of
your web site.</p>
</dd>

<dt>toc</dt>

<dd>
<p>is automatically used with the toc GET parameter. You probably
would not have to use this block otherwise.</p>
</dd>

<dt>xml</dt>

<dd>
<p>is only a demonstration of how a module could serve XML content
stored on your webserver. It does not do anything useful besides
creating a browser from one file to the other. Files have to be
named like images in the galerie module. You need PHP's xslt
extension to use this module.</p>
</dd>
</dl>
</div>
</div>

<div class="SECT4">
<hr>
<h5 class="SECT4"><a name="AEN262">Handling versions</a></h5>

<p>For each content block you can create a new version simply by
clicking on the &ldquo;Create new version link&rdquo;. Once you
have several versions of a block, you can change their status at
any time. If you want to immediately publish a block, you choose
&ldquo;published&rdquo;. If you want to register a version for
being published at the next commit, you choose
&ldquo;prepublished&rdquo;. A version that is
&ldquo;preunpublished&rdquo; is visible on the website, but will be
archived at the next commit. Thus if you want to replace some
content at the next commit, you have to put the published version
into &ldquo;preunpublished&rdquo; and create a new version that you
put into &ldquo;prepublished&rdquo; state. Archived versions will
be no longer visible in the content managment interface, but will
not be deleted from your database. They can be reactivated in the
&ldquo;Manage archived content&rdquo; interface.</p>
</div>
</div>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN265">Manage translations</a></h3>

<p>to be completed</p>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN268">Commit changes</a></h3>

<p>In this interface you see a list of all categories, pages and
blocks that are in prepublished or preunpublished state. You can
return to any of them for further editing or changing their status,
and you can choose between them for commiting. Prepublished content
will go public, preunpublished content will go to the archive.</p>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN271">Manage archived content</a></h3>

<p>to be completed</p>
</div>
</div>

<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="AEN274">Administrator manual</a><a name=
"ADMINISTRATOR-MANUAL"></a></h2>

<div class="SECT2">
<h3 class="SECT2"><a name="AEN277">Installation</a><a name=
"INSTALLATION"></a></h3>

<ol type="1">
<li>
<p>Once you have the sitemgr directory inside your eGroupWare
install you can setup it like any other eGroupWare application with
the setup program (http://yourmachine/eGW-path/setup/). You should
also install the sitemgr-link application, which is is inside
sitemgr and has to be moved up in the directory hierarchy.</p>

<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd sitemgr
mv sitemgr-link ..
   
</pre>
</td>
</tr>
</table>

<p>and then install sitemgr-link with setup</p>
</li>

<li>
<p>Log in to eGroupWare as an admin and create an anonymous eGW
user and assign it a password. The only app (I assume) that they
should have access to is sitemgr-link. sitemgr-link is a dummy
application that redirects eGW users to the generated site.</p>
</li>

<li>
<p>Users who you wish to see sitemgr (aka contributors) must be
given acces to sitemgr, users who you want to be able to link to
the sitemgr site from eGW must be given rights to sitemgr-link. The
easiest way to do this is to go to User groups and give groups
permissions to use the applications.</p>
</li>

<li>
<p>The sitemgr-site is the directory that serves the dynamic web
site. It is located inside sitemgr and works without moving it
somewhere else. But it can be located anywhere. For example, you
could put it in /var/www/html. You could make the root location of
your web server point to it, if you wish (ie, http://yourmachine/
refers to /var/www/html/sitemgr-site if you moved the directory, or
to /path/to/eGroupWare/sitemgr/sitemgr-site if you did not). Make a
mental note of the directory where you put it and the url that it
is accessed by.</p>
</li>

<li>
<p>In the sitemgr-site directory is a file called config.inc.php.
You only have to edit it if you moved the directory. Change the
value of the line</p>

<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
<pre class="PROGRAMLISTING">
'eGW_path'           =&gt; '../../',
   
</pre>
</td>
</tr>
</table>

<p>so that the value of $sitemgr_info{'eGW_path'} is
'/path/to/eGroupWare/'</p>
</li>

<li>
<p>You can handle different websites with sitemgr. The first thing
to do is to define your new website. SiteMgr defines a default
website upon installation, but you will probably have to redefine
it. Log in as a eGW administrator and go into eGroupWare's admin
application and choose &ldquo;Define websites&rdquo; in the sitemgr
section. You should see the default website listed, and can choose
to edit it. A website is defined by the following values:</p>

<div class="VARIABLELIST">
<dl>
<dt>Site_name</dt>

<dd>
<p>This is not used on the website, but only helps identify a
website inside the administration interface.</p>
</dd>

<dt>Filesystem_path_to_sitemgr-site_directory</dt>

<dd>
<p>If you did not move the sitemgr-site directory above you can
leave this unchanged.</p>
</dd>

<dt>URL_to_sitemgr-site</dt>

<dd>
<p>You can also leave this unchanged if you want to access your
public website with a url that looks like
http:/your.eGW.url/sitemgr/sitemgr-site. If you want a different
URL, you either have to move the sitemgr-site directory or to use
an alias or a virtual server in your webserver's configuration.</p>
</dd>

<dt>Anonymous_user's_username</dt>

<dd>
<p>the account name you created above.</p>
</dd>

<dt>Anonymous_user's_password</dt>

<dd>
<p>and the corresponding password</p>
</dd>

<dt>Site_administrators</dt>

<dd>
<p>Here you choose the users and/or groups that should have
administrator rights for the website. They do not have to be
adminstrators in eGW's sense.</p>
</dd>
</dl>
</div>
</li>

<li>
<p>You can know log in as on one of the user's you gave
administrator rights for the website.. Go to the sitemgr
application and select "Configure SiteMgr". Here you can set
different values that affect how your site will be presented.</p>

<div class="VARIABLELIST">
<dl>
<dt>Site_name</dt>

<dd>
<p>is used mainly for metadata</p>
</dd>

<dt>Site_description</dt>

<dd>
<p>is used mainly for metadata</p>
</dd>

<dt>Default_home_page</dt>

<dd>
<p>here you can select the page that will show up first one your
website. Evidently there won't be any choice until you create some
pages.</p>
</dd>

<dt>Template_select</dt>

<dd>
<p>lets you choose between the different site designs that come
with sitemgr or any you will create yourself.</p>
</dd>

<dt>Site_languages</dt>

<dd>
<p>If you want a multilingual site, you have to set them here. This
will let you use the translation interface for translating your
content and you can put a selectbox on your website where it's
visitors can choose between different languages.</p>
</dd>
</dl>
</div>
</li>

<li>
<p>After installation sitemgr does not immediately know about all
available modules. The setup routine only installs the modules
html,index and toc that every site will need. In order to register
all availabe modules select &ldquo;Manage site-wide module
properties&rdquo; from the administrative menu, and then follow the
&ldquo;Register new modules&rdquo; link.</p>
</li>

<li>
<p>That's it. Go to the Outline manager (&ldquo;Manage categories
and pages), add a category or three and check who can view and edit
them, then add a page or three to each category, create some
content for each page. You can also have content that is visible
everwhere on your website (&ldquo;Manage site-wide content&rdquo;)
or on all pages that belong to a category (&ldquo;Manage categories
and pages&rdquo; =&gt; &ldquo;Manage category wide content&rdquo;).
Take care to put all categories and pages and blocks you create
into published state, otherwise they will not be visible on the
website.</p>
</li>

<li>
<p>Go view your recently created site by clicking on the
sitemgr-link application. Voil&agrave;!</p>
</li>
</ol>
</div>

<div class="SECT2">
<hr>
<h3 class="SECT2"><a name="AEN351">Maintenance</a></h3>

<p>As a site administrator, you have three
privileges/responsibilies:</p>

<ol type="1">
<li>
<p>Define site wide content blocks. These are edited in the same
interface as category and page specific blocks.</p>
</li>

<li>
<p>Choose permitted modules: If you choose &ldquo;Manage site-wide
module properties&rdquo; from sitemgr's main menu, you will see
several rows which all contain four elements: a select box, a
button labelled &ldquo;Select allowed modules', another select box
and a button labelled &ldquo;Configure module properties&rdquo;.
The first select box and its adjacent button in each row permits to
choose lists of permitted modules. The first row defines a master
list for the whole site which is used when no more specific lists
are found for content areas or categories. The following rows each
pertain to the different content areas of your site template. Here
you can choose to allow some modules for one content areas, and
other modules for another one. In the category manager, there is a
button &ldquo;Manage Modules&rdquo; associated with each category.
There you can use the same interface to define lists specific to
one category (and all its subcategories, unless overriden). Again
you have the choice between one list that pertains to all content
areas, and specific lists for each category. When sitemgr has to
find a specific value of permitted lists in a given context (a
given contentarea in a given category) the following algorithm is
used: First it aks for a value defined for the pair
contentarea/category. If none is defined, it climbs up the category
hierarchy until the site wide value, each time looking for a value
defined for the pair contentarea/category. If none can be found, it
returns to the given category the search started from, and now asks
for values defined for the given category but independent from the
contentarea. If there is still none defined, it repeats the same
traversal up the category hierarchy. This means that by simply
defining one global master list of permitted modules, you can
configure the whole site, if you do not need more fine grained
control. The lists of permitted lists are never merged, if you
define one list for a given context, this list is used in this
context.</p>
</li>

<li>
<p>Define module properties: The lookup algorithm for module
properties is exactly the same as for the lists of permitted
modules. For each module you can set properties for the whole site,
for content areas, for categories, or for combinations of content
areas and categories. You access the property editor from the same
page where you choose the list of permitted modules. You just use
the second select box in each row. By selecting one module and
clicking the &ldquo;Configure module properties&rdquo; button, you
will open a interface for editing the module's properties which
ressembles the interface for editing module arguments in the
content manager. Be aware that only some modules define
properties.</p>
</li>
</ol>
</div>
</div>

<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="AEN361">Template designer manual</a><a
name="TEMPLATE-DESIGNER-MANUAL"></a></h2>

<p>One main idea behind sitemgr's modularized architecture is that
all dynamic content on the website is produced by a module. This
permits for a very structural way of defining functionality and for
an easy way of extending functionality. With respect to former
versions of sitemgr, this means that the templates have to be
slightly modified:</p>

<ul>
<li>
<p>The whole page template is now stored in a file main.tpl in the
template's directory.</p>
</li>

<li>
<p>The variables page_content, left_blocks,right_blocks have to be
replaced by content areas: <b>contentarea:center</b>,
<b>contentarea:left</b>, <b>contentarea:right</b>. Only the
contentarea center has a special semantics, since it is the
hardcoded value for the display of table of contents and side
index. All other contentareas can have arbitrary names, and you can
have any practical number of them.</p>
</li>

<li>
<p>A contentarea serves to display the content blocks, the site
administrator and contributors define. Each contentarea can have
its own way of wrapping html code around each content block. This
at the moment defined in a class that implements the transformer
interface, i.e. defines a function
apply_transform($title,$content).This class' name is areaname_bt
(for blocktransformer) and it is stored in file areaname_bt.inc.php
inside the template directory. The function apply_transform just
has to wrap the desired html around the content. It is free to
ignore the title, for example the block title does not necessarily
make sense in a page's central content area. A block transformer
could apply other transformations to the content, but this would
probably have counter-intuitive effects on your page's
contributors<a name="AEN372" href="#FTN.AEN372"><span class=
"footnote">[1]</span></a>.</p>
</li>

<li>
<p>Other than that a template directory can contain template files
that are specific to a certain module. For example the news module
uses a file newsblock.tpl which is a standard API template. It is
up to a module's developpers what kind of templates he wants to
use. We propose to use a namespace for these module specific
template files. For example a template used by module 'news' would
go into a subdirectory 'modules/news' in each template directory.
If the module does not find a template it needs in the site
template's directory, it should look for a default template file,
for example in &ldquo;default/modules/news'.</p>
</li>

<li>
<p>You can hardcode module calls into the template if your site
should have the same dynamic content on one specific place.</p>
</li>
</ul>
</div>

<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="AEN378">Module developper manual</a><a
name="MODULE-DEVELOPPER-MANUAL"></a></h2>

<p>SiteMgr's parent module class, defines all the important
functionality a module needs in its lifetime. Thus creating a new
module can be as easy as creating a class that extends the standard
module, defines the module's arguments if there are any, and has a
function get_content that produces the module's content. Let's
start with &ldquo;Hello World&rdquo;.</p>

<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
&lt;?php
class module_hello extends Module 
{      
    function module_hello()  
    {               
        $this-&gt;arguments = array(
            'name' =&gt; array(
                'type' =&gt; 'textfield', 
                'label' =&gt; 'The person to say hello to'
            )
        );
        $this-&gt;title = "Hello world";
        $this-&gt;description = "This is a simple sample module";   
    }
    function get_content($arguments,$properties)    
    {
        return lang('Hello') . ' ' . $arguments['name'];
    }
}
 
</pre>
</td>
</tr>
</table>

<p>Once your module is registered<a name="AEN384" href=
"#FTN.AEN384"><span class="footnote">[2]</span></a> and added to
the list of permitted modules for some context, users can create
blocks from this module: They will see in the content manager a
textfield where they edit the argument name, and once the block is
activated, it will generate the hello phrase on the website. Easy,
isn't it?</p>

<p>Now let's examine more in detail how the standard module is
constructed. This will help you understand in what way you can
extend it to create more powerful modules. It defines the following
functions:</p>

<div class="VARIABLELIST">
<dl>
<dt>add_transformer($transformer)</dt>

<dd>
<p>This function adds a transformer class to the module's
transformer chain, so that when a block is generated from this
module, its content will be passed through $transformer. This
function is automatically called for block transformers, but you
can use it on your own, if you want to separate in your module raw
content from different forms of output. There is only one function
a transformer class has to provide:</p>

<div class="VARIABLELIST">
<dl>
<dt>apply_transform($title,$content)</dt>

<dd>
<p>A transformer that is not a block transformer should normally
ignore the title argument, and construct its return value from the
content argument.</p>
</dd>
</dl>
</div>
</dd>

<dt>set_block(&amp;$block,$produce=False)</dt>

<dd>
<p>This function is called by the content manager (with
$produce=False) and by the page generation (with $produce=True) for
each content block, so that the module knows everything about the
block it has to edit or generate (above all its context and its
arguments). If your module overrides this function, it should
always call the parent class' set_block function first with
parent::set_block($block,$produce). If you want to configure your
module with respect to the block, you can do this here. This is
also the place where your module should add the transformers it
needs for generating output. For example:</p>
</dd>
</dl>
</div>

<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
function set_block(&amp;$block,$produce=False)
{ 
    parent::set_block($block,$produce)
    if ($produce)
    {
        $this-&gt;add_transformer(new my_transform());
    }
}
 
</pre>
</td>
</tr>
</table>

<div class="VARIABLELIST">
<dl>
<dt>get_properties()</dt>

<dd>
<p>This function looks up the value of the module's properties for
the context of a block. There should not be much reason to override
this function.</p>
</dd>

<dt>get_user_interface()</dt>

<dd>
<p>This function is responsible for creating the interface you use
in the content manager when you edit a module's arguments. If you
want this interface to show more than your module's arguments,
youcan override this function. It must return an array of interface
elements where each element is an array with two values associated
to the keys label and form. You can even dynamically construct
arguments, sitemgr's sample gallery module shows how to do
this.</p>
</dd>

<dt>get_admin_interface($defaults)</dt>

<dd>
<p>This function creates the interface for editing module
properties, it works in a similar way to get_user_interface.</p>
</dd>

<dt>get_translation_interface($fromblock,$toblock)</dt>

<dd>
<p>This function creates the interface for the translation manager.
If your module makes use of sitemgr multilingual feature, and you
have overriden get_user_interface, you'll probably have to override
this function too.</p>
</dd>

<dt>build_input_element(($input,$default,$elementname)</dt>

<dd>
<p>This is a helper function for above functions. If you override
one of above functions you can use build_input_element in the same
way as the parent module does.</p>
</dd>

<dt>validate(&amp;$data)</dt>

<dd>
<p>This function is called when a module's arguments are edited.
The parent class simply returns true. When you override this
function, you can alter the arguments, a reference to which is
passed to the function, but you can also return false, and set the
module's validation_error variable. In this case, the arguments
will not be saved and the validation error is displayed to the
user. For example we could add the following lines to our hello
module:</p>

<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
<pre class="PROGRAMLISTING">
function validate(&amp;$data) 
{ 
    if (preg_match("/[[:upper:]]/",$data['name']))
    {
        $data['name'] = strtolower($data['name']);
        $this-&gt;validation_error = "Name has been translated to lower case";
    }
    return true;
}
  
</pre>
</td>
</tr>
</table>

<p>This would make sure that the module argument name would always
be lowercase.</p>
</dd>

<dt>get_content(&amp;$arguments,$properties)</dt>

<dd>
<p>This is the function every module needs. It produces the
module's content. It is passed two arrays, one with the arguments
for the block the module is generating, and the other with the
properties that apply for the block's context. At the moment there
is no constraint on what type of date the get_content function
returns. It can be html, xml, an array, etc. But if it does not
return html, you have to provide a transformer capable to produce
html from the data get_content produces. The arguments are passed
as a reference, because the get_content function can change them,
and they can get stored automatically as session variable. This is
because the parent module provides one other service: Your module
can rely on an automatic handling of HTTP GET, POST and COOKIE
variables, and of session variables. All you'd have to do is to
define the arrays $this-&gt;get, $this-&gt;post, $this-&gt;cookie
and $this-&gt;session. All members of these variables will be
fetched from the GET, POST or COOKIE parameters, or from session
variables and stored for you in the $arguments array. The entries
of $this-&gt;session additionnaly will be stored after get_content
returns to get_output. This can be very useful if you want your
module to remain in a stable state while the user interacts with
other modules on the same page.</p>

<p>The variables you define in these arrays can be identical to
those in $this-&gt;arguments. In this case, if they are defined in
the HTTP session context, they will override the values the page
contributor has defined for the page. But they can be different
variables that do not need an initial value provided by the page
contributor. Whereas $this-&gt;get,$this-&gt;cookie and
$this-&gt;session are simple arrays enumerating the variable names,
$this-&gt;post is special because it can contain the element
definition in the same way as $this-&gt;arguments, which can be
used to programatically construct the form elements.</p>

<p>Your module does not need to use this service, it could directly
read HTTP variables. The advantage of using it is that it provides
a namespace for each module, so that if different modules that use
the same variable names are used on the same page, no problems
occur. If you use this service you can construct URLS automatically
with the modules link function (see below), and if you construct
the user interface, you have to provide the correct form element
names for this service to work. The build_post_element function can
help you do this. For example lets extend our hello module, so that
the site user can choose his own name. Since we can no longer rely
on the validation that is automatically done on contributor
provided input. we call validate from the get_content function.</p>

<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
<pre class="PROGRAMLISTING">
&lt;?php
class module_hello extends Module  {
    function module_hello()
    {
        $this-&gt;arguments = array(
            'name' =&gt; array(
                'type' =&gt; 'textfield',
                 'label' =&gt; 'The person to say hello to'
            )
        );
       $this-&gt;post = array('name' =&gt; array('type' =&gt; 'textfield'));
       $this-&gt;session = array('name');
       $this-&gt;title = "Hello world";
       $this-&gt;description = "This is a simple sample module";
    }
    function get_content(&amp;$arguments,$properties)
    {
       $this-&gt;validate($arguments);
       return lang('Hello') . ' ' . $arguments['name'] . '&lt;br&gt;&lt;form action="' .
           $_SERVER['REQUEST_URI'] . '" method="post"&gt;' .
               $this-&gt;build_post_element('name',lang('Enter a name') .
           '&lt;/form&gt;';
    }
    function validate(&amp;$data)
    {
       if (preg_match("/[[:upper:]]/",$data['name']))
       {
           $data['name'] = strtolower($data['name']);
           $this-&gt;validation_error = "Name has been translated to lower case";                }
       return true;
   }
}
  
</pre>
</td>
</tr>
</table>
</dd>

<dt>build_post_element($key,$default=False)</dt>

<dd>
<p>You can use this function from your module's get_content
function to construct form elements. This works with the argument
definition you put into $this-&gt;post. If you do not provide a
default the current blocks value for the argument will be filled
in.</p>
</dd>

<dt>link($modulevars)</dt>

<dd>
<p>helps you construct URLS with GET parameters that use the
service described above. modulevars is an array of variable values
keyed on variable names.</p>
</dd>

<dt>find_template_dir()</dt>

<dd>
<p>if a module uses a different template (of whatever kind) for
different site themes, this function can help finding the template
directory inside the theme's directory, if it follows the namespace
described above, or if it cannot be found name the default
directory.</p>
</dd>

<dt>get_output($type='html')</dt>

<dd>
<p>This is the function that is actually called by the page
generation engine, since it not only calls the module's get_content
function, but makes sure that all transformers that have been added
to the modules transformer_chain get called. For type argument is
not really used at the moment, but future versions of sitemgr could
be extended so that modules could produce output in different
formats by specifying different transformers for each output type.
Your module should not need to override get_output.</p>
</dd>
</dl>
</div>

<p>To summarize, there are the following requirements for a sitemgr
module:</p>

<ol type="1">
<li>
<p>It is written as a class called module_name and extends the
class Module. It must be put into a file called
class.module_name.inc.php and put into the inc directory of any
eGroupWare application.</p>
</li>

<li>
<p>Its constructor should define the following member
variables:</p>

<ol type="a">
<li>
<p>arguments: the module's arguments a contributor can edit in
order to create content blocks from the module. Each argument needs
to define a label and the type of input element used to edit it in
the content manager. Parameters for these input elements (like size
for textfields, cols and rows for textareas can be defined).
Translatable arguments can be specially flagged with a i18n entry
in the arguments definition array<a name="AEN461" href=
"#FTN.AEN461"><span class="footnote">[3]</span></a></p>
</li>

<li>
<p>properties: the module's properties the site administrator can
edit in order to constrain or configure the functionnality of the
module</p>
</li>

<li>
<p>title: The module's default title that can be overriden for each
content block.</p>
</li>

<li>
<p>description: A short descriptive text, that is displayed in the
content manager and module manager (for example when you put the
mouse over an entry in the module select lists).</p>
</li>
</ol>
</li>

<li>
<p>It needs a get_content function that has access to arguments and
properties and produces the block content.</p>
</li>

<li>
<p>If the content returned by get_content is something different
from HTML, the module has to define transformer classes, and should
add them to the module's transformer chain. This can be done in the
constructor, but the best place for it is the set_block
function</p>
</li>

<li>
<p>The parent module class provides a user interface for editing
module arguments. If a module needs a customized interface or wants
to construct arguments dynamically, it can override the
get_user_interface function.</p>
</li>
</ol>

<p>These are the building blocks which should allow for some
flexibility in constructing modules that make eGroupWare managed
data visible on a sitemgr web site.</p>
</div>
</div>

<h3 class="FOOTNOTES">Notes</h3>

<table border="0" class="FOOTNOTES" width="100%">
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN372" href=
"#AEN372"><span class="footnote">[1]</span></a></td>
<td align="left" valign="top" width="95%">
<p>For compatibility with how sitemgr used to work, the file
sideblock.tpl which uses the two variables block_title and
block_content is still recognized as a template for a
transformation of the two contentareas left and right. The
transformer is automatically created by the template class. Thus
you could use one file sideblock.tpl instead of the two files
right_bt.inc.php and left_bt.inc.php.</p>
</td>
</tr>

<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN384" href=
"#AEN384"><span class="footnote">[2]</span></a></td>
<td align="left" valign="top" width="95%">
<p>Modules must be stored in the directory
/path/to/eGroupWare/sitemgr/modules and be named
class.module_modulename.inc.php in order that sitemgr can find
them.</p>
</td>
</tr>

<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN461" href=
"#AEN461"><span class="footnote">[3]</span></a></td>
<td align="left" valign="top" width="95%">
<p>If a module wants to make use of sitemgr's translation feature,
it must additionally set the module member variable i18n to
true.</p>
</td>
</tr>
</table>
</body>
</html>