Sponsor-Board.de

Hallo liebe SB-Gemeinde,

ich möchte mich mit einer kleinen Diskussionrunde einbringen, da ich aufgrund meiner Erfahrung in einer kleinen Softwareschmiede und dem Studiums in angewandter Informatik momentan mit der Frage beschäftige:

Was wäre wenn die Webentwicklung zunehmends an die Softwareentwicklung angelehnt wäre?

In genaueren Grundzügen würde ich die darstellende Oberfläche eines Browsers gerne zusammenfügen.
Die darstellende Schicht setzt sich zusammen aus meistens HTML und PHP, um das Ganze etwas dynamischer wirken zu lassen.
Was wäre, wenn man dies nun zusammenführt, sprich für PHP Klassen vordefiniert, deren Anzeige im Browser normaler HTML-Code ist, jedoch rein mittels PHP geschrieben ist? Angelehnt an eine Entwicklung wie z.B. mit Java.
Wie sieht dort die Entwicklung einer GUI aus?

Code:

JButton btn = new JButton("Hallo Welt");

Umgeändert in die Browserwelt, wären wir hier bei einem

Code:

<input type="button" value="Hallo Welt" />

<button>Hallo Welt</button>

Wieso nicht auch hier den Ansatz wagen: Ich erstelle ein PHP-Framework mit solchen teils vordefinierten Klassen á la new Button("Text") und kann anhand derer ihre Attribute festlegen, Minimum-Größe, Minimum-Breite usw.

Klar, eine Komponente allein macht eine Seite nicht genial.
Wie sähe dies im Verbund aus?

Code:

<div style="float:left; min-width:500px">

    <input type="button" value="Test" />

    <div style="float:left:">

         <span>Testetikierung</span>

    </div>

    <div style="float:left">

          <img src="gadsg.jpg" />

    </div>

    <div style="float:none">

            Blablub

    </div>

</div>

In Java wiederum sähe solch ein Komponentenverbund anders aus. Hierbei werden die einzelnen Komponenten einfach in einen Layoutmanagergepackt:

PHP-Code:

JPanel pane = new JPanel();
JButton btn = new JButton();
BorderLayout layout = new BorderLayout();
pane.setLayout(layout);
pane.add(btn, BorderLayout.TOP); 

Ich weiß, solch eine objektorientierte Vorgehensweise zur Webentwicklung klingt übertrieben, kann aber auch starke Erleichterungen mit sich bringen, wenn es in Richtung Webentwicklung geht.

Was haltet ihr von solch einem "Framework", rein zur Entwicklung von einer GUI abgesehen von der Arbeit, die dahinter steckt? Fändet ihr so etwas sinnvoll?

Naja ich kann deine Idee zwar nachvollziehen, würde es jedoch nicht machen. Objektorientiertes Programmieren ist zwar der Traum, jedoch macht es in Verbindung mit PHP in meinen Augen nicht allzuviel Sinn. Da objektorientierte Programmierung langsamer ist wie die prozedurale Programmieren (Objekte anlegen usw dauert) ist sind wir schon beim ersten Nachteil. Auf dem Weg zwischen Server und Clienten verliert man schon sehr viel Zeit, jedoch der User möchte alles sofort haben. Also ich sags mal so in Java oder C# am Desktop hast du die notwenigen Ressourcen dafür, da es für den User keinen unterschied macht ob das jetzt 10ms oder 11 dauert. Weiters wenn man objektorientiert Programmiert, macht man vieles umsonst. So wird man zb ein Objekt anlegen was dann einen bestimmten Output bringt, welcher aber eigl immer statisch ist, sprich -> du berechnets obwohls nicht nötig wäre, weil auf jeder Website gibts Elemente die immer gleich sind.

Den zweiten Nachteil welchen ich mir jetzt überlegt habe ist, dass ja die Objekte nach dem Aufruf der Seite verloren gehen -> sprich du hast den Aufwand fürs Anlegen der Objekte für genau einen Output gemacht und dann alles wieder über den Haufen geworfen.

