[TYPO3-german] DIR include ab TYPO3 6.2

[Andreas Becker]

@ Georg:

Danke fuer den Artikel der ist echt gut:

Jedoch spricht er gleich am Anfang doch sehr fuer Renes sehr gute Idee

"Among the most dangerously unconsidered costs is what I've been calling
> complexity cost. Complexity cost is the debt you accrue by complicating
> features or technology in order to solve problems. An application that does
> twenty things is more difficult to refactor than an application that does
> one thing, so changes to its code will take longer. Sometimes complexity is
> a necessary cost, but only organizations that fully internalize the concept
> can hope to prevent runaway spending in this area."


Warum muss das .ts ALLES können?

Die vereinfachung in .tsu, .tsp, .tss und .tsc ist eigentlich die logische
Konsequenz fuer jeden der den Artikel auch bis zu Ende gelesen und einmal
genauer darueber nachgedacht hat.

Richtig; Alle die bisher nur .ts geschieben haben muessen ggf ihre
Extensions abändern - ist unbequem aber langfristig gesehen zahlt sich das
aus da ihr die Zeit die ihr in das ummodeln gesteckt habt schnell wieder
draussen habt, da Euer Code sich wesentlich einfacher wiederfinden und
strukturieren lässt.

Das .ts kann man im Grunde als ein

> "It's often subtle or intentionally hidden features that cost the most in
> the long term."


sehen, da es alles koennen muss und eventuell sogar noch viel mehr (eben
hidden feature ;-)

The first time you open a new section of code, you need to orient yourself.
> The fewer things the code does, the quicker this process. Even
> well-factored, well-written, clean code can take a while to become familiar
> with if it does a lot of things.


Ist der Code nur .tsu sprich User TYPOSCRIPT so ist es nur USER spezifisch
basta! Das ist wesentlich logischer und wesentlich eingaenglicher als ein
.ts das alles moegliche sein könnte.

Mit einem .tsu, tss, tsp, tsc liesen sich alle Files sehr gut auflisten von
a-z entsprechend dem Nutzen und man findet dann auch die Einstellungen
wesentlich schneller wieder die man im Template Analyzer ausgemacht hat. -
Das ist einfach und Logisch - ist doch gut oder?

If an area of your product has two toggles that interact, there are 4
> states (off-off, on-on, off-on, on-off) that must be tested and that must
> be understood when working through issues with customers. If it has three
> toggles, you have 8 states. Four makes 16. The third toggle added 4 states
> was probably just about as easy to spec and implement as the fourth toggle,
> which added an additional 8. The same is true of the sixth toggle, which
> adds 32 states. Again, "how hard would it be to add this toggle?" shows a
> lack of understanding of total costs. "How much more complicated does it
> get with this toggle?" gets us closer to the right discussion.


Read more:
http://www.firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider#ixzz2hD9y8jcC

Nehmt nun die alte bisherige Loesung mit den all inclusive 4 Bereichen

und vergleicht sie mit denen die Rene vorgeschlagen hat.

Software developers like challenges, and the challenge of building a
> complex system that serves up a simple interface is especially alluring.


VERY TRUE

aber noch wichtiger ist das folgende, das von sehr vielen Developern leider
ausser Acht gelassen wird.

Writing the lines of code is rarely the big cost in engineering: it's the
> understanding, the communication and the maintenance.


Wer einmal die Mailingliste nachschaut wird einige Beitraege finden aus
2004 - 2007 wo ich mit Schuelern TYPO3 Webseiten gebaut habe und die hatten
einen riesen Spass dabei. Wenn ich heute damit ankomme dann graut es denen
davor, da sie viel zu oft eben im Code stecken bleiben und mit anderen CMS
Loesungen wesentlich sc hneller und vorallem wesentlich verstaendlicher ans
Ziel gelangen.

Your best people can explain to a child everything that your organization
> does. Your worst people are the ones who sound smart and official at the
> expense of being widely understood.


Ich denke nach diesem Satz muesste hier eigentlich ein EINDEUTIGES Votum
fuer Renes SUPER Loesung geschehen.

