Der er grundlæggende 3 veje at gå:
Version 1:"Old school":PHP-Gtk+ og bcompiler
- For det første, hvis du ikke allerede har gjort det, skal du adskille din forretningslogik fra dit præsentationslag (HTML, skabelonmotorer, ...) og databaselaget
- tilpas derefter dit databaselag, så det kan leve med en alternativ DB (lokal SQlite kommer til at tænke på) og udfør synkronisering, når den er online igen
- Brug endelig PHP-Gtk+ til at oprette en ny brugergrænseflade og pak alt dette med bcompiler
Version 2:"Standard":Tag din server med dig
- Se på Server2Go, WampOnCD og venner for at oprette en "dobbeltklikbar webserver" (Start ved Z-WAMP a> )
- Du skal stadig tilpasse dit DB-lag som i version 1
Version 3:"Web 2.x":Flyt applikation fra server til browser
- Flyt din applikationslogik fra serversiden (PHP) til klientsiden (JS)
- Gør kun din serverdel (PHP) til et dataadgangs- eller synkroniseringslag
- Brug HTML5 offline-funktionerne til at erstatte din dataadgang med lokale data, hvis du er offline, og til at gensynkronisere, hvis du er online
Hvilken er bedst?
Dette afhænger af, hvad du har, og hvad du ønsker. Hvis det meste af din forretningslogik er i PHP, kan det være uoverkommeligt dyrt at flytte det ind i browseren - vær opmærksom på, at dette også genererer en helt ny klasse af sikkerhedsmareridt. Jeg personligt anbefaler ikke porting på denne måde, men jeg anbefaler det til nye apps, hvis backing-DB ikke er for stor.
Hvis du vælger at beholde din PHP-forretningslogik, så er valget mellem 1 og 2 ofte et spørgsmål om, hvor meget brugergrænseflade din app har - hvis det kun er nogle få CRUD-former, kan 1. være en god idé - det er helt klart mest bærbare (i betydningen at tage den med). Hvis ikke, så gå med 2.