wwedit-development Mailing List for ww.edit
Status: Beta
Brought to you by:
wegewerk
Menu
▾
▴
wwedit-development — discussion about development of wwedit
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(2) |
Nov
(12) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-25 07:45:51
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Thomas R. <th...@by...> - 2003-12-05 21:17:06
|
hallo, ich moechte an dieser stelle nur von einem neuen bug berichten. dieser bug ist noch nicht behoben, moechte aber darauf hinweisen, was man momentan nicht machen sollte, um diesen bug zu provozieren. einleitung ========== die website wird in einer baumstruktur von seiten aufgebaut. dementsprechend kann man eine seite von einem ort zu einem anderen kopieren/ verschieben. frage ist, was passiert, wenn man eine seite unter sich selbst (oder unter eine seite unterhalb sich selbst) kopiert? in allen aelteren versionen des benutzten Systems (DB_NestedSet) wurde diese Situation mit einer Fehlermeldung 'this would lead in a recursion' abgebrochen. Beschreibung ============ in der aktuellen version von db_nestedset (1.3.1) ist diese meldung nicht mehr enthalten, und die klasse kopiert ohne ein mucken die selektierte seite. dies endet in einem endlosen kopieren von seiten unter die betroffene seite. aufgehalten werden kann dies nur durch einen abbruch des benuzters oder durch das setzen der maximum execution time. im schlimmsten fall (wie eben erlebt nach maximum execution time von 30 sek. hatte ich eine seitenstruktur von einer tiefe von 742 ebenen) ist dann zwar die website noch in takt, nur das cms macht schlapp beim kompletten auslesen dieser struktur... Vorbeugung ========== keine seite kopieren und unterhalb sich selbst oder einer unterseite unter sich selbst kopieren!!!! zukunft ======= ich werde den author von db_nestedset darauf hinweisen und im cms selbst einen entsprechenden schutz einbauen. dies wird aber vorraussichtlich erst innerhalb der naechsten 2 wochen passieren... gruss thomas |
|
From: Thomas R. <th...@by...> - 2003-11-27 10:51:00
|
Hallo Juri und alle anderen 'nur-mit-leser', > Ist das wirklich ein Problem? Ich habe das Gefühl, dass gerade die > Notwendigkeit des zweimaligen Speicherns für den User eine > Fehlerquelle ist. ist nur die frage, wie oft diesen zweimalige speichern auftritt... zumal es ja auch bei einen popup nicht in der gleichen seite ist... selbst mit dem layer sind wir in der gleichen seite... aber wieviele user sind gewoehnt, in der gleichen seite das formular nicht abzuschicken...? zumal, wenn die einstellung im layer getroffen wurde, muss das layer ja geschlossen werden... und der submit button in der normalen seite sein. wenn nun aber ein user es sich anders ueberlegt... (weil der nur diese einstellungen im layer geaendert hat) und dann nicht auf submit klickt, weil das formular im layer ja schon weg ist? > Die Seite, die dahinter angezegt wird, sollte nach Abschluss > der im Layer > abgeschlossenen Aktion neu geladen werden. Dafür it das Speichern > /Abschicken m.E. doch gerade sinnvoll.. toll... dann ist das mit dem layer doch auch schon wieder unsinnig... und nur eine spielerei die chique aussehen soll... ich denke gerade, weil dies eine entwicklung von mir ist, die nicht bezahlt wird, sollten wir die 'nicht-layer' variante anstregen (weil das mit dem layer dauert sicher schon so seine 2 arbeitstage... und so ein kleines popup oder ein neuer reiter fast gar nix... :) ) und nur mal so nebenbei: http://www.learn.to/quote bezieht sich zwar auf usenet, sollte fuer emails aber genauso gelten... und macht das leben auch auf einer mailingliste fuer alle beteiligte besser... in outlook: extras/optionen/einstellungen/e-mail optionen... da kann man das einstellen... ;-) thomas |
|
From: juri m. >> w. <jur...@we...> - 2003-11-27 10:34:22
|
Ist das wirklich ein Problem? Ich habe das Gef=FChl, dass gerade die Notwendigkeit des zweimaligen Speicherns f=FCr den User eine Fehlerquelle= ist. Die Seite, die dahinter angezegt wird, sollte nach Abschluss der im Layer abgeschlossenen Aktion neu geladen werden. Daf=FCr it das Speichern /Abschicken m.E. doch gerade sinnvoll.. -----Urspr=FCngliche Nachricht----- Von: wwe...@li... [mailto:wwe...@li...]Im Auftrag von Thomas Richter Gesendet: Mittwoch, 26. November 2003 10:37 An: wwe...@li... Betreff: AW: [Wwedit-development] cvs update & ein neues feature & euer feedback... > Mir schwebt ein platzhalter vor, der ein Layer startet, =FCber das die > Erbelemente bearbeitet werden k=F6nnen. Dann ist die Seite nicht so > un=FCbersichtlich wie jetzt bef=FCrchtet. was mir da grad noch einfaellt... im layer waere ja ein formular... das muss auch abgeschickt werden... und wenn man ein formular abschickt, wird die seite abgeschickt... und eigentlich sollte das ja nicht unbedingt passieren... was wieder fuer einen eigenen reiter oder worauf ich mich auch einlassen koennte, wenigstens fuer ein popup spricht... ich denk drueber nach... *gruebel* thomas ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ wwedit-development mailing list wwe...@li... https://lists.sourceforge.net/lists/listinfo/wwedit-development |
|
From: juri m. >> w. <jur...@we...> - 2003-11-26 10:58:17
|
habe nochmals intensivgegr=FCbelt. Mit dem Ererben ist wohl doch ein problematisch, denn so summert ich das auf den unterseiten, es kommen permamnet banner der zentralen ebene dazu und man kann keienm Bereichsredakteur zumuten, die immer wieder wegzuklicken. Die verebung =FCber x definierte Ebenen w=E4re ein Ansatz f=FCr dieses Pr= oblem, beraubt aber im Prinzip ebenfalls die Unteren Ebenen der kontrolle und ausserdem ist es recht pauschal und unflexibel gel=F6st. Vielleicht ein Pool die L=F6sung, bei dem wie Bilder in Templates mit ein= em Servcie-Contaner f=FCr Banner bestimmte "Abos" ausgew=E4hlt werden. Z.B. "zentrale Kampagnen"(1-3 Banner) "Aktionen Vetreibsabteilung"(1-3 Banner) "Werbebanner" (1 Banner) oder "zentraler Presseticker" (als Service) "Presseticker Vertreib" (als Service) oder "=C4nhliche Dokumente" (als Service) etc. Das klicke ich mir dann f=FCr die Seite an und wenn ich ein= e Unterseite anlege ist es erstmal auch ausgew=E4hlt (sofern dort ein Conta= iner daf=FCr vorgesehen ist), kann aber auh weggeklickt werden. Dor k=F6nnen auch eigene Abos oder Banner angelegt werden, die dann nach = dem gelichen Prinzip auf den Untersieten zur verf=FCgung stehen, es sei denn = man schickt den Banner der zentralen Ebene, die den Banner einem neuen Abo (d= ann muss es sich jeder Bereichsredakteur holen) oder einem Bestehenden Abo (d= ann bekommen die es automatisch auf dei Seite) hinzuf=FCgt. Bei Erstellung Ab= os werden Mengen festgelegt, damit dei Seite nicht l=E4nger wird als geplant= . ist bspw. 1-3 festgelegt, kann das erste Banner nur ersetzt aber nicht gel=F6= scht werden, sind mehr als drei Banner drin, rotieren diese per Zufall. Das w=E4re aus redaktioneller Sicht m.E. die sinnvollste L=F6sung. Was da= s Verscheiben vomn Seiten betrifft, w=FCrde wohl wieder die Vererbung gelte= n: Ist ein extra-elemant f=FCr diese Seite festgelgt, kommt das Element mit. wurde es von einer dar=FCberliegnden Seite geerbt, die danac nicht mehr dar=FCberliegt, f=E4llt das Element weg. Das w=E4re m.E. transparenter al= s es mitzunehmen und damit Unklarheiten zu schaffen, welche Elemante wo auftauchen. >wenn js ausgeschaltet, sollte wenigstens >etwas aufgehen... und dass nicht in einem neuen fenster... d.h. fuer >diesen fall brauch man eine loesung mit reiter, damit es ins >navigationskonzept passt.. zumal man den reiter ja nur anzeigen muss, >wenn wirklich eine seite betroffen ist... genau. So w=FCrde ich es generell l=F6sen. Kann man das nicht in die PEAR= -Klasse f=FCr die Reitersteuerung integrieren dass man quasi der Funktion sagt: "= wenn js da, dann als Fensterchen, wie =FCblich oben links an der Stelle xy ausgerichtet und in diesem Fall xy gross, falls js weg, dann in gottsname= n als weiterer Reiter, der gelich aufgrufen wird und nach dem Speichern bit= te auch gleich wieder verschwindet!" Dann w=E4re die Angelegenheit auch glei= ch f=FCr Epoz und Bilddatenbank vom Tisch. Langfristig k=F6nnte das eher wen= iger als mehr Aufwand bedeuten. Vielleicht kann man das erstmal vorsehen (position und gr=F6=DFenangabe f=FCr den Layer) aber nur die Anzeige f=FC= r non-js realisiern, wenn es zuviel Arbeit ist. Einen Sponsor f=FCr die Umsetzung = des Layeraufrufes und der js-Pr=FCfung finden wir dann schon noch, es w=E4re = aber sch=F6n, wenn die L=F6sung gelich da ist. Auszukniffeln w=E4re dabei im =FC= brigen auch, was genau passietr, wenn z.B. der Bild-DB Aufruf =FCber EPoz erfolg= t, dass heisst, das ein Layer ein anderes aufruft. Da hatte ich mir f=FCr da= s IF ja gedacht, dass die Layer immer an einer Stelle stehen, so dass auch hie= r eine Reiternavigation m=F6glich ist, damit ich sehe, dass dahinter noch e= in anderes Layer liegt, wobei ich sinnvollerweise nichts anklicken kann, bev= or ich nicht mit der obersten Aktion fertig bin. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ wwedit-development mailing list wwe...@li... https://lists.sourceforge.net/lists/listinfo/wwedit-development |
|
From: Thomas R. <th...@by...> - 2003-11-26 09:36:12
|
> Mir schwebt ein platzhalter vor, der ein Layer startet, über das die > Erbelemente bearbeitet werden können. Dann ist die Seite nicht so > unübersichtlich wie jetzt befürchtet. was mir da grad noch einfaellt... im layer waere ja ein formular... das muss auch abgeschickt werden... und wenn man ein formular abschickt, wird die seite abgeschickt... und eigentlich sollte das ja nicht unbedingt passieren... was wieder fuer einen eigenen reiter oder worauf ich mich auch einlassen koennte, wenigstens fuer ein popup spricht... ich denk drueber nach... *gruebel* thomas |
|
From: Thomas R. <th...@by...> - 2003-11-26 09:27:50
|
> Daneben gibt es Templates, die einen Bereich vorsehen, in dem
> Seitenübergreifende Banner Services o.ä. angeboten werden. In
> denen ist beim
> Neuanlegen alles vorhanden, was in der darüberliegenden Seite ist.
> Ich kann dort Setenweise verebte Elemente deaktivieren oder
> aus einem Pool
> weitere hinzufügen und neue in den Pool einfügen.
halt! da sprichst du schon uber was, was ueberhaupt nicht mehr in das
angefangene konzept passt... ich halte mir momentan diesen pool an
elementen, der auf jeder seite eingebunden werden kann noch vor... aber
kurzfristig ist da nichts geplant...
es geht nur darum, dass man ganz normal auf einer seite ein
contentobjekt anlegt (ganz so wie man text mit bild & link anlegt). nur
dieses besitzt intern als inherit flag, was automatisch dafuer sorgt,
dass es den unterseiten bei der generierung des html code aus den
templates zur verfuegung steht. - der programmierer der templates fuer
das frontend kann entscheiden, ob er es dann ausgibt.
im bearbeiten screen weisst somit nichts darauf hin, dass es ein
vererbbares objekt ist. (ausser, wenn der templateprogrammierer einen
namen wie 'Website Banner' oder 'vererbbarer banner')
> Wird eine Seite verschoben, erbt sie dei Elemnte der
> darüberliegenden Seite,
> mis ausnahme der bereits deaktivierten Elemente, werden diese
> nicht vererbt,
> bleiben Deaktivierungen und und hinzugefügte Elemente
> erhalten, können aber
> aktiv gelöscht werden.
das hat dann aber nichts mehr mit vererbung zu tun. beispiel:
home
|
+ service
|
+ suche
in dieser site wurde ein banner auf der service seite mit einer werbung
fuer amazon eingestellt. das tempalte der sucheseite ist so
programmiert, dass es diesen werbebanner anzeigt. auf der home seite ist
kein banner eingegeben. nun verschiebt redakteur X die seite suche
direkt unter home. somit verschwindet ja der amazon banner aus der
suchen seite, ohne dass das eventl. gewollt ist... das ist das
problem... mit einen pool von banner waer es kein problem. dann wuerde
man aber nicht von vererbung sprechen, sondern von eingabe von banner
auf mehreren seiten gleichzeitig.
> Ich würde es nicht in einem Reiter unterbringen:
> 1.) Kommen bestimmt noch Reiter dazu
> 2.) Gehört das ja irgendwie zum bearbeitbaren Inhalt, und der
> Sollte über
> die bearbeiten Siete bearbeitet werden.
>
> Mir schwebt ein platzhalter vor, der ein Layer startet, über das die
> Erbelemente bearbeitet werden können. Dann ist die Seite nicht so
> unübersichtlich wie jetzt befürchtet.
implementierungs aufwand wahrscheinlich zu hoch. zumal es ja auch ohne
javascript funktionieren muss...(was mich daran erinnert, dass ich noch
was bei der bildverwaltung machen muss ;) ) also eine alternative mit
popup auch nicht moeglich... wenn js ausgeschaltet, sollte wenigstens
etwas aufgehen... und dass nicht in einem neuen fenster... d.h. fuer
diesen fall brauch man eine loesung mit reiter, damit es ins
navigationskonzept passt.. zumal man den reiter ja nur anzeigen muss,
wenn wirklich eine seite betroffen ist...
und zusaetzlich die loesung mit dem layer ist mir einfach zu
aufwendig.... ausser irgendjemand stellt sich als investor zur
verfuegung... (achso... dann sollte man auch gleich die
datei/bildverwaltung mit als layer bauen, da sonst ja nicht
einheitlich...) ;-)
ich denke ich werde mir in den naechsten tagen mal ein paar notizen aus
den vorschlaegen hier machen und diese nochmal posten... eventl. faellt
dann dem einen oder anderen noch was ein...
liebe gruesse
thomas
--
I propose that the following character sequence for joke markers:
:-)
19-Sep-82 11:44 Scott E Fahlman
|
|
From: Juri M. >> w. <jur...@we...> - 2003-11-25 11:08:05
|
Es gibt elemente die m=FCssen auf allen Seiten erscheinen. Die geh=F6ren = ins Master-Template Daneben gibt es Templates, die einen Bereich vorsehen, in dem Seiten=FCbergreifende Banner Services o.=E4. angeboten werden. In denen i= st beim Neuanlegen alles vorhanden, was in der dar=FCberliegenden Seite ist. Ich kann dort Setenweise verebte Elemente deaktivieren oder aus einem Poo= l weitere hinzuf=FCgen und neue in den Pool einf=FCgen. Dann sollte es auch Templates geben, in denen nichts davon vorhanden ist, und nicht automatisch =FCbernommen werden kann. Wird eine Seite verschoben, erbt sie dei Elemnte der dar=FCberliegenden S= eite, mis ausnahme der bereits deaktivierten Elemente, werden diese nicht verer= bt, bleiben Deaktivierungen und und hinzugef=FCgte Elemente erhalten, k=F6nne= n aber aktiv gel=F6scht werden. Ich w=FCrde es nicht in einem Reiter unterbringen: 1.) Kommen bestimmt noch Reiter dazu 2.) Geh=F6rt das ja irgendwie zum bearbeitbaren Inhalt, und der Sollte =FC= ber die bearbeiten Siete bearbeitet werden. Mir schwebt ein platzhalter vor, der ein Layer startet, =FCber das die Erbelemente bearbeitet werden k=F6nnen. Dann ist die Seite nicht so un=FCbersichtlich wie jetzt bef=FCrchtet. was denkt ihr? j > -----Urspr=FCngliche Nachricht----- > Von: wwe...@li... > [mailto:wwe...@li...]Im Auftrag von > Thomas Richter > Gesendet: Dienstag, 25. November 2003 11:13 > An: wwe...@li... > Betreff: AW: [Wwedit-development] cvs update & ein neues feature & euer > feedback... > > > > Ich w=FCrde die klassiche "Vererbungslehre" anwenden. Auf der > > Bearbeitungs-Seite, auf der die Inhalte eingegeben werden, k=F6nnte e= in > > kleines Interface erscheinen, dass alle inherited Elements auflistet, > > vielleicht mit einer aktiven Checkbox, so dass der User > > einzelne Elemente > > deaktivieren kann. > > sozusagen als neuer reiter? ich kann mir vorstellen, wenn die > bearbeitungsseite viele daten enthaelt, dann wird es unuebersichtlich... > und man arbeitet ja primaer mit dieser seite. folglich wird ich es > einfach erreichbar vielleicht einfach als reiter einblenden... > > trotzdem finde ich es wichtig, dass man schon waehrend der eingabe > solcher vererbbaren objekte schon definieren kann, wie viele ebenen tie= f > diese banner angezeigt werden... schliesslich waere damit wohl schon de= r > "regel-sonderfall" mit ein klick abgedeckt... und fuer den > "sonder-sonderfall" gibts dann den neuen screen... > > > Die ander Frage w=E4re, ob bei der Deaktivierung eines > > Elementes die Elemente > > auch auf untergeordneten Seiten gel=F6scht werden. Hier w=FCrde > > ich vorschlagen > > eine Abfrage einzubauen, ob das Element auf den untergeordneten Seite= n > > entfert werden soll. HEUREKA! damit h=E4tte man auch gelich > > eine L=F6sung f=FCr > > das bei der ersten Frage geschilderte Problem: Wenn ich es auf den > > Untergeordneten Seiten haben will aber nicht auf der > > obersten, deaktiviere > > ich es mit der Option "Deactivatre Element only on this level" statt > > "Deactivate Element on all subsequent levels". > > ok... wird grauenhaft zu programmieren... hab da aber schon ideen, die > sich besonders mit solchen globalen seiten funktionen wie tell-a-friend= , > druckversion etc. decken wuerden... > > > Wenn Bedarf besteht w=FCrde ich mich bereit erkl=E4ren hierf=FCr > > eine Skizze zu > > erstellen. > > immer her damit... aber nur skizzen ;-) > > > btw: > > was passiert, wenn eine seite, die von einer oberseite inhalt geerbt > bekommt, verschoben wird, wo diese seite diese inhalte nicht bekommt... > ich meine, es verschwindet ja zu diesem zeitpunkt INHALTSDATEN.. ist da= s > problematisch? im workflow, muessten diese prozesse ja dem > workflowmanagement unterliegen, aber momentan... sollte man vielleicht > eine warnung ausgeben? oder einfach ignorieren... was ist sinnvoll, > solange kein workflowmgt existiert...? > > > gruss > > -- > I propose that the following character sequence for joke markers: > > :-) > 19-Sep-82 11:44 Scott E Fahlman > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > wwedit-development mailing list > wwe...@li... > https://lists.sourceforge.net/lists/listinfo/wwedit-development > |
|
From: Thomas R. <th...@by...> - 2003-11-25 10:11:54
|
> Ich würde die klassiche "Vererbungslehre" anwenden. Auf der
> Bearbeitungs-Seite, auf der die Inhalte eingegeben werden, könnte ein
> kleines Interface erscheinen, dass alle inherited Elements auflistet,
> vielleicht mit einer aktiven Checkbox, so dass der User
> einzelne Elemente
> deaktivieren kann.
sozusagen als neuer reiter? ich kann mir vorstellen, wenn die
bearbeitungsseite viele daten enthaelt, dann wird es unuebersichtlich...
und man arbeitet ja primaer mit dieser seite. folglich wird ich es
einfach erreichbar vielleicht einfach als reiter einblenden...
trotzdem finde ich es wichtig, dass man schon waehrend der eingabe
solcher vererbbaren objekte schon definieren kann, wie viele ebenen tief
diese banner angezeigt werden... schliesslich waere damit wohl schon der
"regel-sonderfall" mit ein klick abgedeckt... und fuer den
"sonder-sonderfall" gibts dann den neuen screen...
> Die ander Frage wäre, ob bei der Deaktivierung eines
> Elementes die Elemente
> auch auf untergeordneten Seiten gelöscht werden. Hier würde
> ich vorschlagen
> eine Abfrage einzubauen, ob das Element auf den untergeordneten Seiten
> entfert werden soll. HEUREKA! damit hätte man auch gelich
> eine Lösung für
> das bei der ersten Frage geschilderte Problem: Wenn ich es auf den
> Untergeordneten Seiten haben will aber nicht auf der
> obersten, deaktiviere
> ich es mit der Option "Deactivatre Element only on this level" statt
> "Deactivate Element on all subsequent levels".
ok... wird grauenhaft zu programmieren... hab da aber schon ideen, die
sich besonders mit solchen globalen seiten funktionen wie tell-a-friend,
druckversion etc. decken wuerden...
> Wenn Bedarf besteht würde ich mich bereit erklären hierfür
> eine Skizze zu
> erstellen.
immer her damit... aber nur skizzen ;-)
btw:
was passiert, wenn eine seite, die von einer oberseite inhalt geerbt
bekommt, verschoben wird, wo diese seite diese inhalte nicht bekommt...
ich meine, es verschwindet ja zu diesem zeitpunkt INHALTSDATEN.. ist das
problematisch? im workflow, muessten diese prozesse ja dem
workflowmanagement unterliegen, aber momentan... sollte man vielleicht
eine warnung ausgeben? oder einfach ignorieren... was ist sinnvoll,
solange kein workflowmgt existiert...?
gruss
--
I propose that the following character sequence for joke markers:
:-)
19-Sep-82 11:44 Scott E Fahlman
|
|
From: Juri M. >> w. <jur...@we...> - 2003-11-25 09:59:41
|
Ich w=FCrde die klassiche "Vererbungslehre" anwenden. Auf der Bearbeitungs-Seite, auf der die Inhalte eingegeben werden, k=F6nnte ein kleines Interface erscheinen, dass alle inherited Elements auflistet, vielleicht mit einer aktiven Checkbox, so dass der User einzelne Elemente deaktivieren kann. Es stellt sich bei dieser L=F6sung folgende Fragen: wie kommet der User a= uf darunterliegenden Seiten wieder an ein ggf. auf der Eleternseite deaktiviertes Elemenet heran? Hier k=F6nnte man ein Elemet hinzuf=FCgen-M= en=FC einf=FChren, das aber wohl zu einem sp=E4teren Zeitpunkt, denn das ist ei= ne eher untypische Anfordreung. Die ander Frage w=E4re, ob bei der Deaktivierung eines Elementes die Elem= ente auch auf untergeordneten Seiten gel=F6scht werden. Hier w=FCrde ich vorsc= hlagen eine Abfrage einzubauen, ob das Element auf den untergeordneten Seiten entfert werden soll. HEUREKA! damit h=E4tte man auch gelich eine L=F6sung= f=FCr das bei der ersten Frage geschilderte Problem: Wenn ich es auf den Untergeordneten Seiten haben will aber nicht auf der obersten, deaktivier= e ich es mit der Option "Deactivatre Element only on this level" statt "Deactivate Element on all subsequent levels". Wenn Bedarf besteht w=FCrde ich mich bereit erkl=E4ren hierf=FCr eine Ski= zze zu erstellen. j > -----Urspr=FCngliche Nachricht----- > Von: wwe...@li... > [mailto:wwe...@li...]Im Auftrag von > Thomas Richter > Gesendet: Dienstag, 25. November 2003 02:17 > An: Wwedit-Development > Betreff: [Wwedit-development] cvs update & ein neues feature & euer > feedback... > > > hi, > > nach einer langen coding session diese nacht, habe ich soeben ein neues > feature in wwedit implementiert. > > folgende details dazu: > > bei der definition von content-objekten kann man ein spezielles attribu= t > _inherit definieren. dies war sonst standardmaessig 0, da dieses featur= e > noch nicht implementiert war. > > durch setzen auf 1 erreicht man, dass alle inhalte von diesem typ an > contentobjekten auch auf ALLEN unterseiten vorhanden sind. dies > bedeutet, dass man zum beispiel 'banner' als eigenes contentobjekt > definieren kann, und durch setzten von _inherit=3D1 eingebene banner au= ch > auf unterseiten vorhanden sind - und dass ganz unabhaengig vom seitenty= p > (also kann man nun auch banner auf sitemap/ kontakt und suche setzen). > > wichtig ist dabei, dass die natuerlich nicht automatisch angezeigt > werden, sondern dass sich das smarty template darum kuemmern muss. > > mein problem, was ich hier diskutieren will, ist, dass nicht immer alle > solche 'vererbbare' objekte auf allen unterseiten sichtbar sein > sollen.... wie loesst man das am besten...? > > eine idee waere, dass man bei eingabe von solchen objekten angeben kann= , > wieviele ebenen tief, bzw. ob ueberhaupt, sich das objekt fortpflanzen > soll. das ist einfach und fast schon ausreichend. problematisch ist es > natuerlich, dass dann natuerlich innerhalb einer ebene keine ausnahmen > gemacht werden koennen... :( > > wie waers vielleicht zusaetzlich mit einem ausschlussverfahren... d.h. > der user kann bei der eingabe eines solchen objektes zusaetzlich auch > noch explizit sagen, auf welchen seiten es nicht angezeigt werden > darf...? > > bitte um kreative idee, wie man so etwas FUER DEN USER am besten loesen > koennte... > > > achso... nach einigen wochen hab ich es auch endlich geschafft, einige > probleme auf mac browsern (safari, ie) zu loesen... scheinbar handelte > es sich dabei nur ein bug bei der bildauswahl im pagetype pt_exttext. > (die schlimmen haben nach auswahl des bildes die inputbox nicht mit der > url des bildes gefuellt....). - is gefixt und in der aktuellen cvs > version... > > > nun mit der fast fertigen vererbung von inhalt, ist auch das letzte bet= a > release von wwedit2.1 (beta2) nicht mehr fern... > > > liebe gruesse > > > auf feedback wartend - thomas > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > wwedit-development mailing list > wwe...@li... > https://lists.sourceforge.net/lists/listinfo/wwedit-development > |
|
From: Thomas R. <th...@by...> - 2003-11-25 09:54:15
|
hi tobi, > - ferner wird beim vorhandensein eines inherit Elements (mehr > als 3 werden > es ja wohl kaum in einer Seite werden) auf der > Übersichtsseite, dort wo man > den ganzen Seitenbaum sehen kann, eine weitere Spalte mit checkboxen > angezeigt, die alle checked sind. Wenn ich jetzt auf einer > oder mehreren > Seiten das Element nicht will, dann entferne ich das Häkchen. > Wenn das sich zu schwierig gestaltet, sollte auf der > Informationsseite zu > den einzelnen Seiten diese Checkbox vorhanden sein. > Mit dieser Variante könnte man sich dann auch die Angabe der > Vererbungstiefe > ersparen. stell dir folgende seite vor: home | +-service | +-kontakt | | | +-post | +-anfahrt +-suche nun moechte ich ein paar banner auf der startseite platzieren. diese banner sollen aber nicht auf der post und anfahrt seite erscheinen. auf der kontakt seite stelle ich zusaetzliche banner ein, diese sollen dann auf post und anfahrt erscheinen. auf der kontaktseite sollen nun alle banner auftauchen... sowas geht mit deinen prinzip nicht... haben wir aber zum beispiel schon bei einigen seiten bei wegewerk mit wwedit1 gehabt (wenn auch haendisch)... wie waers mit einen neuen reiter bei seiten, die von oberseiten solchen inhalt geerbt bekommen? auf diesem sind dann alle geerbten objekte aufgelistet und es kann fuer jedes einzelne bestimmt werden, dass es auf der aktuellen seite und auf allen unterseiten nicht mehr angezeigt werden darf... *gruebel* *gruebel* > Dickes Lob auch für die Entfernung der Bugs in den elendigen > Mac Browsern. danke... danke... ;-) |
|
From: Tobias H. | megalomanix.d. <in...@me...> - 2003-11-25 08:24:12
|
Moin, moin an alle... Das Feature mit dem inherit Element finde ich sehr , sehr n=FCtzlich. Wenn es denn technisch m=F6glich ist, stelle ich mir das = Ausschlussverfahren f=FCr die Anzeige so vor: - man kann angeben auf wie viele Unterebenen sich das Element vererbt. - ferner wird beim vorhandensein eines inherit Elements (mehr als 3 = werden es ja wohl kaum in einer Seite werden) auf der =DCbersichtsseite, dort = wo man den ganzen Seitenbaum sehen kann, eine weitere Spalte mit checkboxen angezeigt, die alle checked sind. Wenn ich jetzt auf einer oder mehreren Seiten das Element nicht will, dann entferne ich das H=E4kchen. Wenn das sich zu schwierig gestaltet, sollte auf der Informationsseite = zu den einzelnen Seiten diese Checkbox vorhanden sein. Mit dieser Variante k=F6nnte man sich dann auch die Angabe der = Vererbungstiefe ersparen. Dickes Lob auch f=FCr die Entfernung der Bugs in den elendigen Mac = Browsern. Werde diese Woche die ersten Teile der Dokumentation auf die Seite = stellen, habe mich erstmal auf den Adminbereich konzentriert. Gr=FCsse, Tobias PS: wer hat die lustigen Screenshots eingestellt? W=FCrde die gerne austauschen, gegen welche die nicht so geheimnisvoll daher kommnen. :) |
|
From: Thomas R. <th...@by...> - 2003-11-25 01:16:05
|
hi, nach einer langen coding session diese nacht, habe ich soeben ein neues feature in wwedit implementiert. folgende details dazu: bei der definition von content-objekten kann man ein spezielles attribut _inherit definieren. dies war sonst standardmaessig 0, da dieses feature noch nicht implementiert war. durch setzen auf 1 erreicht man, dass alle inhalte von diesem typ an contentobjekten auch auf ALLEN unterseiten vorhanden sind. dies bedeutet, dass man zum beispiel 'banner' als eigenes contentobjekt definieren kann, und durch setzten von _inherit=1 eingebene banner auch auf unterseiten vorhanden sind - und dass ganz unabhaengig vom seitentyp (also kann man nun auch banner auf sitemap/ kontakt und suche setzen). wichtig ist dabei, dass die natuerlich nicht automatisch angezeigt werden, sondern dass sich das smarty template darum kuemmern muss. mein problem, was ich hier diskutieren will, ist, dass nicht immer alle solche 'vererbbare' objekte auf allen unterseiten sichtbar sein sollen.... wie loesst man das am besten...? eine idee waere, dass man bei eingabe von solchen objekten angeben kann, wieviele ebenen tief, bzw. ob ueberhaupt, sich das objekt fortpflanzen soll. das ist einfach und fast schon ausreichend. problematisch ist es natuerlich, dass dann natuerlich innerhalb einer ebene keine ausnahmen gemacht werden koennen... :( wie waers vielleicht zusaetzlich mit einem ausschlussverfahren... d.h. der user kann bei der eingabe eines solchen objektes zusaetzlich auch noch explizit sagen, auf welchen seiten es nicht angezeigt werden darf...? bitte um kreative idee, wie man so etwas FUER DEN USER am besten loesen koennte... achso... nach einigen wochen hab ich es auch endlich geschafft, einige probleme auf mac browsern (safari, ie) zu loesen... scheinbar handelte es sich dabei nur ein bug bei der bildauswahl im pagetype pt_exttext. (die schlimmen haben nach auswahl des bildes die inputbox nicht mit der url des bildes gefuellt....). - is gefixt und in der aktuellen cvs version... nun mit der fast fertigen vererbung von inhalt, ist auch das letzte beta release von wwedit2.1 (beta2) nicht mehr fern... liebe gruesse auf feedback wartend - thomas |
|
From: Thomas R. <th...@by...> - 2003-11-01 19:53:31
|
Hi Leute, Die letzten Tage bei mir waren etwas stressig.... vieles ist mir durch den kopf gegangen (besonders einige bekanntgewordene probleme) und ich hab mich mit einer laengerfristigen loesung beschaeftigt. einige sachen moechte ich hier vorstellen und eventl. zur diskussion stellen: punkt 1. die idee mysql fulltext-suche (tolles ding... automatisches ranking durch relevanz bestimmung etc.) habe ich mal ueber den haufen geworfen, da es eine etwas verrueckte idee ist, sich fuer die PEAR DB Klasse zu entscheiden, mit der man fast jedes beliebige RDBMS benutzen kann und sich dann fuer eine so DB spezifische Suchimplementierung zu entscheiden. dafuer habe ich allerdings nun in alles pagetypes, bei denen es notwendig ist(pt_text,pt_exttext,pt_extform) die suche implementiert und eine doku geschrieben, wie man eine suche auf der eigenen seite einbaut (./docs/pt_search.txt, bzw. beispiel in ./templates/suche.tmpl.html). punkt2. Das "404 Problem": Bisher funktionierte das CMS auf folgende Art und Weise: Der Browser fragt nach einer Seite innerhalb von wwEdit. Diese Seite existiert in den meisten Faellen nicht und ein 404 (Not Found) wird ausgeloest. Durch entsprechende Konfiguration wird ein ErrorDokument definiert, welches ueberprueft, auf welche Seite zugegriffen werden sollte und sucht sie in der Datenbank und wenn sie gefunden wurde wird ein Code 200 (OK) und die gefundene Seite gesendet. Das Problem: Anscheinend haben einige CGI Installationen ein Problem damit, dass ich den "HTTP/1.1 200 OK" Code senden will und brechen deswegen zusammen. Das wiederum bedeutet, dass man die Seite nur ohne senden der OK Codes betreiben kann, was wiederum dafuer sorgt, dass Suchmaschinen die Seite nicht durchsuchen. und das ist doof. Desweiteren weiss ich auch gar nicht, wie sich andere Webserver ausser Apache mit einer solchen Technik vertragen. Deswegen habe ich lange da gesessen und einen Mechanismus implementiert, der zusaetzlich zu dem Aufruf ueber ein ErrorDokument folgende Aufrufe gestatten: 1. Aufruf ueber die Seiten-ID (also called 'pageid'): index.php?id=23 Der Name der Variablen (hier id) laesst sich beliebig in der Konfigurationsdatei definieren. 2. Aufruf ueber die Seiten-Url (also called 'pagepath'): index.php?id=/service/contact/ Auch hier kann der Name der Variablen frei definiert werden. :) 3. Aufruf ueber Fake-Urls (also called 'pageinfo'): index.php/service/contact/ Fuer diese Technik muss garantiert werden, dass die Umgebungsvariable PATH_INFO durch den Webserver gesetzt wird. Dies sollte standardmaessig der Fall sein, kann beim Apache auch durch die Konfigurationsdirektive AcceptPathInfo On aktiviert werden. Ich denke besonders auch der zweite Aufruf ist interessant, da sich so mit Hilfe von mod_rewrite genau das gleiche Ergebnis wie mit der ErrorDocument Direktive erreichen lassen. Achso: Normalerweise funktionieren alle Techniken gleichzeitig (vorrausgesetzt ErrorDocument und AcceptPathInfo sind richtig eingestellt). Durch setzen einer Konfigurationsanweisung (call_method) in der misc.ini wird allerdings auch beeinflusst, dass die Navigationen auch gleich die richtigen Links liefern! Angenommen ich schaffe es noch bis zur Vollendung von wwEdit 2.1 Final das Linkmanagement, waere das doch eine tolle Sache !? punkt 3. wie alle wissen sollten, sind in wwedit epoz und edit on pro integriert. nach einigen ringen habe ich mich dazu entschieden diese wieder aus dem wwedit2 packet zu entfernen. allerdings habe ich eine schnittstelle geschaffen, die es ermoeglicht diese editoren nahtlos ins system zu integrieren. epoz und eopro sind nun extra module im cvs (hostname: cvs.sourceforge.net repository: /cvsroot/wwedit/ modul wysiwyg). diese koennen in ein beliebiges verzeichnis (ganz unabhaengig von wwedit (also auch auf einen anderen server)) installiert werden. durch angabe in der misc.ini werden diese dann in wwedit zur verfuegung gestellt. (moeglich machts eine einheitliche javacsript api, die dafuer sorgt, dass der editor den content aus der seite laedt, bzw. wieder reinspeichert.) uebrings: ein netter nebeneffekt: installiert editonpro auf einen server mit einer lizens fuer diesen. durch das konfigurieren von wwedit2, ist es dann moeglich bei verschiedenen wwedit installationen das gleiche lizensfile von edit-on-pro zu benutzen (bitte beachtet aber trotzdem die lizensbestimmungen!). Achja.... nach einigem recherieren ist es mir nun auch gelungen die Toolbox (da wo man bilder und dateien hochladen kann) AUCH in editonpro zu integrieren. dadurch kann man bilder einfach durch klick in editonpro einbinden!!!!! so nun noch meine aktuelle todo liste: wwEdit 2.1 Final ---------------- + feature: eigenes passwort aendern + fix: usermanagement, backup, loginhistory nur fuer den masteradmin + feature: userpreferences: einstellen der groessen der eingabe felder etc. + feature: standardmaessig 2 themes integrieren + feature: "Linkfinder" bei Linkfeldern (interne Verlinkungen, Dateien etc.) + feature: Linkmanagement (wenns klappt!) wwEdit 2.2 Final ---------------- hoffentlich mit folgenden Features: + ACL (Access Control Lists): Rechtesystem + Workspace System + Workflowmanagement + Seitentyp Bildergalerie, Downloadbereich, RSS-Reader + Plugin Architektur fuer globale Website/Seitenfunktionen (Tell-A-Friend, Druckversion, Seitengrafik, Navigationsgrafik, Metanavigation etc.) das wars dann mit dieser langen mail. bei kritik/anregungen wuerden ich mich freuen -- b y t e f r e a k . d e - - - - - - - - - - - - - - . Thomas Richter . Kochhannstr. 6 . 10249 Berlin . Germany . . mobile +49-160-80 454 81 . home +49-30-39 48 0248 . web http://bytefreak.de |
|
From: Thomas R. <th...@by...> - 2003-10-22 16:15:58
|
Hi, Nachdem ich gestern festgestellt habe, dass der Bug mit dem Sortieren im PEAR Package DB_NestedSet behoben ist, musste ich feststellen, dass in diesen Versionen ein neuer Bug enthalten ist, der es unmoeglich macht Seiten ueber die Copy/Cut & Paste funktion zu kopieren/verschieben. Ich habe bereits ein Bug Report abgeschickt und hoffe, dass es bald eine funktionierende Version von DB_NestedSet gibt. Ansonsten ist hier eine kleine Anleitung, wie man den Bug selbst beheben kann (getestet!): Im PEAR Installationsverzeichnis im Ordner ./DB/ in der Datei NestedSet.php Zeile: 1736 $this->_moveAcross($source,$target,$pos); einfach folgendermassen umschreiben: $newid = $this->_moveAcross($source,$target,$pos); und dann vor der naechsten schliessenden geschweiften Klammer (}) eine neue zeile einfuegen: return $newid; und schon laeufts. thomas |
|
From: Thomas R. <th...@by...> - 2003-10-21 18:57:14
|
Hallo, Vielleicht ist es manchen schon aufgefallen. Es gab da vor einiger Zeit ein paar Probleme mit dem Sortieren von Seiten innerhalb der Navigation, nachdem man besonders ausgiebig mit Ausschneiden & Einfuegen gearbeitet hat. Ich konnte gestern dieses Problem indentifizieren und musste feststellen, dass es sich leider um ein Bug im PEAR Package DB_NestedSet handelt. Dieses Problem ist in der aktuellen Version (1.3) behoben. ABER! Leider hat sich der Author von DB_NestedSet entschieden, die API seiner Klasse etwas zu aendern. Ausgewirkt hat sich das auf einige Teile des CMS, weswegen ich heute mich um die entsprechenden Anpassungen gekuemmert habe. Was das bedeutet: Wenn Ihr wollt, dass der Fix 'Seiten sortieren' behoben sein soll, muesst Ihr die aktuellste DB_NestedSet installieren und evetl. vorhandene CMS Installationen auf die kommende Version aktualisieren. Ich werde innerhalb der naechsten 2 Tage diese Version mit weiteren Bufixes & Feature Improvements veroeffentlichen (also mal ein richtiges Release auf Sourceforge unter der Version 2.1 Beta). Folgende Features sind bis dahin zu erwarten : Backup Funktionalitaeten einer produktiven Seite : 2 verschiedene Backend Themes mit Moeglichkeit zwischen diesen zu Wechseln : einfache Nutzerverwaltung : Login History : funktionierendes Kopieren/Verschieben von Seiten im Sprachmodus 'sync' : funktionierendes Verschieben von Seiten innerhalb der Navigation Das wars. Thomas |
|
From: Thomas R. <th...@by...> - 2003-09-05 01:24:22
|
Hallo interessierte, Freudige nachricht erhielt ich eben vom sourceforge support team. Das bereits existierende cvs modul wurde erfolgreich auf den sourceforge server uebertragen. Damit ist es nun ein wirkliches opensource projekt... Die projekt website mit task listen, feature request(unter tracker zu finden), buglisten, mailingliste, file releases und einen webzugang zum cvs ist unter http://sourceforge.net/projects/wwedit aufrufbar. Dort ist auch eine kleine anleitung zum cvs zu finden, aber ich wird trotzdem ein paar worte dazu ablassen: Es gibt zwei zugriffsmoeglichkeiten: 1. anonym, nur lesend: authentifizierung: pserver nutzername: anonymous server: cvs.sourceforge.net cvsroot: /cvsroot/wwedit passwort leer lassen 2. developemtaccess mit schreibrechten. Authentifizierungsmethode: ext, bzw. ssh nutzername ist euer sourceforge login passwort euer sourcforge passwort server: cvs.sourceforge.net cvsroot: /cvsroot/wwedit Das modul, welches den wwedit sourcecode enthaelt heisst nun auch nicht mehr cms, sondern ganz offiziell wwedit! methode zwei koennen nur projektmitglieder durchfuehren. Es wird allerdings niemand von der entwicklung, bzw. vom streben ein projektmitglied zu sein, abgehalten ;-) Ich denke in naher zukunft werde ich noch ein alternatives backend von vincent ebenfalls zur verfuegung stellen. Uebrings: alle fleissigen entwickler und alle helfer werden, wie in os projekten ueblich, in der Credits datei unter ./docs/ namentlich mit einer gewuenschten email adresse und einem evtl. vorhandenen amazon wunschzettel, alphabetisch erwaehnt... ;-) Na dann mal ne gute nacht und froehliches entwickeln... thomas |
|
From: Thomas R. <th...@by...> - 2003-09-03 09:16:27
|
Hi Leute, Gestern abend habe ich das erste Release Candidate 1 des neusten pagetypes fertig gestellt. es handelt sich, wie in meiner gestrigen email beschrieben um eine moeglichkeit auf einer website nahezu beliebige formulare zu verwenden, und die eingegebenen daten per email zu verschicken. Eine kurze Funktionsbeschreibung: 1. Ein formular wird ueber die templates.ini an ein template gebunden. Dabei wird als pagetype pt_extform benutzt. um nun ein bestimmtes formular auf dieser seite zu benutzten, muss das feld definition auf eine formular definition gesetzt werden. 2. forularedefinitionen werden in der datei forms.ini eingetragen. ein beipiel liegt unter http://wwedit.sourceforge.net/screenshoots/01_forms.ini.jpg. als sektionsname dient der wert im defintionfeld des templates in der template.ini. folgende merkmale koennen zu einem formular definiert werden: - Name des Formulars (wird im Backend angezeigt, kann im Frontend angezeigt werden) - Eine optionale BCC Adresse, an die IMMER eine Kopie der Daten geschickt werden soll. - Eine absenderadresse fuer die emails, die an den redakteur gehen - ein betreff fuer die emails - einen contenttype (zbsp.: text/plain oder text/html, je nachdem, ob html mails oder text mals versand werden sollen) - ein smarty template file, welches sich im ordner ./templates/ befinden muss. dieses template wird benutzt, um die email zu texten und zu gestalten. - liste an formularfeldern und texten 3. die einzelnen formularfelder werden in der fields.ini definiert. als sektionname wird der name aus der feldliste in der forms.ini benutzt. ein feld besteht aus mehreren feldern: - einen namen (der der auch als name fuer das formular im frontend benutzt werden muss) - ein Label (fuer das backend) - einen typ (selectone, selectmore, input, text, label) text und label ermoeglichen es dem redakteur im backend texte zu definieren. der unterschied liegt in der darstellung als textarea oder input box. - verfuegbare values (fuer selectone, selectmore), welche fuer eine auswahl zur verfuegung stehen (selectboxen, radiobuttons, checkboxen) - einen default wert - und validierungsregeln 4. validierung von formularen. - validierung wir dmit hilfe der PEAR Klasse Validate realisiert - man muss ja das rad nicht neu erfinden. - conditions ist eine kommagetrennte liste von bedingungen: + min_length:anzahl definiert eine min. laenge der eingabe + max_length:anzahl definiert eine max. laenge der eingabe + min_count:anzahl definiert fuer selectmore eine min. anzahl ausgewaehlter elemente + max_count:anzahl definiert fuer selectmore eine max. anzahl ausgewaehlter elemente + email es muss sich um eine email-adresse handeln + url es muss sich um eine url handeln + number es muss sich um eine ganze zahl handeln + min mindest wert einer zahl + max maximal wert einer zahl so. ich hoffe der funktionsumfangst so einigermassen bewusst geworden. wem auffaellt, dass was fehlt (zum beispiel validierung fuer kommazahlen oder liste von email-adressen) , dann doch bitte bescheid geben. gruss thomas |
|
From: Thomas R. <th...@by...> - 2003-09-02 08:18:23
|
Hi Liste, Unter http://wwedit.sourceforge.net/screenshoots/ findet Ihr die ersten Screenshoots des neusten pagetypes. Ich habe ein Beipiel Formular konfiguriert, welches im ersten Bild zu sehen ist. Die anderen Bilder enthalten die Konfigurationsanweisungen fuer das Formular: 02_xxx.jpg [templates.ini] 03_xxx.jpg [forms.ini zur konfiguration der formulare] 04_xxx.jpg [fields.ini zur konfiguration der einzelnen formularfelder] Gegenwaertig ist erst mal die Backend-Schnittstelle fertig und funktioniert. Das Feature, dass die Daten die der Nutzer im Frontend eintippt gespeichert werden, ist noch nicht implementiert und werde ich erst mal auf die lange Bank schieben. An die Frontend-Schnittstelle mit samt der automatisierten Validierung (fields.ini der Eintrags conditions=), welches wohl das coolste an dem pagetype ist, werde ich heute abend coden. heil eris thomas |
|
From: Thomas R. <th...@by...> - 2003-09-01 21:07:53
|
schon mal ueber ein barrierefreies cms nachgedacht? ich glaub mal was davon gehoert zu haben. bei contentmanager.de gibt es im forum einen interessanten thread dazu. demnach ist wohl das sixcms barrierefrei. mehr ist eigentlich nicht zu finden. vielleicht sollte man sich mal gedanken darueber machen... ich denke ein opensource cms mit einem alternativen backend (was nicht mal aehnlich dem sein muss, was momentan laeuft) und dieses wirklich alle personen anspricht, ist sicher wirklich was, was das cms in den vordergrund ruecken koennte... vielleicht sollten wir uns das mal freihalten und wirklich ernsthaft in betracht ziehen? @tobi: was denkst du sind momentan die groessten probleme des backends? (label-tags ausgeschlossen... genauso die tabellen... ich denke die sind problemlos umzustellen.) gruss thomas 'ich will schlafen' richter |
|
From: Thomas R. <th...@by...> - 2003-09-01 17:27:11
|
> Wenn Ihr diese mail lest diese ail hier, weil ihr in der > mailingliste wwe...@li... aufgenommen seit. hab ich erwaehnt, dass alle beschwerden bzgl. rechtschreibung/ grammtik bei mir nach /dev/null gehen? also versucht es gar nicht erst... ;-) thomas |
|
From: Thomas R. <th...@by...> - 2003-09-01 13:15:55
|
Hi Leute, Wenn Ihr diese mail lest diese ail hier, weil ihr in der mailingliste wwe...@li... aufgenommen seit. war das ne doofe entscheidung von mir euch aufzunehmen, und ihr wollt wieder raus, dann besucht einfach: http://lists.sourceforge.net/lists/listinfo/wwedit-development/ dort koennt ihr euch wieder austragen. warum es mir eigentlich geht: ich moecht eine gute zusammenarbeit erreichen und mit euch einige ideen austauschen, um das cms in eine gute richtung weiterzuentwickeln. eine funktionalitaet, welche ich in zukunft fuer wichtig erachte sind interaktive elemente auf der website. besonders formulare gehoeren dazu. momentan haben wir schon eine mini-loesung fuer sowas. page pt_mailform denkt aber noch lange nicht alle anforderungen ab. dort ist es bisher nur moeglich 3 Formularfelder auf einer seite zu benutzen. diese muessen dann auch noch vom type textarea oder input type="text" sein. meine vorstellung ist die entwicklung eines neuen pagetypes (pt_extform). mit diesem soll es moeglich sein, dass der adminsitrator der seite mit hilfe von ini dateien formulare definieren kann. durch die zuweisung zu einem smarty template laesst sich dies dann auch fuer den endnutzer visualisieren. der pagetype kuemmert sich um die analyse der formularkonfiguration und visualisiert dieses im eigentlichen redaktionssystem und ermoeglicht dem redakteur zusaetzliche texte und konfigurationen einzugeben. folgende anforderung stelle ich an ein solchen modul: 1. verschiedene formularfelder konfigurierbar durch siteadmin - textarea/ input type="text" - checkboxen/ multiple selectbox - radiobuttons/ single selectbox 2. siteadmin kann textbloecke definieren, welche der redakteur verwalten kann 3. redakteur kann definierte textbloecke verwalten 4. siteadmin kann processing mode definieren - mode 1: die daten die ein nutzer im frontend eingibt, werden in einer datenbank gespeichert und koennen durch einen redakteur im cms eingesehen werden. optimal waere natuerlicht dann auch eine freikonfigurierbare export moeglichkeit (xml,cvs,txt,xls etc.) - mode 2: die daten werden per email an eine durch den redakteur definierte email adresse geschickt. - mode 3: kombination aus mode 1 und mode 2. es wird verschickt & gespeichert ich denke es handelt sich um eine coole loesung, welche ich plane so zu codieren, dass ein weiter benutzen in anderen projekten moeglich ist. gerade die obigen anforderungen treffen ja eigentlich auf nahezu jedes projekt zu. somit liegt es nahe eine kleine klassebibliothek zu entwerfen, welche die funktionalitaet implementiert, sowie einen pagetype zu definieren, welcher dann mit hilfe der klassenbibliothek die obige funktionalitaet in das cms einbindet. auf kritik und vorschlaege bin ich gespannt. moechte schliesslich nicht irgendwas uebersehen haben, und dann im nachhinein mehr arbeit haben, als es noetig ist. thomas ps.: ihr muesst nicht nur eigene interessen vertreten. auch funktionalitaeten, die ihr nie brauchen wuerdet sollten mal als idee vorgestellt werden. |