Ich habe mir das jetzt so ausgedacht und hoffe du kannst es nachvollziehen. Falls hier was nicht stimmt belehre mich bitte eines Besseren Wink

MFG
Moser Michael

Solche Ansätze werden ja bereits teilweise verwendet, z.B. für die dynamische Generierung von Formularen. Das bringt bestimmte Vorteile mit, wie z.B. eine automatische Validierung je nach Feldtyp usw. Habe ich so oder so ähnlich schon öfters im Netz gelesen und werde ich auch so umsetzen. Für alle HTML-Elemente ... nein, würde ich nicht machen.

Also ich bevorzuge ja eine Trennung von Design und Code so stark wie möglich. Deshalb generiere ich meist auch keine WPF-Elemente per C#, sondern definiere sie in XAML.

Ansonsten generell OOP ja, aber nur begrenzt. OOP-Ansätze bei der Arbeit zwischen HTML und PHP, wenn es net nur ums direkte Generieren von Elementen geht, wie ich das auch bei WPF mache, finde ich auf jeden Fall gut.

Dennis schrieb:

Was wäre wenn die Webentwicklung zunehmends an die Softwareentwicklung angelehnt wäre?

Webentwicklung ist ein Sub Bereich von Software Entwicklung. Also ist es das schon Wink

Dennis schrieb:

In genaueren Grundzügen würde ich die darstellende Oberfläche eines Browsers gerne zusammenfügen.
Die darstellende Schicht setzt sich zusammen aus meistens HTML und PHP, um das Ganze etwas dynamischer wirken zu lassen.
Was wäre, wenn man dies nun zusammenführt, sprich für PHP Klassen vordefiniert, deren Anzeige im Browser normaler HTML-Code ist, jedoch rein mittels PHP geschrieben ist? Angelehnt an eine Entwicklung wie z.B. mit Java.
Wie sieht dort die Entwicklung einer GUI aus?

Code:

JButton btn = new JButton("Hallo Welt");

Also den Weg, den ASP.NET mit seinen HtmlControls geht? Prima Idee. Verwende ich seit mehreren Jahren so (habe diesbezüglich ein Framework geschrieben). Ist zwar anfangs langwieriger. Aber wenn man am Ende nur noch folgendes für eine Tabelle schreiben muss, weiß man es auch zu schätzen.

PHP-Code:

$data = FooModel::GetCollection();
$table = new Table($data);
$table->SetHeader(0, 'Test');
$table->SetHeader(1, 'Test2'); 

Gibt keine bessere Möglichkeit selbst in der View noch einmal die direkte Presentation mit dem Presentation Controller zu trennen. -> Wartbarkeit wesentlich besser!

moser96 schrieb:

Sehe ich anders. Die Produktivität und Wartbarkeit die du durch OOP erhälst sind tausend mal mehr wert, als der minimalistische Nachteil des Overheads.

Vielleicht nicht bei einem 1000 Zeilen Projekt. Bei 10.000 Projekt Dateien, wird man es jedoch schon eher bemerken Biggrin

Spätestens wenn dann Refactoring ansteht. Mit einer richtigen IDE wie PHP Strom dann keine große Sache mehr.

Außerdem: Was kostet derzeit eine sehr gute Server CPU? 1000 €? Reicht die nicht, dann halt noch eine 2. rein. Immerhin günstiger als die Wochen Mehraufwand des Entwicklers.

Die meiste Zeit verstreicht im übrigen bei IO und Datenbank Operationen. Bekannter maßen können viele Entwickler auch nicht richtig mit Indizies in der Db umgehen oder haben noch nie etwas von Caching (Memcache) oder Paralel Threading (PThreads) gehört.

Außerdem gibt es ja noch OP-Code Cache oder HVVM.

Wenn Zeit wirklich so kritisch ist, sollte man lieber gleich die Website in C++ schreiben.

moser96 schrieb:

