Application "includen" welke buiten je docroot staat

[Anoniem: 149075]

Ik ben de hele dag al aan het brainstormen en zoeken hoe ik het beste PHP applicaties welke je standalone kunt gebruiken kunt "includen" in je eigen script. De reden waarom ik dit wil is omdat de "geinclude" applicatie dan op zichzelf blijft staan en makkelijker te upgraden is. Ik wil tevens voorkomen door middel van het buiten de doc_root plaatsen van een dergelijke applicatie dat deze op zichzelf wordt aangeroepen.

Nu is het nogal trivial om een applicatie te includen met include() door gewoon een pagina te laden en hier de include in te zetten. Een tweede probleem waar je tegenaan loopt is dat je documentroot voor de applicatie niet meer klopt met van waar je het daadwerkelijk aanroept. Veel applicaties hebben geen doc_root setting in hun config staan dus wordt het allemaal een beetje dirty.

Ik heb ook al de mogelijkheid bekeken om een Apache Alias aan te maken en deze dan alleen vanaf localhost benaderbaar te maken door middel van een .htaccess zodat de URL niet vanaf externe IP's benaderd kan worden.

edit:
in dit geval zou ik overigens gebruik maken van een iframe waar ik denk ik sowieso niet onderuit komt

Zelf vind ik het allemaal erg dirty en probeer een manier te vinden om dergelijke programma's als een soortement van module te laden. Het lijkt mij dat het laden van een module op zich mogelijk moet zijn, ook zonder het volledig aanpassen van een dergelijke applicatie.

Applicaties waar ik aan denk als voorbeeld zijn:

- Webmail
- Gallery
- Chat
- etc.

Er zijn voldoende PHP varianten van te vinden, vaak alleen geen idee hoe je dit zou kunnen "includen" in je eigen script browsel.

Moet ik gaan kijken naar een manier hoe ik modules kan laden in mijn script of zijn er ook andere manieren welke netjes te verwerken zijn ?

[ Voor 3% gewijzigd door Anoniem: 149075 op 12-06-2011 20:22 ]

[8088]

Het probleem is me niet volledig duidelijk, maar zijn symlinks geen optie om de doc_root-horde te overbruggen? Je zou ook API's voor je applicaties kunnen schrijven, maar dat is wel een hoop extra werk.

[Anoniem: 149075]

Ik zal het probleem proberen te verduidelijken.

Ik heb een intranet met de url:

www.intranet.tld/

Een gebruiker kan hier op inloggen en zijn ding doen.

Omdat ik het makkelijk vindt om hier door andere personen geschreven applicaties IN te gebruiken zal ik deze moeten laden in mijn intranet.

Normaal zal je zonder manier van includen krijgen: www.intranet.tld/applicatie

Dit zal de applicatie ook nodig hebben omdat het beschibaar moet zijn via je browser.

Nu wil ik dat natuurlijk ook bereiken maar dan niet onder directory van de applicatie zelf maar in mijn intranet php script tool ding. Om tegen te gaan dat de applicatie op zichzelf geladen zal worden kan ik dus geen /home/www.intranet.tld/applicatie gebruiken maar zal ik deze in /home moeten zetten in een /home/applications folder en de applicatie daar dus uit moeten laden in mijn intranet... which is impossible krijg ik het gevoel.

Een API zou mogelijk zijn maar inderdaad onnoemelijk veel werk.


Echter is op deze manier

[Janoz]

Ik begrijp niet helemaal welk probleem je denkt op te moeten lossen. Als je het al in een eigen pagina zou willen zetten dan kan dat enkel middels een iframe of het aanpassen van de applicatie (denk alleen al aan de html start tag). Als je een iframe zou gebruiken dan moet de app per definitie van buiten beschikbaar zijn.

[Anoniem: 149075]

Janoz schreef op zondag 12 juni 2011 @ 21:08:
Ik begrijp niet helemaal welk probleem je denkt op te moeten lossen. Als je het al in een eigen pagina zou willen zetten dan kan dat enkel middels een iframe of het aanpassen van de applicatie (denk alleen al aan de html start tag).

Klopt helemaal, dat zou een optie kunnen zijn.

Als je een iframe zou gebruiken dan moet de app per definitie van buiten beschikbaar zijn.

En dat wil ik dus niet, de app van buiten beschikbaar. En dat zou dus een dubbele uitdaging worden vrees ik.

Het moet opzich mogelijk zijn. Drupal en dergelijke frameworks doen dit ook, dus waarom zou je het zelf niet kunnen maken. Drupal als voorbeeld is wellicht weer lastig omdat dit zijn eigen manier van modules laden heeft.

[ Voor 15% gewijzigd door Anoniem: 149075 op 12-06-2011 22:58 ]

[Freeaqingme]

Drupal en dergelijke frameworks doen dit ook, dus waarom zou je het zelf niet kunnen maken

Omdat Drupal modules specifiek voor Drupal geschreven worden. Je kan ook niet zomaar een drupal module in een typo3 applicatie zetten. Als je dan zo nodig een application framework wil gebruiken zou je beter eens naar Drupal of Symfony kunnen kijken.

[Anoniem: 149075]

Freeaqingme schreef op zondag 12 juni 2011 @ 23:41:
[...]


Omdat Drupal modules specifiek voor Drupal geschreven worden. Je kan ook niet zomaar een drupal module in een typo3 applicatie zetten. Als je dan zo nodig een application framework wil gebruiken zou je beter eens naar Drupal of Symfony kunnen kijken.

Nee logisch dat dat niet kan, maar het is de moeite waard te bekijken hoe zij dergelijke scripts als module laden.

Het nadeel van dergelijke frameworks vind ik dat je weer op een andere manier moet gaan programmeren, dus dat zal ik niet doen. Maar dat is een andere discussie welke we hier niet moeten voeren, hier heb ik al voldoende research voor gedaan. Ik heb mijn eigen framework dat letterlijk MVC doet.

[Kwastie]

Anoniem: 149075 schreef op zondag 12 juni 2011 @ 23:55:
[...]
Nee logisch dat dat niet kan, maar het is de moeite waard te bekijken hoe zij dergelijke scripts als module laden.

Het laden is triviaal.

"Ze" hebben deze "problemen" opgelost door een API te maken, en omdat iedere module zich aan deze API houdt integreert het meestal goed.

Simpel gezegd kun je het bijvoorbeeld op deze manier oplossen: (ik neem hierbij wel aan dat je een een "single point of entry" hebt)

Ergens definieer je welke "modules" beschikbaar zijn , vervolgens geef je per module aan hoe de URL er uit ziet. (bijv. "Gallery" -> site.nl/foto/). Iedere module weet zelf wat er moet "gebeuren".

Stel, de gebruiker opent "site.nl/foto/view/1". Je applicatie laad de module "Gallery", en die module weet dat hij bij "/view/1" een foto moet weergeven.

Zo werkt trouwens https://www.djangoproject.com/ ook

[ Voor 3% gewijzigd door Kwastie op 13-06-2011 00:47 ]

[Freeaqingme]

Anoniem: 149075 schreef op zondag 12 juni 2011 @ 23:55:
[...]


Nee logisch dat dat niet kan, maar het is de moeite waard te bekijken hoe zij dergelijke scripts als module laden.

Het nadeel van dergelijke frameworks vind ik dat je weer op een andere manier moet gaan programmeren, dus dat zal ik niet doen.

Als je moet kiezen tussen het wiel volledig opnieuw uitvinden, of een reeds bestaande oplossing gebruiken en enkel wat nieuwe dingen moeten leren zal je normaal gesproken /altijd/ op de 2e oplossing uitkomen. Als programmeur moet je toch ook de api van de programmeertaal waar je op dat moment in programmeert leren? En die van 3rdparty api's, en de shortcuts van je IDE, en ....

[Anoniem: 149075]

Freeaqingme schreef op maandag 13 juni 2011 @ 01:50:
[...]


Als je moet kiezen tussen het wiel volledig opnieuw uitvinden, of een reeds bestaande oplossing gebruiken en enkel wat nieuwe dingen moeten leren zal je normaal gesproken /altijd/ op de 2e oplossing uitkomen. Als programmeur moet je toch ook de api van de programmeertaal waar je op dat moment in programmeert leren? En die van 3rdparty api's, en de shortcuts van je IDE, en ....

Ik snap wat het bedoelt alleen vraag ik me sterk af of je via API's zaken wilt gaan aansturen.

Ik heb bijvoorbeeld Gallery2 bekeken en daar de API van geraadpleegd. Waarom zou je alles via de API doen ? wijzigen ze iets in de API zal je zaken aan moeten passen, dit blijft toch maar dan nog. Het "inladen" van een volledige tool zou makkelijker zijn voor de implementatie natuurlijk

Ik wil geen quick en dirty maar probeer te bekijken hoe andere developers dit doen welke dergelijke tools implementeren. Ik zie daar overigens weinig API gebruik.

[Freeaqingme]

Ik heb het niet enkel over externe webservices. Bij een programmeertaal vormen de beschikbare functies en hun parameters een api. Bij een framework vormen de beschikbare classes, methodes, en hun parameters een api.

Een kenmerk van goede api's is dat je als je een versie gebruikt, die versie in principe nooit zal veranderen.

[Anoniem: 149075]

Ik heb het momenteel alleen even over een webservice, excuus voor de onduidelijkheid.

Wat je zegt klopt, opzich zal een API nooit mogen veranderen, ik heb echter andere ervaringen. Vandaar dat ik een op zichzelf staande app wil "includen" zodat hij eigenlijk op zichzelf draait, wellicht met wat login tweaks, maar wel in een schil.

[Voutloos]

Anoniem: 149075 schreef op maandag 13 juni 2011 @ 12:08:
Wat je zegt klopt, opzich zal een API nooit mogen veranderen, ik heb echter andere ervaringen. Vandaar dat ik een op zichzelf staande app wil "includen" zodat hij eigenlijk op zichzelf draait, wellicht met wat login tweaks, maar wel in een schil.

Helaas, er is geen silver bullet hier, dus een beter antwoord dan dat van Freeaqingme gaat er voor jou niet uitrollen.

En omdat er geen heilige graal is, doet iedereen het anders, of vanuit de andere kant gezien: anders had iedereen niet zo moeilijk gedaan. Je hebt gewoon een conventie/API/hoe-je-het-ook-noemt nodig, en daarbij krijg je inderdaad vanzelf de verantwoordelijkheid erbij om dat stabiel te houden en niet bij elke release helemaal om te gooien.

Een van de moeilijkste aspecten bij het bedenken van een API is dat het echt helemaal doorgedacht moet zijn, zodat je het voldoende backwards (en forwards) compatible kan houden, zonder dat je binnen no-time permanent in een hoekje zit te huilen vanwege alle legacy of slechte design keuzes. Of je zelf iets maakt of een bestaand systeem adopteert maakt mij niet uit (jouw topics kennende wil je het toch zelf opnieuw uitvinden), maar speel tenminste wel serieus met wat bestaande implementaties, zodat je gewoon leert wat wel en niet mooi werkt.

[ Voor 25% gewijzigd door Voutloos op 13-06-2011 12:59 ]