HP Design/Layout...

Janchu88

Kapitän zur See , HWLUXX Vize-Superstar
Thread Starter
Mitglied seit
29.11.2005
Beiträge
5.271
Ort
irgendwo im Nirvana...
Hi,

wie ich ja gut und breit bereits kundgetan habe werde ich für die Schule als Facharbeit im Thema Informatik einen Webshop erstellen...

PHP und SQL prügel ich mir derzeit gewaltsam rein aber mache gute fortschritte. Werde mir noch die feinheiten mit Sessions etc angucken, aber das soll hier net Thema sein.

Was mich interessiert... Wo bzw wann setze ich mit besten mit dem Layout ein?

Sollte ich erstmal alle Skripte etc funktionell soweit runtertippen etc und erst wenn das alles 100%ig steht mir gedanken um design und layout machen, oder wäre es gut sich da jetzt schon gedanken drüber zu machen? Und was brauch ich dafür eigentlich alles, Javascript, CSS, "$?" ?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hi,
wann du mit dem Layout anfaengt ist ganz dir überlassen.
Solltest du zb eine Template Engine verwenden, was bei einem Shop System anzuraten wäre, dann kannst du das Layout sozusagen ganz zum schluss machen.
An Programmier bzw script oder sonstigen sprachen brauchst du fuers layout eigtl nur html und css. JS brauchst du eigtl nur wenn du einige sachen dynamisch gestalten möchtest oder was weiß ich.

Falls du nicht weißt was eine Template Engine ist:
Eine Template Engine trennt den HTML Code vom php script. Wenn du zb eine php seite hast z.b. so:
PHP:
echo "bli bla blubb";
echo "tabelle hier";
echo $fobar;
echo "und noch ne tabelle";
while bla bli blubb
konntest du das mit einer template engine folgender maßen trennen:
PHP:
$tpl->assign("foobar", $fobar");

while ....
und das template:
PHP:
bli bla blubb
tabelle hier
{$fobar}
und noch ne tabelle
.
.
.
damit trennst du eigtl ganz gut den anzeige code von der logic und kannst später das design einfacher anpassen.
 
also brauch ich mir erstmal keine gedanken darüber machen die php skripte auf ein bestimmtes layout hin zu optimieren?
 
nun ja das kommt drauf an wie du programmierst. WEnn du ne template engine nutzt, dann eigtl nicht, da musst du halt nur die variablen schonmal "assignen" die du dann später in deinen templates anzeigen willst.

andernfalls wäre es ratsam das design schon fertig zu haben, da du sonst sehr viel im code herrumfuschen musst.
 
nun ja das kommt drauf an wie du programmierst. WEnn du ne template engine nutzt, dann eigtl nicht, da musst du halt nur die variablen schonmal "assignen" die du dann später in deinen templates anzeigen willst.

andernfalls wäre es ratsam das design schon fertig zu haben, da du sonst sehr viel im code herrumfuschen musst.

wäre dir sehr verbunden wenn du näher auf den begriff assignen eingehen würdest ;)
 
rofl okay... wenn du eine template engine nutzt, dann schreibst du in einem template um auf eine variable zu zugreifen einfach ein {$meine_var}
damit die template engine aber weiß, was in diesem lückenfüller stehen muss, assigned man die ;) das kommt dann ganz auf die template engine an. Bei Smarty geht das zb folgender maßen:
$smarty->assign("meine_var_im_tpl", "der wert hier soll drinn stehn");

MfG
Alex
 
Also für so ein Schulprojekt würde ich mir die CSS-Datei irgendwo klauen oder von soner Seite holen die den Kram umsonst anbietet. Spart ne Menge Arbeit, vor allem wenn du eh ziemlich für den Mülleimer produzierst ;-)
CSS ist nämlich nicht ganz so einfach und ein Shop muss ja schon einiges reißen.
Gerade mal bei Google geguckt: http://css.roob.dk/ gefunden. Würde mir sowas holen und dann einfach abändern, wies dir gefällt/Bedürfnisse sind.
 
Hi Janchu, bin gerade auf diesen Thread gestoßen. Auch wenn das Thema nicht mehr aktuell ist, möchte ich gerne der Vollständigkeit folgendes anmerken was vielleicht für den ein oder anderen der auf diesen Thread stolpert interesannt sein könnte.

Erstmal stimme ich generell (bis auf wenige Details) mit dem von Nascar vorgetragenen überein.

Es sollte aber IMHO nach dem MVC-Pattern designt werden.
OK, mag für ne kleine HP over engineered sein aber wenn das Projekt weckst, dann wird man es bereuen wenn man sich nicht danach gehalten hat ;)

Auf eine Internet-/Appliation/HP übertragen wäre:
  • das Model eine Abstraktion über die DB. Wobei man sich da nicht selber eine Abstraktion schreiben sollte (das intern mit rohes SQL verwendet), sondern ein ORM (Object Relational Mapper) benutzen sollte.

    Vorteil:
    • Gute ORMs unterstützen dabei verschiedene Datenbanken, so das man nicht gegen verschiedene Datenbanken programmieren muss. Der ORM übernimmt dabei im Hintergrund die Arbeit für einen. Der Vorteil ist klar darin zu erkenne das man nicht nur auf eine Art von Datenbank gebunden ist ;)
    • Ein anderer Vorteil ist, das eben bei einem ORM eine gegebenes Schemata auf echte Objekte abgebildet werden. Dabei entspricht eine Tabelle einem Objekt und Exemplare dessen einem Datensatz. Beziehungen unter dern Objekten lassen sich auch beschreiben.
    • Das hinzufügen von Datensätzen ist viel leichter da nur noch jeweilige Exemplare von Objekten erzeugt werden müssen die je nach Einstellung automatisch oder selbständig in die DB über das ORM hinzugefügt werden. Es brauchen dabei keinerlei Referenzen auf selbst erzeugte Exemplare gehalten werden ;)
    • Das quering bei guten ORMs kann sehr mächtig sein und steht echten SQL-Statements im nichts nach.
    • Auf aus einem query zurückgegeben Exemplare kann nicht nur lesend sondern auch Modifizierend zugegriffen werden. Modifikationen können dabei auch je nach Einstellung Automatisch oder selbständig in die DB über den ORM geändert werden.
    • Letztendlich braucht man durch ein ORM nicht mehr mit einer flachen Struktur zu hantieren, sondern kann "dreidimensional" auf Daten zugreifen bzw. abbilden.

    Falls man noch mehr Abstraktion wünscht, bieten viele ORMs nicht nur die Möglichkeit die DB über Schemata plus Mapping auf Objekte zu beschreiben, sondern auch auf eine Deklarative weise die nur mit Objekten und dessen Beziehungen untereinander auskommt. Das Schema wird dabei selbständig durch den ORM erzeugt :)
  • die View, wäre dabei halt 1) der Browser der das rendering anzeigt und Benutzereingaben entgegennimmt und an den Controller weiterleitet, 2) das/die template(s)[/d] die ein vom Controller gegebenen Kontext rendern.

    [*] der Controller ist dann das eigentliche Herz des ganzen Systems.
    Der Controller ist dabei für folgendes zuständig:
    • Er nimmt Benutzereingaben von der "View" (Also in diesem Kontext vom den vom Browser, z.B. durch forms, GET, POST, ...) entgegen und wertet sie aus.
    • Anhand ausgewerteten Benutzereingaben werden entweder:
      • Datensätze in er DB aktualisiert und (Optional) die View aktualisiert in dem ein passendes template mit einem Kontext aufgerufen wird.
      • Datensätze in der DB ausgelesen und anschließend ein passendes template mit einem Kontext aufgerufen und die "View" aktualisiert.
      • Oder nichts gemacht (Was eher unwahrscheinlich ist)
      • Oder sontige logistische aufgaben...


Wie man sieht ist es Sinnvoll nach dem MVC-Pattern zu strukturieren da man auf dauer gesehen bzw. bei wachsender Größe des Projektes ein sehr Wartbares System erhält :)

Noch was:
Wie man sieht ist der Controller für die eigentliche Logic zuständig. Aber(!) gute template languages erlauben zusätzlich Fallunterscheidungen (if/else- statement) und auch iterationen (for-statement) um die gelieferten Daten weiter aufzubereiten ;) Auch erlaubt mir eine gute template languages für wiederkehrende Sachen kurze Macros/Funktionen zu definieren (Siehe PHP :d) und stellt auch eingebaute Funktionen zur Verfügung ;) -- Wie dem auch sei, man sollte so wenig wie möglich Logic in die templates implementieren aber mehr als nur das substituieren von Platzhaltern (Template variables=Kontext) sollte man dennoch nutzen. Fallunterscheidungen und Iterationen finde ich z.B. sehr gut, da man z.B. das einzeigen einzelner Abschnitte davon Abhängig machen kann ob ein Platzhalter gesetzt ist. Wichtig ist, dass das tempalte nicht als zweites PHP mutiert und dadurch eben zuviell Logic implementiert wird ;)

Eine Template Engine trennt den HTML Code vom php script. Wenn du zb eine php seite hast z.b. so:
Du weißt aber schon das PHP ursprünglich eine Template Engine war?!! :d *SCNR*
 
ja weiß ich, nur ne template engine auf php basierend vereinfacht die kacke noch mal :P
 
hab diesen thread hier schon komplett vergessen...

Inzwischen hab ich mich für C# in ASP.Net mit Mysql Connectior für Ado.net und nen Mysql 5.0 Server entschieden. ;)

Hab halt von null aus angefangen, aktuell siehts so aus:

http://s2.directupload.net/file/d/1428/mtgcmtn8_jpg.htm

Warenkorb ist auch schon am funktionieren, muss aber nochmal überarbeitet und fertig gestellt werden. Danach folgt noch der Login, eine Anmeldeseite und ein wenig statischer Kram.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh