Serendipity Forums

• coreupdate mit autoupdate,
• Anzeige der entrydrafts,
• Anzeige der entrycomments,
• Anzeige der entrycommentspending,
• Anzeige der entryfutures,
• Buttons der pluginupdates,
• (todo) Aufräumen der cleansmartycompiles

Timbalu wrote:Mittendrin habe ich die weiteren Arbeiten eingestellt, das es hieß, es wäre irgendwo ein neues Backend in Arbeit.

Timbalu wrote:An dieser Stelle bräuchte ich mal ein paar Vorschläge und Ideen, wie sich ein template basiertes Dashboard mittels JQuery wirkungsvoll zu individuell anpassbaren und verschiebbaren Blöcken zusammenbauen und stylen ließe...

Timbalu wrote:Ist denn jemand dabei dein Backend-Gerüst in die Core Dateien tatsächlich zu integrieren, oder nur zu helfen diesen Prototyp zu vervollständigen.

Timbalu wrote:Warum findet die Auseinandersetzung, die Suche nach Helfern, die Fragen, etc nicht über das Forum statt?

Timbalu wrote:Ich kann mich nicht erinnern darüber je etwas gelesen zu haben, außer der wagen Andeutung das jemand eventuell darüber brütet.

Timbalu wrote:Inline styles sind nur vorhanden, solange ein display/hide script darauf zugreifen muss. Wenn das ohne inline styles zu lösen ist, bitte her damit.

Timbalu wrote:Ansonsten hätte ich gerne konkreteres!

yellowled wrote:Vorher macht es keinen Sinn, über die Integration in den Kern auch nur nachzudenken.

yellowled wrote:Wenn es einen vorzeigbaren, ausgegorenen Prototypen gibt, kann und wird hier darüber diskutiert werden – bis dahin steht es jedem frei, sich auf GitHub zu beteiligen.

yellowled wrote:Ich habe es vorgezogen, dazu die Leute aus der s9y-Truppe per E-Mail zusammenzutrommeln, die tatsächlich Frontend machen. Was ist Dein Problem damit?

yellowled wrote:Natürlich ist das ohne Inline-Styles zu lösen – durch addClass und removeClass etwa. ... Abgesehen davon, dass man mit einem style="display:none;" mal eben sämtliche Screenreader aussperren kann.

yellowled wrote: ... – so lange so etwas nicht klar getrennt und modifizierbar (also smartifiziert und mit externem, überschreibbaren CSS versehen) ist, ...

yellowled wrote:(Ja, ich weiß, dass es nicht viele Admin-Templates gibt. Ich weiß aber auch, warum das so ist.)

yellowled wrote:

Timbalu wrote:Ansonsten hätte ich gerne konkreteres!

Äh, ich auch. Was brauchst Du denn nun?

Timbalu wrote:(Ich erlebe immer wieder das manche Serendipity Blogger über lange Zeit von den Möglichkeiten ihres Systems keine Ahnung haben, weil es sie erstmal überfordert, wie es jetzt präsentiert wird. Hier muss also ein Design her, das Informationen gibt, Neugierig macht, Ängste nimmt, Wege verkürzt, auf Wichtiges und Entwicklungen hinweist, Freiheiten ermöglicht, usw. usw. usw., Die "autoupdate" Diskussion ist ja ein Teil davon.)

hagenroewer wrote:Das löse ich momentan anders, ... 2-Rollen-Modell

Timbalu wrote:Ah soooo, da bin ich schon wieder einen Schritt weiter

Timbalu wrote:Der Prototyp ist aber doch nur wirklich anschaubar, wenn er auf echte Daten zugreifen kann.

Timbalu wrote:Eigentlich gar keines, bis auf den fahlen Beigeschmack einer gewissen Selbstherrlichkeit...

Timbalu wrote:Vielleicht hättest du das einfach ein wenig offener kommunizieren sollen.

Timbalu wrote:hmmm, Screenreader im Backend halte ich für kein besonders haltbares Argument.

Timbalu wrote:Ich brauche das "display:none" für den switch zwischen body|truncate und fullBody.
Gib mir doch bitte mal ein funktionfähiges Beispiel für eine add/remove Class möglichst mit jquery.

HTML:
<div id="foobar" class="whatever">[…]</div>

CSS:
.whatever { display: none; }

jQuery:
$(function() {
	$('#foobar').click(function(){
		$(this).toggleClass('whatever');
	})
});

Timbalu wrote:Ja, wenn nicht dazu..., wozu mache ich das überhaupt, tztztz!

Timbalu wrote:Da wir ja von einer Backend-Gestaltung reden, ist die Notwendigkeit für (User) Templates ja auch nicht so groß wie im Frontend. Hier muss ausgewogen abgeschätzt werden, wieviel Design, zuungunsten der Performance wirklich nötig und vertretbar ist.

Timbalu wrote:Die Frage des Verbleibs bei PHP-Layouts vs Smarty-Layouts sollte aber m.E. dringend geklärt sein, bevor man beginnen kann die Backend HTML Struktur schrittweise an ein moderneres Layout anzupassen.

Timbalu wrote:zB per JS verschiebbare Blöcke zur individuellen Anpassung, horizontale oder vertikale inner-Blockscroll_JS-Funktionen, etc etc etc

Timbalu wrote:Das mit dem Screenreader, display:none und fehlender Barrierefreiheit war mir nicht bewusst, danke der Nachhilfe. Kann man dann dein genannte Beispiel trotzdem verwenden?

Timbalu wrote:Zählt soetwas dann nicht mehr als inline-style, da es nur im "Aufbau-HTML" des Browsers stattfindet? Und stört das dann einen Screenreader nicht mehr?

Timbalu wrote:Gibt es außerdem Ideen oder Vorbilder, wie man eine dynamische Anzahl Entries für diesen Block (entweder aus der Config, bzw aus der eigentlichen sql query), also zwischen 1 und X, einzeln klappbar machen kann?

Timbalu wrote:Kann man aus einem Plugin heraus die Ausgabe des gesamten Backends bestimmen, bzw overlayen, also head, body, seitenleiste, main, und footer? Wenn ja, Wie? Letztendlich wäre erst dann so ein Dashboard das was es zu sein vorgibt...!

yellowled wrote:Doch, es wäre ein Inline-Style, auch wenn es nur dynamisch im DOM vorhanden wäre. Aber immerhin ist relativ unwahrscheinlich, dass genau diesen Style jemand per CSS überschreiben möchte. Sauberer ist der Weg über eine Klasse, der aber eben bestimmte Effekte umständlicher umsetzbar macht. Und Screenreader hätten (nehme ich an) ebenso Probleme damit, es sei denn (was scheinbar noch recht häufig vorkommt), die unterstützten kein JS oder hätten es deaktiviert.

yellowled wrote:Verstehe ich nicht. Natürlich kannst Du auch dynamisch erzeugten Elementen (etwa über eine Klasse statt einer id) dieses Verhalten zuweisen …?

 jQuery(document).ready(function($) {
 $("div#entrybox a.button").click(function () {$("div#entrybox div.boxed").slideToggle("slow");});
});

    <div class="dashboard dashboard_comments">
        <h3> {$CONST.COMMENT} </h3>

            {foreach from=$comments item=co name='foo'}
            
            <div id="entrybox"> 
                
                <div class="blah" id="comment_{$co.id}">
                    <label class="x"> <a href="#colist_{$smarty.foreach.foo.iteration}" class="button"> Press Here</a> </label>
                
                    {body}
                
                    <div class="boxed">
                        <a name="colist_{$smarty.foreach.foo.iteration}"></a>
                        {detail+adminbox}
                    </div>
				
                </div>
						
            </div><!-- #entrybox end -->
          
            {/foreach}
            
    </div>

yellowled wrote:Was meinst Du mit „overlayen“?

Timbalu wrote:Das hört sich für mich an wie Rücksicht nehmen ist ganz gut, zu gewährleisten ist aber garNix...

Timbalu wrote:Also heute Nacht kam mir die Idee, ob ich nicht den 'backend_config' hook nehmen, versuchen das ganze "Admin Framework", wie head, body, sidebar, content, footer entsprechend im Dashboard nachbilden und ausgeben könnte, ohne das die weiteren Ausgaben und Abläufe erfolgen, sich das Dashboard also anstelle über die bisherige Backendstruktur legt... Bevor ich das weiter verfolge, wollte ich eigentlich nur mal wissen, ob das generell möglich ist und der eingeschlagene Weg über diesen Hook der richtige sei (schwierig wird es so oder so, nehme ich mal an).

yellowled wrote:Aus meiner Sicht ist das Dashboard Teil des Backends, ersetzt es aber nicht.