Prüfung auf XHTML/Typkonvertierung bei getProperty

[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:

Code: Alles auswählen

if($is_XHTML  == 'true'){
.
.
.
}

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.

[emergence]

hatte ich mir auch schon mal überlegt...

vernünftige vorgehensweise wie das gehandled werden soll ???

ich verschiebs nach development...

[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:

Code: Alles auswählen

return $ergebnis;

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?

[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...

[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...)

[emergence]

...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...

[HerrB]

Zum checkin vorgemerkt.

Gruß
HerrB

[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