Den zweiten Nachteil welchen ich mir jetzt überlegt habe ist, dass ja die Objekte nach dem Aufruf der Seite verloren gehen -> sprich du hast den Aufwand fürs Anlegen der Objekte für genau einen Output gemacht und dann alles wieder über den Haufen geworfen.

Objekte gehen nicht verloren. Lediglich Referenzen. Dafür gibt es die magischen Methoden __sleep und __wakeup in Verbindung mit Session oder serialize()

Klar, ein großer Nachteil von PHP ist die Zustandslosigkeit. Aber wenn man die braucht, sollte die Website auf .Net (Oder Java oder C++) laufen.

@Topic:
Ja, du solltest wenn immer möglich auf Html Controls statt auf direkte HTML Ausgaben setzen.

P.S: Sorry für den Roman Biggrin

Stimme dem was GGSeSports sagt im Großen und Ganzen zu.

Klar man findet Gegenargumente aber für mich, auch wenn ich es so in der Form noch nicht einsetze, klingt es auf jedenfall vielversprechend.

Code:

$data = FooModel::GetCollection();

$table = new Table($data);

$table->SetHeader(0, 'Test');

$table->SetHeader(1, 'Test2');

Sowas ist definitiv sehr nice! Besser als das man hingeht, eine HTML-Template-Datei erstellt und dann erst mal die Hülle für die Tabelle schreibt, die man dann auch noch mit den Variablen und Schleifenlogik bestücken muss. Man hat nochmal eine Zwischenebene die man für alles, das sie benutzt, manipulieren kann. Die generierte Tabelle soll eine bestimmte Klasse erhalten? Kein Problem, einmal den Code der Klasse ändern und alle Tabellen sind angepasst. Ansonsten müsste man alle HTML-Templates einzeln bearbeiten. Man vermeidet redundaten Code (oder allgemeiner Informationen): Man schreibt einmal die Klasse und erweitert sie für alles was zusätzlich an Funktionalität benötigt wird. Ohne das noch einmal wo anders tun zu müssen. Langsamer muss es dabei auch nicht werden, wenn man z. B. das Zusammenbauen einer Tabelle im Code mit Klassen und Methoden von einer Template-Engine zu HTML+PHP-Code rendern lässt und dann cached.

Klar ein bisschen Performance geht ggf. verloren aber wie GGSeSports schon sagte: Die bessere Wartbarkeit und Erweiterbarkeit des Codes wiegt schwerer.

Nachteile: Zusätzlicher Lern- und Konfigurationsaufwand und es musst natürlich erstmal so ein Framework erschaffen werden. Man darf sich auch nicht zu sehr blenden lassen von den vermeintlichen Vorteilen. Beispiel der Code oben: Das Model muss zuvor konfiguriert werden, was hier übergangen wurde. Man wird wahrscheinlich festlegen müssen, welche Attribute überhaupt in die Tabelle sollen. Was, wenn man nicht einfach nur eine Tabelle will, sondern eine mit Extras? Dann wird es komplexer. Man muss für vieles die Table-Klasse bearbeiten, man ist darauf angewiesen, dass sie flexibel ist. Und dem Frontend-Entwickler, der von PHP keine Ahnung hat (gut, vielleicht unwahrscheinlich), ist nicht geholfen, wenn man seine HTML-Templates wegzaubert.

Tja mal abwarten wo sich der Mainstream in den nächsten Jahren hinbewegt, wird jedenfalls sicherlich spannend. Dennis wenn du vorhast ein PHP-Framework zu entwickeln mit dem man alle gängigen HTML-Elemente abdeckt: Überleg es dir gut. Gibt es so etwas schon? (Garantiert) Wie gut sind die bestehenden Sachen? Wie viel Anklang finden sie? Etc.

Sowas in der Art haben wir auch beim dynao CMS gemacht : [Link: Registrierung erforderlich]

Also z.B. ne Form Klasse, die wie folgt ein Formular mit Auswertung erstellt (hier noch mit der lang-Klasse) und das auch direkt in die DB schreibt - auch hinzufügen geht darüber:

PHP-Code:

$form = form::factory('user','id='.$id,'index.php');

    $field = $form->addTextField('name', $form->get('name'));
    $field->fieldName(lang::get('name'));
    $field->autofocus();

    $field = $form->addTextField('email', $form->get('email'));
    $field->fieldName(lang::get('email_adress'));
    $field->addValidator('notEmpty', lang::get('user_email_empty')); // Optionale Validierung
    $field->addValidator('email', lang::get('user_wrong_email')); // Optionale Validierung

    if($form->get('password') != $form->sql->getValue('password')) {
        $password = userLogin::hash($form->get('password'));
    } else {
        $password = $form->sql->getValue('password');
    }

    $field = $form->addTextField('password', $password);
    $field->addValidator('notEmpty', lang::get('user_password_empty')); // Optionale Validierung
    $field->fieldName(lang::get('password'));
    $field->setSuffix(lang::get('password_info')); // Optionaler Suffix

    if($action == 'edit') {
        $form->addHiddenField('id', $id);
    }

    if($form->isSubmit()) {

        if($form->get('password') != $form->sql->getValue('password')) {

            $form->addPost('password', userLogin::hash($form->get('password')));

        }
    
    }

    echo $form->show(); 

Das ganze hier (weiter unten auch die Tabellen-Klasse) :
[Link: Registrierung erforderlich]

Fazit
Ich finde solche Klassen echt hilfreich, erleichtert einiges ... durch nen autoloader werden dann auch nur die benötigten geladen und dann auch gecached - noch nen Vorteil.
Auch grade wenn andere das System für Addons nutzen, hilft das - so bleibt ne Struktur vorhanden.

Von der HTML Ausgabe ist dies - ohne ganz viele unnötigen Funktionen - nicht Zoo variabel, was aber bei einem eh vorausgesetzten Design nicht von Nöten ist.

Eine einfach HTML Ausgabe ohne weitere Vorteile, wie bei deinem Button, ist nicht sinnvoll.

Der Gedanke spielt sich auch nicht um einzelne Komponenten sondern um ganze Komponentenverbunde, die man dann auch mittels Layoutmanagementklassen leicht positionieren könnte.

Mein Gedanke zielt nur darauf ab, erstens den Umstieg von wirklichen objektorientierten Sprachen in die Internethochburg zu erleichtern, aber auch die Effektivität in der Entwicklung, die durchaus durch solche Sachen gegeben sind, da man nur noch die Komponenten sozusagen "reinsteckt" und die Positionieren und Verwaltung vom Framework her übernommen wird.

Jep. Richtig. Kannst ja eine Basis Klasse zu jedem Control haben die dann für jedes Control bestimmte Eigenschaften und Methoden bereitstelt. Zb:

PHP-Code:

$container= new FooContainer(); //Geerbt von HtmlContainerBase
$control = new FooHtmlControl() //Geerbt von HtmlControlBase
$control->FloatLeft();
//$control->Display(EndpointType::FrontEnd);
$control->Assign($container);
$container->Display(EndpointType::FrontEnd) 

Wie gesagt, ich würde es unbedingt auf die Objekt Orientierte Weise machen (Wie du eingangs erwähnt hast). Prozeduale Entwicklung ist meiner meinung nach Old Shool.

Edit:
Gibt dann auch andere Interessante Ansätze (z. B. der Composer Pattern):

[Link: Registrierung erforderlich]

Edit 2:

simon_s schrieb:

Und dem Frontend-Entwickler, der von PHP keine Ahnung hat (gut, vielleicht unwahrscheinlich), ist nicht geholfen, wenn man seine HTML-Templates wegzaubert.

Das muss nicht unbedingt sein:

PHP-Code:

<?php
namespace Cms\Core\Controller;

use Cms\Core\System;

/**
 * Controller View
 * @package Cms\Core\Controller
 */
class View
{
    /**
     * Das zu verwendente Template
     * @var string
     */
    private $_templatePath = '';

    /**
     * Enthält Variablen die in das Template eingefügt werden sollen
     * @var array
     */
    private $_ = [];

    /**
     * Erstellt eine neue View
     * @param $templatePath string
     */
    public function __construct($templatePath)
    {
        $this->_templatePath = $templatePath;
    }

    /**
     * Ordnet eine Variable einem bestimmten Schlüssel zu.
     * @param $key string
     * @param $value object|string
     */
    public function Assign($key, $value)
    {
        $this->_[$key] = $value;
    }

    /**
     * Parst das Template und gibt das Ergebnis als String zurück
     * @param string $endpointType
     * @param string $design
     * @return string
     */
    public function LoadTemplate($endpointType = null, $design = null)
    {
        //Endpoint Typ automatisch setzen, wenn noch nicht vorhanden
        if ($endpointType === null) {
            $endpointType = System::$App->EndpointType;
        }

        //Design automatisch setzen, wenn noch nicht vorhanden
        if ($design === null) {
            $design = System::$App->Design;
        }

        //Versuchen, Template aus Standard Pfad zu laden
        $templateFile = DIR_TEMPLATE . '/' . $endpointType . '/' . $design . '/Markup/' . $this->_templatePath . '.php';
        if (file_exists($templateFile)) {
            ob_start();
            require($templateFile);
            return ob_get_clean();
        }

        //Fehler zurückgeben
        return 'System Error: Template (' . $this->_templatePath . ') for Endpoint "' . $endpointType . '" not availible in Design "'. $design .'"! This may not happen!';
    }

    /**
     * Liefert ein bestimmtes Template
     * @param string $templatePath
     * @param string $endpointType
     * @return string
     */
    public static function GetTemplate($templatePath, $endpointType = null) {
        $view = new self($templatePath);
        return $view->LoadTemplate($endpointType);
    }
}
?>

PHP-Code:

$view = new View('Base/Paragraph');
$view->Assign('Content', 'Lorem Ipsum...');
echo $view->LoadTemplate(); 

Template könnte dann so aussehen:

Code:

<p><?= $this->_['Content']; ?></p>

Natürlich könnte es neben den "HTML Element" Classen auch komplette "Controlls" geben ala: Forumular (Mit samt Inputs), Bildergalerie (Beschreibung etc. pp), Kontaktforumular.

Die Frage ist immer wie generisch man es haben möchte. Super generisch heißt halt auch wirklich, dass der Designer CSS zu 100% begriffen haben muss, um ohne div Suppe eine Website nur aufgrund der Semantik darzustellen.

Wenn man einen Designer hat, der dies nicht behrscht, oder es technisch nicht möglich ist die Semantik zu der gewümschten Darstellung zu führen, dürfen die "Controlls" halt nicht ganz zu generisch sein. Die Mischung machts.

Ja ok klar wenn man dann doch wieder HTML-Templates noch hat, logisch. Ich hatte Dennis jetzt so verstanden dass er darauf komplett verzichten möchte und nur noch PHP-Code vewenden will.

@Aaron

Zitat:

Auch grade wenn andere das System für Addons nutzen, hilft das - so bleibt ne Struktur vorhanden.

Ein sehr gutes Argument. Wenn man wie ihr ein Open Source CMS schreibt mit dem ausdrücklichen Wunsch, dass Dritte dafür eigene Erweiterungen entwickeln, dann kann das definitiv zur Vereinheitlichung und Durchsetzung von Richtlinien dienen. Bsp: Formulare senden immer in einem versteckten Feld den Zeitpunkt ihres Renderings mit. Wenn ein Entwickler ein neues Formular mit HTML erstellt muss er sich darum dann selber kümmern, er weiß es vielleicht gar nicht, er vergisst es oder ist schlicht zu faul. Aber wenn es eine Form-Klasse gibt dann kann man das dort schon einbauen und der Entwickler benutzt es automatisch.

Dennis

moser96

Ringelnatz

Schwester Wombat

GGSeSports

sic_

Aaron

Dennis

GGSeSports

sic_