Bitte denkt darueber alle noch einmal ueber Eure +1 fuer die Folder Loesung
nach, da diese alles nur komplizierter macht anstatt Dinge zu vereinfachen.

RENE DANKE FUER DEINEN VORSCHLAG! WEITER SO! Du hast folgendes ganz klar
erkannt:

Without keeping simplicity, you will never keep up with competitors who are
> trying to disrupt you.


Nun heisst es jedoch auch:

Make sure your whole team knows this.


Ich hoffe JEDER der hier kommentiert liest auch den von Georg benannten
Artikel bis zum Ende.
Dir Rene empfehle ich dich mit dem THEMES Leuten in Verbindung zu setzen
und dort schon einmal dein Konzept einzuarbeiten, denn die sind sehr an
USABILITY of TYPO3 interessiert!

Um TYPO3 wieder populaerer zu machen und die Abwanderung zu stoppen
brauchen wir leider noch mehr s Loesungen wie THEMES und die von Rene eben
vorgestellte TYPOSCRIPT Lösung.

Danke Rene!

(***** 5 STARS)




2013/10/9 Andreas Becker <ab.becker at web.de>

> >
> > getreu dem zukünftigen TYPO3 Motto: "convention before configuration"
>
>
> :-) Ich wuerde eher das Motto auf "Confusing but consistent" abändern.
>
> Einige Loesen es bisher mit Unterfoldern im Pagetree der mit einer Folder
> Struktur innerhalb fileadmin der ihrer eigenen Extension. Jedoch landen bei
> beiden Methoden schnell mal snippets in einem Falschen Fach. Mit einer
> eindeutigen Endung waere dem abgeholfen.
>
> Eine Convention wuerde Clarity bringen, doch das anscheinend nicht
> gewünscht. Deine Idee Rene ist aus paedaggischer Sicht SEHR sinnvoll, da
> auch ein Laie sofort sehen wuerde das da wohl ein File am falschen Platze
> ist. Aus Developer sicht sieht dies oft eventuell leider anders aus, da der
> in der Regel nicht will das ein Laie es so einfach hat!
>
> Bei TYPO3 geht es nicht wie bei Montessori "Hilf mir es selbst zu tun" zu,
> die Leute wie Page etc hervorbringen, sondern vielmehr wie in
> standardisierten Regelschulen aus denen auch u.a. Einstein mal flog ;-)
>
> Du hast jedoch vollkommen recht das der Zug abgefahren ist fuer deine Idee,
> ist TYPO3 6.2 erst einmal publiziert!
>
> Einen Nutzen den deine Idee auf jeden Fall vereinfacht , waere der Aufbau
> eines TYPOscript repositories, da diese .tsu, .tsp sofort und auch
> automatisch eingeordnet und innerhalb von TYPO3 aufgelistet werden könnten.
>
> Eventuell ist es ja sogar möglich, dass man dieses Repositry zentral
> verwaltet z.B. auf TYPO3.org oder THEMES und dann jeder dort eine
> ansammlung von erprobten Snippets findet die innerhalb von TYPO3 dann
> entsprechend ihrem Nutzen als User / Page / Setup oder Constants
> aufgelistet werden (aehnlich dem Extension Repository. In typo3conf oder
> auch fileadmin koennte man noch einen weiteren Ordner fuer all die Snippets
> anlegen die der jeweilige Develper fuer seine Seite aus dem Repository
> gezogen hat, wo er sie dann ggf noch individuell anpasst.
>
> Wie waere es Rene, wenn du einfach einmal wie ein kleines Repository mit
> deiner Convention aufstellst und dann fragst du auf der Englischen Liste
> nach! Ich koennte mir durchaus vorstellen dass es dort auf Gegenliebe
> Stößt, macht es doch TYPO3 mehr transparent und user friendly auch fuer
> Developer und Designer, die nicht die CODE Gurus sind!
>
> -1 bezueglich der Folder Lösung, denn die schliesst nicht aus, das ein user
> typoscript unerkannt in einem setup flder bzw ein setup im constant folder
> landet!
>
> +1 fuer Rene's Loesung denn die ist wesentlich besser und flexibler und vor
> allem wesentlich eindeutiger! - TRANSPARENT
>
> Ich koennte mir zudem vorstellen dass dein Konzept ein idealer Baustein
> fuer THEMES ist! Waere es nicht super man haette in TYPO3 eine Art
> eingebauten Website Builder?
>
> Starte die TYPO3 Base
> Baue dein Design aus Foltern, Feature, Content und Footer Bereichen
> Structuriere dein content
> Wähle dein Menu (genau das koennte aus so einem Repository stammen)
> Wuerze es mit Typscript snippets (Klare Strukturen wuerden hier Kosten
> reduzieren da man die entsprechenden Snippets schneller finden würde ;-)
> Erstelle den Content
> Fuege deinen Content ein
> Speichern nicht vergessen
> Entscheide was auf Mobile angezeigt werden soll und was nicht
> Fertig
>
>
> Liebe Gruesse
>
> Andi
>
>
> 2013/10/8 Ralf-Rene Schröder <ralf.rene at online.de>
>
> > Am 08.10.2013 10:58, schrieb Philipp Gampe:
> > > bernd wilke wrote:
> > >> ich benutze aktuell einen anderen Ansatz um die verschiedenen Bereiche
> > >> zu unterscheiden. page-TS kommt in eine eigenes Unterverziechnis und
> > >> wird mit seiten-uid und seitenname benannt, user-TS käme analog auch
> in
> > >> ein eigenes Verzeichnis.
> > >> dann habe ich auch ein Verzeichnis für extension-templates, die erst
> in
> > >> bestimmte Seiten eingebunden werden. ansnsten gibt es ...-constants.ts
> > >> und ...-setup.ts, nicht gerade kurz, aber deutlich gekennzeichnet
> > >
> > > +1
> >
> > ich merke schon das ich hier mit der Idee ziemlich allein da stehe...
> > bis jetzt habe ich es ja auch immer so gemacht
> > ich habe unterhalb meines Layout Ordners Unterordner für etwa
> > basics
> > page
> > extension01
> > extension02
> > ...
> > extensionXX
> >
> > in einem Extensionordner (neben nötigem html und css) dann files
> > setup.ts constants.ts pageTSconfig.ts und userTSconfig.ts bei Bedarf...
> > das einbinden muß aber dadurch alles immer file bezogen stattfinden
> > (denn ich will nicht ALLES zusammen in einen übergeordneteten TYP-Ordner
> > packen um Konfigurationen auch einzelner Extension problemlos
> > transferieren zu können und eben auch der Übersichtlichkeit halber)
> >
> > mit der neuen DIR Möglichkeit ab 6.2 könnte nun eine EINZIGE include
> > Zeile ausreichen alle Setup dateien eines kompletten Seitenbaums
> > recursiv zu inkludieren (egal wie sie dort verteilt sind, aber eben nur
> > wenn sie sich im filetype unterscheiden ... sonst wäre, nebenbei gesagt,
> > eigentlich diese filetype Angabe pro include Zeile ziemlich
> überflüssig)...
> > eine weitere für alle Constants Dateien, und so weiter...
> >
> > es mag sein das hierdurch jetzt auch weitere Probleme entstehen würden
> > (Ladereihenfolge etc.) aber ich werde das Gefühl nicht los das hier
> > trotz der Editor anpassungen (das macht man halt einmal) die Vorteile
> > überwiegen würden...
> >
> > Aber OK... es war ein Versuch zu sehen ob auch andere dies
> > nachvollziehen können... für mich alleine werde ich es wahrscheinlich
> > für die Zukunft dann so einrichten...
> >
> > DANKE für's Mitdenken...
> >
> > PS: war halt nur die Idee, diese Möglichkeit mit den filetypes
> > frühzeitig zu standardisieren, bevor jeder sein eigenes Süppchen kocht
> > (getreu dem zukünftigen TYPO3 Motto: "convention before configuration").
> >
> > --
> > image[FORMAT] - Ralf-René Schröder
> > http://www.image-format.eu ... Wir geben Ihrem Image das richtige Format
> > _______________________________________________
> > TYPO3-german mailing list
> > TYPO3-german at lists.typo3.org
> > http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
> >
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>