Ergebnis 1 bis 9 von 9

Thema: Zend_Crypt?

  1. #1
    Erfahrener Benutzer Avatar von SRIT
    Registriert seit
    12.02.2007
    Ort
    Hude (Oldenburg)
    Beiträge
    359
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard Zend_Crypt?

    Hallo,

    ich habe im ZF 1.8.0alpha ne Paket namens Zend_Crypt gefunden, weiß einer was man damit anfangen kann/soll?
    simple is good... simpler is better!

  2. #2
    Erfahrener Benutzer
    Registriert seit
    26.12.2006
    Beiträge
    246
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Schau mal hier vorbei, Stefan:
    http://framework.zend.com/wiki/pages...n?pageId=35309

    Schau mal noch bei deinen PNs rein, du hast Post!
    Gruß Dino
    Eclipse PDT Hilfe benötigt
    http://www.zfforum.de/17084-post74.html
    Danke!

  3. #3
    Erfahrener Benutzer Avatar von ice-breaker
    Registriert seit
    29.03.2008
    Ort
    Steinbach/Taunus
    Beiträge
    1.862
    Thanks
    0
    Thanked 9 Times in 5 Posts

    Standard

    Finde ich nur einen sehr schlechten Entwurf, ich hatte auch an einem Zend_Crypt Entwurf gearbeitet, aber als Padraics angenommen wurde habe ich es dann sein lassen.
    Dieser Entwurf ist viel zu speziell auf die beiden fehlenden Features, ein genereller Entwurf für Hashing und Ver/Entschlüsselung wäre deutlich angebrachter gewesen, so wird es irgendwann nen Bruch der BC geben, wenn man noch solche Features reinbringt.
    Und nebenbei hat er seinen Proposal nicht erfüllt, denn er sprach davon, dass er auch reine PHP-Implementierungen machen wollte, womit es als Zf-Komponente sinnvoll wäre, dies hat er jedoch nun gestrichen und seine Klasse ist nur noch ein Wrapper um die nativen PHP-Funktionen, finde ich einen sehr traurigen Fall, dass es so in den Core aufgenommen wird und Dinge wie Zend_Image abgelehnt werden, da sie nur Wrapper seihen und keine eigene Funktionalität haben.
    "Die Wahrheit entgeht dem, der nicht mit beiden Augen sieht." -Orici

  4. #4
    Moderator Avatar von thomas
    Registriert seit
    16.12.2006
    Beiträge
    1.350
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Hängt auch immer davon ab wie der Proposer hinter seinem Proposal steht.
    Padric hat seit einiges Monaten nichts mehr gearbeitet und Zend_Crypt wurde nur aufgenommen weil es für eine bestimmte Komponente benötigt wird.
    Mfg
    Thomas Weidner
    I18N Team Leader, Zend Framework
    Wir schwarzen Schafe sind die heimlichen Herrscher der Welt... unser schwarzer Humor ist unsere beste Waffe
    www.thomasweidner.com

  5. #5
    Erfahrener Benutzer Avatar von SRIT
    Registriert seit
    12.02.2007
    Ort
    Hude (Oldenburg)
    Beiträge
    359
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Hmm wie ist denn das gemeint, dass die nativen Sachen nicht genutzter werden sollen? Würde denn Zend_Config_Ini auch darunter zählen, weil ja an sich parse_ini_file auch als Wrapper genutzt wird. Und es wäre sicher möglich sowas mit PHP Mitteln zu lösen (von der Perf. mal abgesehen)...
    simple is good... simpler is better!

  6. #6
    Erfahrener Benutzer Avatar von ice-breaker
    Registriert seit
    29.03.2008
    Ort
    Steinbach/Taunus
    Beiträge
    1.862
    Thanks
    0
    Thanked 9 Times in 5 Posts

    Standard

    Neija die Leute vom Zf haben in den Proposals schon mehrmals vermerkt, dass sie keine Klassen möchten, die einfach nur native PHP funktionen wrappen.
    Also eine Image-Klasse deren Methoden einfach nur die gdlib Aufrufen ohne groß etwas selbst zu machen.

    Zend_Config macht ja doch schon einiges, denn parse_ini gibt nur nen Array zurück, hat keine Vererbung, keine Sections, dann gibt es keine save_ini-Funktion usw.
    "Die Wahrheit entgeht dem, der nicht mit beiden Augen sieht." -Orici

  7. #7
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Ausserdem ergibt sie zusammen mit Zend_Config_Xml einer Vereinheitlichung der Schnittstelle, ist auch nicht ganz unerheblich

  8. #8
    Erfahrener Benutzer Avatar von SRIT
    Registriert seit
    12.02.2007
    Ort
    Hude (Oldenburg)
    Beiträge
    359
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Joa gut, mir ist halt grad kein anderes Beispiel eingefallen. Nur wie soll man sonst mit Bilddateien umgehen um mal beim Beispiel zu bleiben? Wenn man jetzt den Treiber wählen könnte (ImageMagick, GD, Cairo, Ming) etc. wär das wieder was anderes? Im Grunde kann man ja nur die zur verfügung stehenden Funktionen nehmen oder versteh ich diese Diskussion immer noch net ganz?
    simple is good... simpler is better!

  9. #9
    Erfahrener Benutzer
    Registriert seit
    28.12.2006
    Beiträge
    9.966
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard

    Im Grunde kann man ja nur die zur verfügung stehenden Funktionen nehmen oder versteh ich diese Diskussion immer noch net ganz?
    Grundsätzlich wird man -- möchte man die Probleme effizient lösen können -- nicht um native (C) Funktionen herumkommen. Mal abgesehen davon, dass ich Wrapper nicht grundsätzlich schlecht finde, zB um ansonsten alleinstehende, zusammengehörige Funktionen auch wirklich zusammen zu fassen, find ich es auch schwierig zu sagen, wann ein Wrapper noch ein Wrapper ist. Ist zum Beispiel sowas noch ein Wrapper?
    PHP-Code:
    class String {
      protected 
    $_s;
      public function 
    __construct ($s) { $this_s $s }
      public function 
    substring ($a$b) {
        
    $this->_s substr ($this->_s$a$b);
        return 
    $this;
      }

    Ich finde es ist aber immer eine gute Idee ähnliche Zweck unter gleicher Schnittstelle zu vereinen, so sind sie sehr leicht austauschbar.

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •