mboost-dp1

PHP MVC OOP Projekt


Gå til bund
Gravatar #1 - CBM
27. jun. 2017 11:37
Woohoo.. 3 forkortelser i topic...

Jeg skal i gang med et PHP projekt,

Jeg skal lave flg.

* NEMID LOGIN SIDE
* MENU SIDE
* INDSTILLINGER 1
* INDSTILLINGER 2

efter korrekt login sendes man til menu siden, hvorfra man kan vælge indstillinger 1, indstillinger 2 eller log af...

projektet snakker sammen med en webservice, som giver mig informationer og som kan modtage informationer (om det ændringer brugeren laver)

jeg skal bruge UIKit (css og js)
og vil frygtelig gerne lave dette,
mit første PHP projekt,
så korrekt som muligt, derfor vil jeg gerne bruge MVC design principper og jeg vil gerne benytte objekt orientering...

Men jeg mangler nogle gode tuts omkring objekt orientering med PHP og jeg mangler anbefalinger hvad angår et nemt og lækkert framework som kan støtte mig i at arbejde med MVC og OOP

Jeg bruger awardspace som gratis midlertidig test host og deres gratis sider fungerer glimrende med UIKit

Jeg bruger notepad++, Fling, FileZilla samt Firefox+firebug

Jeg har kontakt med signaturgruppen og forventer derfor ikke at nemid login bliver et problem at få til at køre
Gravatar #2 - arne_v
27. jun. 2017 11:43
CBM (1) skrev:
Woohoo.. 3 forkortelser i topic...


3 TLA in topic ...

:-)
Gravatar #3 - CBM
27. jun. 2017 12:14
@arne : jeps... 3x3 :-)

sidder og prøver på at strikke nogle classes sammen...
har en med data til det ene "skærmbillede" og en med data til det andet

men hvis jeg opretter objekter ud fra de klasser som jeg vil fylde data i fra en webservice, så er disse classes vel "model", ligesom en klasse der kan snakke med en webservice for mig også er "model" ?

Jeg skal vel egentlig ikke putte mere i de 2 klasser end hvad der skal til for at opbevare de data jeg vil præsentere og ændre?


"Hvis du vælger et standard MVC framework, så vil controller-action-view setup blive defineret for dig."

- kan du anbefale et godt og meget light framework til formålet?

( jeg har ikke kunnet finde et )

- jeg har fundet lidt sider med info omkring OOP med PHP

- det er et temmeligt lille projekt, så et kæmpe framework virker til at ville blive uoverskueligt i denne sammenhæng
Gravatar #4 - arne_v
27. jun. 2017 12:30
CBM (3) skrev:
men hvis jeg opretter objekter ud fra de klasser som jeg vil fylde data i fra en webservice, så er disse classes vel "model", ligesom en klasse der kan snakke med en webservice for mig også er "model" ?

Jeg skal vel egentlig ikke putte mere i de 2 klasser end hvad der skal til for at opbevare de data jeg vil præsentere og ændre?


Model vil inkludere baade rene data klasser og noget til at tilgaa dem med.

Jeg foretraekker at se model som et relativt tyndt lag oven paa business logic layer eller remote data.

http://www.vajhoej.dk/arne/articles/arch.html#mvc
Gravatar #5 - arne_v
27. jun. 2017 12:36
CBM (3) skrev:
"Hvis du vælger et standard MVC framework, så vil controller-action-view setup blive defineret for dig."

- kan du anbefale et godt og meget light framework til formålet?

( jeg har ikke kunnet finde et )


Der er masser af muligheder.

Men jeg ved ikke hvilken der er bedst, fordi jeg har ikke selv prøvet dem.

Du skal have fat på en PHP mand!

:-)
Gravatar #6 - CBM
27. jun. 2017 12:42
@arne:

er det ikke typisk
"stricter version: only call the layer beneath" man vil bruge?

ie. view bør ikke kalde model men derimod kalde controller som så selv afgører hvornår den har behov for at snakke med modellen?

Jeg kan godt lide denne opbygning...

Browser Tier > Application Tier > DB Tier

Application Tier:
VIEW -
Presentation Layer
CONROLLER -
Business Logic Layer (eller det du vil kalde Control Layer?)
MODEL -
Data Access Layer (eller det du i visse modeller kalder Business Logic Layer?)

Jeg kan ikke se hvorfor der kan være behov for både controller og business logic layers? eller rettere, hvad er forskellen?

det virker til at nogle af dine modeller anser business logic for at håndtere databasen, mens andre modeller bruger den som controller ?

jeg er lidt forvirret :-)


arne_v (5) skrev:

Der er masser af muligheder.

Men jeg ved ikke hvilken der er bedst, fordi jeg har ikke selv prøvet dem.

Du skal have fat på en PHP mand!

:-)


TB? :-)


Gravatar #7 - gramps2
27. jun. 2017 12:48
Jeg ved godt at du ikke er glad for Google, men burde tjenesten ikke blive testet i Chrome sideløbende med Firefox?
Gravatar #8 - CBM
27. jun. 2017 14:15
#7:
Jo det kan der være noget om.

Safari
Firefox
Chrome
IE???
Edge
Opera???
Gravatar #9 - arne_v
27. jun. 2017 16:27
CBM (6) skrev:

TB? :-)


Der må være adskillige PHP folk her.
Gravatar #10 - arne_v
27. jun. 2017 16:44
CBM (6) skrev:
Jeg kan godt lide denne opbygning...

Browser Tier > Application Tier > DB Tier

Application Tier:
VIEW -
Presentation Layer
CONROLLER -
Business Logic Layer (eller det du vil kalde Control Layer?)
MODEL -
Data Access Layer (eller det du i visse modeller kalder Business Logic Layer?)

Jeg kan ikke se hvorfor der kan være behov for både controller og business logic layers? eller rettere, hvad er forskellen?

det virker til at nogle af dine modeller anser business logic for at håndtere databasen, mens andre modeller bruger den som controller ?

jeg er lidt forvirret :-)


Den gængse 3 lags model er:

PL = brugergrænsefladen

BLL = forretnings logikken, hvis det er et eCommerce web site så er det rigtig forretning d.v.s. moms udregning + rabat satser + forsendelsesokomkostninger + trække penge fra Dankort + initiere forsendelse etc., hvis det er newz.dk så er det kun "forretning" d.v.s. er man logget ind + hvad er der af nye indlæg + kan man kommentere på tråd etc.

DAL = håndtering af persistering af data

Man kan (og jeg kan godt lide det) splitte brugergrænsefladen i 2 dele ved at introducere Control Layer og så have en 4 lags model:

PL = synlige del af brugergrænsefladen der viser noget
CL = den del af brugergrænsefladen som håndterer brugernes handlinger
Gravatar #11 - arne_v
27. jun. 2017 16:49
#10

Hvis vi snakker Delphi så er det enten:

PL = form + form kode
BLL = beregnings kode
DAL = gemme i og hente fra database kode

eller:

PL = form
CL = form kode
BLL = beregnings kode
DAL = gemme i og hente fra database kode
Gravatar #12 - Slettet Bruger [1913734024]
27. jun. 2017 17:00
Forretningslogikken i MVC bør ligge i "modellen" og ikke i dine controllers.

På den måde kan dit PL (V+C af MVC) udskiftes uafhængigt af BL. Hvis du nu har al din BL kode i controllers, så bliver det besværligt at tage det med over på f.eks. en WebService eller måske en mobil app senere. På samme måde som med MVC og BL i modellen, så vil modellen/BL kunne bruges bag en service facade i f.eks. en SOA arkitektur hvis du senere skal scale ud.
Gravatar #13 - arne_v
27. jun. 2017 17:05
#12

Nu tror jeg ikke at der er nogen som har argumenteret for at have al BL kode i controllers.

Men jeg naevner to opfattelser af M:
* facade af BLL
* tynd proxy i PL/CL til BLL

Og jeg kan bedst lide den sidste.
Gravatar #14 - Slettet Bruger [1913734024]
27. jun. 2017 17:12
arne_v (13) skrev:
#12

Nu tror jeg ikke at der er nogen som har argumenteret for at have al BL kode i controllers.

Men jeg naevner to opfattelser af M:
* facade af BLL
* tynd proxy i PL/CL til BLL

Og jeg kan bedst lide den sidste.


CBM (6) skrev:

Jeg kan ikke se hvorfor der kan være behov for både controller og business logic layers? eller rettere, hvad er forskellen?


Måske bare mig der misforstod #6?
Gravatar #15 - arne_v
27. jun. 2017 17:17
#14

Ah. Ja - jeg kan godt se din pointe.

Jeg tror at jeg fik CBM forvirret lidt med "control layer".
Gravatar #16 - CBM
28. jun. 2017 05:26
@arne: jeg vil satse på 3 lag, PL+BLL+DAL
Gravatar #17 - CBM
28. jun. 2017 06:46
hvad med fil struktur og navngivning?

jeg tænker pt på flg.:

filstruktur...

alle php filer i rod biblioteket

alle cs i cs folder
alle js i js folder

navngivning...

alle model php filer som m_<navn>.php
alle controller php filer som c_<navn>.php
alle view php filer som v_<navn>.php

undtagen de php filer som indeholder selve formen, fx

login.php, hovedmenu.php, indstilling1.php, indstilling2.php

så måske er det alligevel denne struktur:

PL = form (login.php,hovedmenu.php...)
CL = form kode (v_login.php, v_hovedmenu.php...)
BLL = beregnings kode (c_login.php, c_hovedmenu.php...)
DAL = gemme i og hente fra database kode (m_login.php, m_hovedmenu.php...)

evt kombineret med en c_shared.php og en m_shared.php til kode der kan genbruges på tværs af alle forme/"skærmbilleder"?

alle forme vil blive stateless, så vidt det er muligt, dog skal de kende til om man er logget ind eller ej




Gravatar #18 - gramps2
28. jun. 2017 08:44
Jeg synes helt sikkert at du skal teste i Chrome, IE, Firefox, Safari. Edge vil også være en god ide, da den faktisk har en ret stor del. Opera er desværre forsvundet ned under Others...
Gravatar #19 - CBM
28. jun. 2017 09:23
gramps2 (18) skrev:
Jeg synes helt sikkert at du skal teste i Chrome, IE, Firefox, Safari. Edge vil også være en god ide, da den faktisk har en ret stor del. Opera er desværre forsvundet ned under Others...


Yes, men tænker at UIKit
(der består af JS og CSS
og som vil håndtere alt
responsive GUI i dette projekt ...
dvs en RWD GUI),
har sikkert sørget for at deres framework virker i alle browsere,
vil dog teste for at være sikker.
Gravatar #20 - gramps2
28. jun. 2017 12:44
Det er UI. Jeg har en mistanke om at f.eks. NemID login kan give bøvl mht. funktionalitet på tværs af browserne - uden dog at have arbejdet med det før.

UI-mæssigt burde der ikke være stor forskel, nej.
Gravatar #21 - CBM
28. jun. 2017 13:00
#20: tjah, kan bekræfte at det virker i edge, firefox, opera og chrome... kan ikke teste i safari da jeg ikke kan hente den til linux eller windows, jeg har ikke en mac og jeg har ikke min hackintosh VM længere
(den blev slettet for længe siden pga jeg ikke brugte den)

lidt mystisk at Apple har valgt ikke længere at stille safari til rådighed på windows... oh well
Gravatar #22 - Claus Jørgensen
28. jun. 2017 13:04
CBM

GitHub hvad du laver, så kan newz lave code-reviews
Gravatar #23 - Slettet Bruger [1913734024]
28. jun. 2017 13:15
Enig med #22, det kan give meget. :-)
Gravatar #24 - CBM
28. jun. 2017 13:18
#22 og #23... tjah, tror ikke min chef ville bryde sig om at jeg laver projektet til et open source projekt :-) men er ellers enig i jeres betragtninger... selv om det nok næppe er banebrydende på nogen måde.


Der er så også lige det at han sikkert ikke vil have offentliggjort interfaces til vore "interne" webservices :-)


Tænker jeg må nøjes med den viden jeg kan suge på anden vis :-)

NEMID login siden virker fint, men bruger ikke UIKit pt... jeg måtte lære hvad composer var, for at kunne hente de filer der skulle bruges til NEMID siden :-)
Gravatar #25 - arne_v
28. jun. 2017 17:37
CBM (17) skrev:
hvad med fil struktur og navngivning?

jeg tænker pt på flg.:

filstruktur...

alle php filer i rod biblioteket

alle cs i cs folder
alle js i js folder

navngivning...

alle model php filer som m_<navn>.php
alle controller php filer som c_<navn>.php
alle view php filer som v_<navn>.php

undtagen de php filer som indeholder selve formen, fx

login.php, hovedmenu.php, indstilling1.php, indstilling2.php


Igen er du nok bedre tjent med at spørge en PHP mand. :-)

Men jeg ville lave 3 subdirs og droppe m_, c_ og v_ prefixes.

Struktur.

Og jeg ville også seriøst overveje separate sub dir til bll og dal i.s.f. bare at putte det hele i m.
Gravatar #26 - arne_v
28. jun. 2017 17:38
CBM (17) skrev:
hvad med fil struktur og navngivning?

jeg tænker pt på flg.:

filstruktur...

alle php filer i rod biblioteket

alle cs i cs folder
alle js i js folder

navngivning...

alle model php filer som m_<navn>.php
alle controller php filer som c_<navn>.php
alle view php filer som v_<navn>.php

undtagen de php filer som indeholder selve formen, fx

login.php, hovedmenu.php, indstilling1.php, indstilling2.php


Igen er du nok bedre tjent med at spørge en PHP mand. :-)

Men jeg ville lave 3 subdirs og droppe m_, c_ og v_ prefixes.

Struktur.

Og jeg ville også seriøst overveje separate sub dir til bll og dal i.s.f. bare at putte det hele i m.
Gravatar #27 - arne_v
28. jun. 2017 17:45
CBM (16) skrev:
jeg vil satse på 3 lag, PL+BLL+DAL


Det gør de fleste.

De fleste har ikke engang hørt om CL.

CBM (17) skrev:
så måske er det alligevel denne struktur:

PL = form (login.php,hovedmenu.php...)
CL = form kode (v_login.php, v_hovedmenu.php...)
BLL = beregnings kode (c_login.php, c_hovedmenu.php...)
DAL = gemme i og hente fra database kode (m_login.php, m_hovedmenu.php...)


Men mange ender alligevel op med de facto separate PL og CL.

Jeg forstår dog ikke helt din opdeling.

I min opfattelse er det:

PL = v_
CL = c_ + tynd m_
BLL
DAL

CBM (17) skrev:
evt kombineret med en c_shared.php og en m_shared.php til kode der kan genbruges på tværs af alle forme/"skærmbilleder"?


Ja. shared (eller util som de ofte kaldes) til lidt genbrug er tit praktisk.

Til static brug.

Til instance brug var det i mange tilfælde mere oplagt at bruge traits.

CBM (17) skrev:
alle forme vil blive stateless, så vidt det er muligt, dog skal de kende til om man er logget ind eller ej


Det bør ligge i session.
Gravatar #28 - arne_v
29. jun. 2017 01:38
arne_v (27) skrev:
Jeg forstår dog ikke helt din opdeling.

I min opfattelse er det:

PL = v_
CL = c_ + tynd m_
BLL
DAL


eller:

PL = v_
CL = c_
BLL = m_
DAL
Gravatar #29 - CBM
29. jun. 2017 04:02
arne_v (28) skrev:

eller:

PL = v_
CL = c_
BLL = m_
DAL


Netop det jeg tænkte men det ville nok være bedre med subdirs:

/view
Login.php
Menu.php
...

/controller
Login.php
Menu.php
...

/model
Logon.php
Menu.php
...

/shared
Model.php
Controller.php

?



Edit.. Tak til newz for rnd udlogning?
Gravatar #30 - CBM
29. jun. 2017 12:59
hmm.. er stødt på 2 problemer...

1) “Cannot send session cache limiter - headers already sent”
jeg kører flg. kode i min "header" for alle sider pånær login

<?php session_start(); ?>

det er det første der bliver kørt for siden

...

jeg har også en logout php fil som ikke benytter header og footer, men som også laver en session start når den kaldes, efterfulgt af en redirect til login siden.. denne side kommer også med fejlen??

ala dette...
https://www.w3schools.com/php/php_sessions.asp

bare med en redirect tilføjet i slutningen af body


2) UIKIT

https://getuikit.com/docs/introduction

Hvordan laver jeg en dropdown box med fx 3 linjers tekst hentet
fra en funktion i en php klasse?

man skal kunne vælge en af linjerne og så skal en session variabel sættes baseret på ens valg, således at de andre sider kan læse hvad der er valgt

hvis jeg gør dette...

<div class="uk-margin uk-grid-small uk-child-width-auto" uk-grid>
<label><input class="uk-radio" type="radio" name="radio2" checked> A</label>
<label><input class="uk-radio" type="radio" name="radio2"> B</label>
</div>

så skal jeg have en måde at dynamisk generere det på.... skrive en txt fil og include?

og hvordan ved jeg hvad der er valgt?
Gravatar #31 - arne_v
29. jun. 2017 13:06
CBM (30) skrev:
<?php session_start(); ?>

det er det første der bliver kørt for siden


Sikker?

Ikke en blank linie ovenover?
Gravatar #32 - arne_v
29. jun. 2017 13:12
CBM (30) skrev:
bare med en redirect tilføjet i slutningen af body


redirect skal laves inden der sendes noget normal response til client.
Gravatar #33 - CBM
29. jun. 2017 13:46
@arne:


her er min logout side

<?php session_start(); ?>
<!DOCTYPE html>
<html>
<body>

<?php
// remove all session variables
session_unset();

// destroy the session
session_destroy();
?>

<script>
window.location.replace(<link jeg redirecter til>);
</script>

</body>
</html>

skal jeg køre session destroy efter mit redirect?????

hov vent... jeg fjernede noget whitespace og nu virker det?


åbenbart er

<?php session_start(); ?>

ikke det samme som


<?php
session_start();
?>

Gravatar #34 - Slettet Bruger [1913734024]
29. jun. 2017 13:50
#33

Hvis du bruger JavaScript til at redirect, så behøver du ikke at sende redirect først.

Tilgengæld, hvis du bruger header('Location: <url>'); i PHP, så skal man sende redirect før der sendes indhold til browseren.
Gravatar #35 - CBM
29. jun. 2017 13:59
#33: Ok. Er det bedst med js eller php til redirect, eller kommer det ud på et?
Gravatar #36 - Slettet Bruger [1913734024]
29. jun. 2017 14:10
CBM (35) skrev:
#33: Ok. Er det bedst med js eller php til redirect, eller kommer det ud på et?


Forskellen er at med JavaScript skal modtagerens browser modtage HTML dokumentet, parse det, alt efter hvor JavaScriptet er indsat, indhente eksterne resourcer, køre JavaScriptet og derfra redirect.

Ved PHP modtager browseren en HTTP header redirect kode og går til destinationen - uden at loade dokumentet.
Gravatar #37 - Claus Jørgensen
29. jun. 2017 14:25
#33

plx don't mix php/html :(
Gravatar #38 - CBM
29. jun. 2017 14:59
@claus:
Skulle jeg lave en logout.php med
Session delete og redirect som jeg inkluderer?

Eller bare ren PHP, jeg har jo ikke brug for at vise noget HTML?

<?php session_start();

// redirect
('Location: <url>');

// remove all session variables
session_unset();

// destroy the session
session_destroy();
?>


Og hvordan ift mvc?

?
Gravatar #39 - Slettet Bruger [1913734024]
29. jun. 2017 15:29
Claus Jørgensen (37) skrev:
#33

plx don't mix php/html :(


Du må være umådelig vild med WordPress. :-)

#38

Du behøver ingen view komponeneter for at lave en logout der bare skal redirect. Det ville nok være bedst bare at have den del i en controller.
Gravatar #40 - arne_v
29. jun. 2017 15:33
#39

En controller/action skal da returnere et eller andet til client og det et eller andet er vel et view. Spoergsmaalet er vel kun om det skal loades normalt eller redirect.

Views er ikke noedvendigvis tilnyttet en bestemt controller. Saa der er ikke noget galt med at logout controller bruger login view.
Gravatar #41 - Slettet Bruger [1913734024]
29. jun. 2017 15:36
arne_v (40) skrev:
#39

En controller/action skal da returnere et eller andet til client og det et eller andet er vel et view. Spoergsmaalet er vel kun om det skal loades normalt eller redirect.

Views er ikke noedvendigvis tilnyttet en bestemt controller. Saa der er ikke noget galt med at logout controller bruger login view.


Hvis din controller alligevel bare sender en HTTP 302 unconditionally, så er et view vel alligevel aldrig sendt til klienten og dermed irrelevant.

Hvis man undlader redirect, så kan man sagtens vise en log ind skærm.
Gravatar #42 - arne_v
29. jun. 2017 15:49
#41

Sandt nok. Redirect trigger en anden controller/action som returnerer et view.
Gravatar #43 - Slettet Bruger [1913734024]
29. jun. 2017 15:55
arne_v (42) skrev:
#41

Sandt nok. Redirect trigger en anden controller/action som returnerer et view.


Det er også min antagelse. Du kan så have ret i at det ikke nødvendigvis er den korrekte måde at håndtere situationen på. Din model med at varetage logout i en controller og derfra retunere det ønskede view er vel mere optimal (færre interaktioner mellem klient og server) hvis vi antager at viewet der skal præsenteres efter logout ikke indeholder en større mængde controller kode. Ved en ikke tilstrækkelig opdeling mellem CL og BL, så kan man ende med en del duplikeret controller kode hvis der er meget kode i det ønskede view/controller. (Giver det mening?)
Gravatar #44 - CBM
4. jul. 2017 12:03
web services...

jeg er løbet ind i problemer mht en "dummy webservice" jeg vil lave til min side (indtil den rigtige service er klar)...

eksempel 1:

dette fungerer fint:

klient

HelloClientWsdl.php

<?php # HelloClientWsdl.php
# Copyright (c) 2005 by Dr. Herong Yang
#
$client = new SoapClient(".../Hello.wsdl",
array('soap_version' => SOAP_1_2,'trace' => 1 ));

echo("\nDumping client object functions:\n");
var_dump($client->__getFunctions());

$return = $client->__soapCall("hello",array("world"));
echo("\nReturning value of __soapCall() call: ".$return);

# $return = $client->hello("world");
# echo("\nReturning value: ".$return);

echo("\nDumping request headers:\n"
.$client->__getLastRequestHeaders());

echo("\nDumping request:\n".$client->__getLastRequest());

echo("\nDumping response headers:\n"
.$client->__getLastResponseHeaders());

echo("\nDumping response:\n".$client->__getLastResponse());
?>

server

HelloServerWsdl.php

<?php # HelloServerWsdl.php
# Copyright (c) 2005 by Dr. Herong Yang
#
function hello($someone) {
return "Hello " . $someone . "! - With WSDL";
}
ini_set("soap.wsdl_cache_enabled", "0");
$server = new SoapServer(".../Hello.wsdl",
array('soap_version' => SOAP_1_2));
$server->addFunction("hello");
$server->handle();
?>

WSDL

Hello.wsdl

<?xml version="1.0"?>
<definitions name="MyDefinition"
targetNamespace="urn:myTargetNamespace"
xmlns:tns="urn:myTns"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<message name="myRequest">
<part name="reqParam" type="xsd:string"/>
</message>
<message name="myResponse">
<part name="resParam" type="xsd:string"/>
</message>
<portType name="MyPortType">
<operation name="hello">
<input message="tns:myRequest"/>
<output message="tns:myResponse"/>
</operation>
</portType>
<binding name="MyBinding" type="tns:MyPortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="hello">
<soap:operation soapAction=""/>
<input>
<soap:body use="encoded"
namespace="urn:myInputNamespace"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace="urn:myOutputNamespace"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name="MyService">
<documentation>Returns a greeting string.
</documentation>
<port name="MyPort" binding="tns:MyBinding">
<soap:address
location=".../HelloServerWsdl.php"/>
</port>
</service>
</definitions>

det næste eksempel.. som returnerer et array, fungerer ikke...

eksempel 2:

klient

client2017.php

<?php

//DISABLE WSDL CACHE.
ini_set("soap.wsdl_cache_enabled", "0");

//CREATE SOAP CLIENT FROM WSDL.
$client = new SoapClient(".../serverwsdl2017.wsdl");

//CALL SOAP METHOD.
$test = $client->test();

//DISPLAY RESPONSE.
var_dump($test);
echo($test->name." ".$test->surName); //Return object data.
//echo($test[0]." ".$test[1]); //Return array data.
//echo($test["name"]." ".$test["surName"]); //Return hash data.
?>

server

server2017.php

<?php

//CLASS WTH WEB SERVICE METHODS.
class WebService {

function test() {

//OBJECT.
$obj = new stdClass();
$obj -> name = "John";
$obj -> surName = "Malkovic";

//ARRAY.
$arr = array("John", "Malkovic");

//HASH.
$hsh = array("name"=>"John", "surName"=>"Malkovic");

//RETURN.
return $obj; //Return object.
//return $arr; //Retun array.
//return $hsh; //Retun hash
}
}

//DISABLE WSDL CACHE.
ini_set("soap.wsdl_cache_enabled", "0");

//CREATE SOAP SERVER.
$server = new SoapServer(".../serverwsdl2017.wsdl");

$server->setClass("WebService");
$server->handle();
?>

WSDL

serverwsdl2017.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<!-- WSDL file generated by PHP WSDLCreator (http://www.protung.ro) -->
<definitions name="WSDLExample1" targetNamespace="urn:WSDLExample1"
xmlns:typens="urn:WSDLExample1" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/">
<message name="infoResponse">
<part name="infoReturn"></part>
</message>
<portType name="SelfcareWS1PortType">
<operation name="test">
<documentation>Adds two numbers.</documentation>
<output message="typens:infoResponse"></output>
</operation>
</portType>
<binding name="SelfcareWS1Binding" type="typens:SelfcareWS1PortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"></soap:binding>
<operation name="test">
<soap:operation soapAction="urn:SelfcareWS1Action"></soap:operation>
<input>
<soap:body namespace="urn:WSDLExample1" use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"></soap:body>
</input>
<output>
<soap:body namespace="urn:WSDLExample1" use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"></soap:body>
</output>
</operation>
</binding>
<service name="WSDLExample1Service">
<port name="SelfcareWS1Port" binding="typens:SelfcareWS1Binding">
<soap:address location=".../server2017.php"></soap:address>
</port>
</service>
</definitions>

SOAPUI brokker sig over at der er noget galt med WSDL filen i eksempel 2, men har intet problem med WSDL filen i eksempel 1... Den skriver bare ikke noget om hvad problemet egentlig er?

https://www.w3schools.com/xml/xml_validator.asp
w3schools XML validator finder ingen fejl i XML filen i eksempel 2 ?

jeg undres... :/

jeg ville allerhelst kunne modtage et objekt fra en eksempel webservice
Gravatar #45 - arne_v
4. jul. 2017 13:31
#44

Er der gode grunde til at vælge SOAP?
Gravatar #46 - CBM
4. jul. 2017 14:04
#44: ja, jeg kunne finde eksempler der var nemme at få til at køre i php? :)
Gravatar #47 - arne_v
4. jul. 2017 18:46
#46

Hvis snakker ESB og integration i den tunge (læs: dyre) ende, så er SOAP rigtigt godt.

Men til en letvægts web løsning var noget RESTful simpelt JSON/HTTP(S) nok bedre.
Gravatar #48 - arne_v
5. jul. 2017 02:37
Her er et eksempel.

restsrv.php:


<?php
class Person {
public $id;
public $firstname;
public $lastname;
public function __construct($id, $firstname, $lastname) {
$this->id = $id;
$this->firstname = $firstname;
$this->lastname = $lastname;
}
}

parse_str($_SERVER['QUERY_STRING']);
$nogen = new Person($id, 'Anders', 'And');
header('Content-type: application/json');
echo json_encode($nogen);
?>



restcli.php:


<?php
$resp = file_get_contents('http://localhost:81/restsrv.php?id=123');
$nogen = json_decode($resp);
echo $nogen->id . ' ' . $nogen->firstname . ' ' . $nogen->lastname . "\r\n";
?>

Gravatar #49 - arne_v
5. jul. 2017 02:37
Hvis du meget gerne vil bruge SOAP så kan jeg godt prøve at få det til at virke også.
Gravatar #50 - CBM
5. jul. 2017 03:35
@arne: jeg har ingen særlige præferencer for 'sæbe' i denne sammenhæng, så jeg vil afprøve dit REST eksempel i dag. Takker :-)

Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login