Kolla om någon $_POST isset
 

Går det på något sätt att kolla om någon $_POST isset med php?

Då menar jag inte att kolla en specifik $_POST som t.ex. if (isset($_POST['submit'])) utan kolla om det finns någon $_POST över huvudtaget som är isset.

Hittade svaret på ett annat forum, så tänkte dela med mig.

if ($_POST) kollar ifall någon $_POST över huvudtaget har skickats med sidan. Detta är skitbra då jag har samlat alla mina händelser som ska triggas i fall något formulär har postats till sidan i en inlänkad php fil.

Oh happy day!

Annars är det mer korrekt med:

Man bör göra liknande funktioner med $_GET, $_COOKIE, $_SERVER & $_SESSION.

fördelen är om man får bort repetetiv kod från sidorna.
Tex.

Förstår inte riktigt poängen med det där exemplet om jag ska vara ärlig.
Du gör ju samma kontroll i funktionen som du lika gärna skulle kunna göra direkt i koden. Det hade ju till och med blivit kortare om du skrev den direkt i koden såhär:
Det där ger exakt samma resultat som din lösning.
Massa specialfunktioner i onödan gör bara koden onödigt komplex.

Jonas själv har ett logiskt fel i exemplet.

Tack för tipset robincox! Brukar ganska ofta göra något när formulär postats, så nu slipper jag hålla koll på variabelnamn.

Anledningen till att jag vill ha if ($_POST) och inte if ($_POST['something']) är att jag har en php sida som jag includar om någon $_POST finns över huvud taget. Finns det någon $_POST så kommer massor av if (isset($_POST['differentValues'])) att kollas. Jag sparar en massa laddningstid genom att hoppa över alla $_POST kollningar om det inte finns någon $_POST över huvud taget.

Det verkligt rätta sättet är att enkapsulera $_POST i ett objekt och sedan ha en metod, så skriver man typ som såhär:
if($obj->isset()) include('file.php');

Och om man vill hämta ett värde så skriver man
$obj->post('key');

Motsvarande metoder ska också finnas för $_GET etc. Kolla hur ramverk såsom Codeigniter har implementerat detta.

Men vill man inte programmera objektorienterat så skulle jag föredra Jonas lösning under alla omständigheter. Jag vet inte hur din kod ser ut men jag antar att du ändå kollar vilka specifika värden som är tillagda, innan du försöker göra något med dessa. Så du borde väl egentligen göra det typ såhär:
if($obj->validate()) include('file.php');

validate antas här vara en funktion som validerar din formdata och laddar in filen bara om formulärdatan går att använda till någonting. Det vore en bra lösning. Kör man inte objektorienterat så skulle jag ha gjort likadant d.v.s. validerat först och sedan baserat på valideringen inkluderat filen. Inte kollat om någon data finns, ladda in filen och sedan låta den göra valideringen. Men jag hade inte programmerat på det här sättet överhuvudtaget så vad vet jag...

En sista sak bara. Det är inte den här typen av optimeringar som sparar "massa med laddningstid" så Don't Repeat Yourself-principen och god struktur trumfar att minska antalet operationer, i det här sammanhanget, varje gång. Enligt min åsikt.

Varför inte bara kolla om _POST är tom?

Eller if(!count($_POST)) eller if(!sizeof($_POST)) eller if(!end($_POST)) eller if(!next($_POST)) eller if(!current($_POST)) eller if(!count(array_keys($_POST)) eller if(array_reduce($_POST) != NULL)

etc.etc.etc. if($_POST) är fortfarande det kortaste alternativet.

Nja, jag skulle inte ta för givet att $_POST alltid är en array, som du gör.

Det är ju bara om du själv lyckas skriva över $_POST med din egen kod som den inte är en array.
T.ex:
$_POST = null;

Eftersom den kontrollen sker på mer än ett ställe (vilket är troligt) så platsar den i en funktion.
All logik som görs på mer än ett ställe skall vara i en funktion för att underlätta.

Eh, var när hur? Koden är dessutom skriven direkt från huvudet, och var tänkt som exempel.

Som kommer att producera en NOTICE om $_POST inte är satt.

Din jämförelse med false ska inverteras. Just nu säger du att om värdet inte är satt så ska du använda det.

Den logik du försöker låta bli att upprepa är rätt meningslös. Det blir ju lika mycket kod att skriva, bara att du skriver post() och skippar arrayens namn istället för isset(), och det är tveksamt om det kommer behöva göras ändringar i framtiden. Jag tycker det blir klarare att bara göra issetjämförelsen öppet istället för att lägga den i en funktion som potentiellt göra många fler saker.

Men samtidigt håller jag inte riktigt med i all kritik mot metoden. Om det fungerar för dig och dina projekt är det antagligen bra kod, och jag kan förstå att vissa inte vill skriva $_POST överallt. Och du har rätt i att vissa andra förslag ger notiser - syndigt värre!

Om jag förstår dig rätt så vill du göra följande:

[pseudokod]
if(är_satt($_POST)) {
//validera under-element till POST:en här samt gå vidare med hanteringen av dessa
}
[/pseudokod]

Detta vill du göra för att helt enkelt slippa gå in och ladda din inlänkade fil om du inte kommer från rätt formulär / om något bara klickat på "submit" / annan mystisk anledning?

Jag tror nog att du bör kolla på att revidera din design istället för att bara hitta en lösning som fungerar. Ditt pattern verkar vara ganska sårbart mot förändringar.

Ja, absolut där håller jag med.
Men i det exemplet hjälper det dig ju inte alls eftersom du ändå tvingas göra i stort sett samma kontroll i koden ändå . Det gör ju att funktionen inte förenklar och gömmer undan kod vilket är hela anledningen till att man placerar sådan logik som används på flera ställen i en funktion.
Jämför:
med
Din funktion fyller ju ingen funktion då man kan göra exakt samma kontroll direkt i koden och den är dessutom både enklare och kräver ett mindre antal tecken. Det andra exemplet har ju även fördelen att alla vet exakt vad som händer där utan att veta vad funktionen "post" gör.

Är $_POST satt av servern är det en array, annars returnerar väl alla de där kontrollerna false, eller åtminstone något som evalueras till fasle i en if-sats. Har inte kolla på alla i huvudet dock så jag kan ha fel.

Testa kör följande på din dator:
error_reporting(-1);
if(!$_POST) echo 'test';

Det genererar i alla fall ingen E_NOTICE i min logg. Dessutom så används överallt i manualen på php.net...

$_POST är en s.k. "superglobal array" - man hänvisar till den på det sättet i manualen och det står tydligt att den endast definieras i form av en array.

Ja den definieras som en array men det finns inget som hindrar att skriva över den med valfritt värde.

Finns ju ingen anledning att skiva över den. Om man skriver kod där det kan hända har man nog gjort något väldigt fel och då bör man nog tänka om lite i och för sig.

Självfallet är det inte ett "normalt" förfarande.