Seite 1 von 1
Prüfung auf XHTML/Typkonvertierung bei getProperty
Verfasst: Do 2. Feb 2006, 15:42
von Stefan_Br
Ein NAchschlag zum Thread
http://contenido.org/forum/viewtopic.ph ... 2A&start=0, der leider geschlossen ist:
In der Datei front_content.php ist das Problem, dass die Abfrage der xhtml-Einstellung nicht richtig funktioniert noch nicht behoben.
Entsprechend wird das <base>-Tag immer in xhtml-Syntax ausgegeben.
Auch hätte ich einen Verbesserungsvorschlag für die Art, wie der Fehler in functions.con2.php behoben wurde.
Das ursprüngliche Problem lag doch im Missverstehen der automatischen Typkonvertierung von PHP:
Die Funktionen zur Property-Abfrage geben ja immer Strings zurück, werden die dann mit einem bool verglichen, werden sie auch nach bool gewandelt; wird aber ein String nach bool gewandelt, kommt am Ende immer true raus, es sei denn, der String war ein Leerstring. Folglich kommrt auch true raus, wenn der String 'false' lautete.
Natürlich kann man wie in der Korrektur in functions.con2.php für diesen Fall einfach eine explizite Typumwnadlung voranstellen. Kürzer und übersichtlicher wäre es aber, wenn man den Rückgabewert einfach mit dem String 'true' vergliche:
Vielleicht könnte man auch, um solche Fehler künftig zu vermeiden, in der getEffectiveSetting() und den entsprechenden getProperty()-Methoden der Objekte am Ende vor der Rückgabe auch eine Explizite Typwandlung vornehmen für den Fall, dass das Ergebnis 'true' oder 'false' ist.
Verfasst: Fr 3. Feb 2006, 18:55
von emergence
hatte ich mir auch schon mal überlegt...
vernünftige vorgehensweise wie das gehandled werden soll ???
ich verschiebs nach development...
Verfasst: Fr 10. Feb 2006, 20:14
von Stefan_Br
Falls Du die explizite Umwandlung in den getProperty-Funktionen meinst:
zum Beispiel am Ende der entsprechenden getProperty-Funktionen so:
wenn da jetzt z.B. steht:
stattdessen sowas:
Code: Alles auswählen
if($ergebnis == 'true'){$ergebnis= true;}
if($ergebnis == 'false'){$ergebnis= false;}
return $ergebnis;
Und was ist jetzt mit dem Fehler beim <base>-Tag, der im Gegensatz zu den Fehlern bei den MetaTags noch nicht behoben ist? Kommt das in der nächsten Version?
Verfasst: Sa 11. Feb 2006, 10:18
von emergence
nein, anders
die getProperty würd ich auf keinen fall verändern...
es wird auch dazu verwendet die werte entsprechend zu setzen...
da müsste man sonst ne menge intern umbauen...
ich würd die function getEffectiveSetting modifizieren...
ich hätte in der funktion anstelle von
Code: Alles auswählen
if ($value === false)
{
return $default;
} else {
return $value;
}
etwas wie das hier verwendet
Code: Alles auswählen
if ($value === false)
{
return $default;
} else {
// if default value is a boolean try to return a bool value
if (is_bool($default)) {
if ($value == "true") $value = true;
if ($value == "false") $value = false;
}
return $value;
}
der trick an der sache ist nun
falls bei getEffectiveSetting beim dritten optionalen parameter ein bool wert übergeben wird wird eine typenumwandlung versucht...
falls der parameter nicht angegeben wird handling wie bisher...
ich selbst verwende das aber nicht, da ich einfach zu wenig zeit habe, das genauer auszutesten....
Und was ist jetzt mit dem Fehler beim <base>-Tag, der im Gegensatz zu den Fehlern bei den MetaTags noch nicht behoben ist? Kommt das in der nächsten Version?
keine ahnung ob das in der nächsten version kommt...
es gibt momentan jede menge anderer patches die zuerst in einen neuen release eingebaut werden sollten... momentan tut sich da aber sehr wenig...
Verfasst: Sa 11. Feb 2006, 22:41
von Stefan_Br
Du hast Recht, dass es nur sinnvoll ist, eine Typkonvertierung vorzunhemen, wenn der Aufruf offensichtlich einen bool erwartet, weil ein bool true beispielsweise bei automatischer Rückkonvertierung nach string nicht wieder 'true' wird, sondern '1'.
die getProperty würd ich auf keinen fall verändern...
es wird auch dazu verwendet die werte entsprechend zu setzen...
da müsste man sonst ne menge intern umbauen...
ich würd die function getEffectiveSetting modifizieren...
Hm, vielleicht, es wäre aber verwirrend, wenn sich getEffectiveSetting anders verhalten würde, als die getProperty-Funktionen der einzelnen Objekte. Vielleicht sollte man es auch ganz unterlassen, man muss ja beim Aufrufen auch nur beachten, dass man eben einen string und nicht einen bool zurückbekommt. Außerdem müsste man auch wenn man die Änderung bei getEffectiveSetting vornähme zumindest bei jedem Aufruf kontrollieren, ob es noch funktioniert; es könnte ja sein, dass an einer Stelle als default ein bool übergeben wurde und dennoch einstring erwartet wird, weil die Funktion ja bisher einen string geliefert hat, egal welchen Typ default hatte.
es gibt momentan jede menge anderer patches die zuerst in einen neuen release eingebaut werden sollten... momentan tut sich da aber sehr wenig...
Ich mein, vielleicht könnte ich dabei behilflich sein, zumindest wenn es um die Bugs geht, zu denen ich hier schon was gepostet habe (sind zwar nicht so viele und sicher auch nicht die Wichtigsten...)
Verfasst: So 12. Feb 2006, 16:35
von emergence
Stefan_Br hat geschrieben:...vielleicht könnte ich dabei behilflich sein
naja hilfe ist immer gerne gesehen, aber das hab ich nicht zu entscheiden was in einen neuen release kommt... das ist nur sache von 4fb(werden wohl momentan auch wenig zeit resourcen haben)
eine möglichkeit zu unterstützen, wäre zb das bugs forum durchzusehen und bei problemen die noch keine entsprechende fehlerbehebung aufzeigen, eine lösung zu finden und dort zu posten...
bzw. eventuell angebotene lösungswege auszutesten...
Verfasst: Mi 4. Okt 2006, 21:01
von HerrB
Zum checkin vorgemerkt.
Gruß
HerrB
Verfasst: Mo 9. Okt 2006, 00:23
von HerrB
Vorgeschlagene Überarbeitung (nach Möglichkeit Boolean zurückliefern, wenn Boolean als default übergeben) wurde als kritisch eingestuft und wird nicht Bestandteil von Contenido.
Fehler korrigiert. In class.htmlelements.php ist noch ein Konstrukt übrig, welches man noch überarbeiten sollte.
Gruß
HerrB