UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> From Access To Php    
 
   
Penguin629
post Aug 27 2015, 09:43 PM
Post#1



Posts: 11
Joined: 19-August 15



Hi all,

I was looking at the guide below posted by Zocker.

I would like some suggestions on making the transition from Access & Sql Server to PHP.
If you were able to do it successfuly, what helped?

What translates well from Access and what will give me a hard time in PHP?

Thanks!


UA
Go to the top of the page
 
zocker
post Aug 28 2015, 03:31 AM
Post#2


Utterly Eccentric and Moderator
Posts: 4,055
Joined: 4-March 00
From: Bristol / Ipswich / Spain


hi, Welcome to UA welcome2UA.gif

Thanks for reading my Tutorial! I don't thnk that anything much translates from Access to web design in terms of software or functionality. What is relevant is that as an (fairly experienced) Access user, you should understand SQL and some (particularly string) functions in VBA. Thats because you need PHP to build HTML text. I think I can sum up with an extract from the tutorial. PHP fulfills the role of VBA (more or less) it is a similarly a procedural language and has much in common with VBA but is NOT RUN on our own, local computer:
QUOTE
Anyone and everyone can write a webpage using Notepad, perhaps the most basic usable text editor ( anyone remember MsDos Edlin?...) you must save it as yourfilename.htm however or your browser won't open it and display its content for you. A fundamental concept to bear in mind is that we are going to USE PHP at our server TO BUILD HTML 'RECIPES' for a BROWSER TO INTERPRET, php does nothing for us at all on 'our' side of the internet.

A good and easy to understand example of this text based approach is a command button which you would like to place on a web page. With MsAccess, to design a structure to cause a Form to close, you would go to your design view 'toolbox' and drag and drop a command button, which you might imagine to be real object, onto your Access Form, you would then write the code to tell it what the button must do (Error handling if you are consciencious then DoCmd.Close in this case) when clicked. (A 'wizard' also does all that for you.) In HTML page construction there is no 'command' button and you will become frustrated when you want to use one, this is because you are really writing a page, a set of instructions, a program. You are writing into your web page the instruction which is that part of your recipe which will be used (interpreted) by a web browser to create a button from its own 'larder' of webpage components…these are the instructions:

<html>

<input type='button' value='Close' onClick='run some code here to close window' />

</html>

So, just by using Notepad, you can create a command button on a webpage:

When the browser opens the file and obeys these instructions, you will see the familiar Close button displayed.

BUT: From a (say) MySql database, PHP will build (some of) these HTML instructions.




Try this: PHP basics


I hope this helps.....good luck! I cannot recommend XamPP enough!




Z
Go to the top of the page
 
jleach
post Aug 28 2015, 04:25 AM
Post#3


UtterAccess Editor
Posts: 9,814
Joined: 7-December 09
From: Staten Island, NY, USA


PHP as a language to learn is fairly easy to pick up on - it's buttoning down all the hatches and making sure it's secured that can be a real pain.

It acts as a middle layer in a standard 3-tier architecture: MySQL for the Data Layer at the bottom, HTML/JS/CSS for the presentation layer at the top, and PHP to go between them.

PHP can be procedural or heavily OOP based. I suggest sticking with the procedural end of things unless you're entirely comfortable with classes in VBA, if not more advanced OOP topics. That'll give you one less paradigm shift to have try and deal with at a time.


There's two different main ways that PHP can be used. Sometimes it's sprinkled in throughout HTML files, and when the file is processed those bits and pieces are looked at and resolved. I don't care for this approach myself as it tends to couple the HTML and PHP and doesn't lend itself well to forward management. I much prefer the other main approach, which is to use PHP to generate all of the HTML output, perhaps using some template html files.

Structurally, the files and flow in language pretty easy to deal with. You start with a .php file that someone will browse to, you typically use the start of that file to a) setup config stuff and b) include any other files you may need (you can think of various libraries as VBA references, but when you include files it's like building one compound file with all of the includes in the order that they're included, then the code actually runs based on everything that's been put together - thus it's important to note that #require_once is often safer than #include). Typical files to include are 1) a config/settings file, 2) a database access file that has a few functions for accessing the database, 3) a common functions file with various other stuff you'll need on a regular basis.

Session state can be a tough one to get nailed down sometimes, it's not something you need to use in Access at all really. Basically, you've got a $_SESSION array with a bunch of stuff related to the session. Http is a stateless protocol, meaning that if I navigate to another page in the same website, the http protocol itself doesn't know anything about that, but using the $_SESSION variables you can persist information from one page to the next. So, when someone logs in, you might say $_SESSION['user_id'] = $thisSanitizedUsername, and then on some other page you can see if isset($_SESSION['user_id']), etc.

It's also good to have a decent understanding of the http protocol and how it works. Basically, the client machine initiates a request, the request is sent to a server, the server's PHP (or other...) receives the request, handles it accordingly, and returns an http response, which is typically an HTML page (although it could be XML or JSON or whatever else, as often seen in web service development).


Especially in web environments, security is a big deal, and PHP makes it hard to do right. It's lackluster type system and quirky rules and exceptions make it a lot of work to properly sanitize all of the user input. Even error handling is a mess: there's various types of error handling, and the behavior of each of those various types is driven by a conglomeration of settings both server level and language level (and local scoped directives). It just makes it pretty hard to handle easily, so instead of focusing on writing logical code you spend a lot of time focusing on how to make sure someone's not trying to inject malicious code and making sure you're not reporting sensitive information back to the client if there's an error. Those are my two biggest gripes really (which can be gotten around to an extent by using various PHP frameworks, but then you need to know both PHP as well as how the framework is designed, so you're usually better at the start to just learn the PHP stuff itself and get it done and over with).


There's a lot of open source projects in PHP. Go download MediaWiki (e.g., the wiki engine used by Wikipedia) or WordPress and find the index.php and navigate through them. You'll see some stuff that looks entirely foreign, but often it's fairly straightforward without really needing to *know* the language.

If you're going to be doing serious work with the language, you'll want an IDE. Many use Eclipse, which I don't care for myself. I shelled out about $100 or so JetBrain's PHPStorm and it's served me well. Use MySQL Workbench for the database end. phpMyAdmin is the "usual" but it [censored], terribly. MySQL Workbench is the basic equivalent to SQL Server's SSMS.

PHP is a good language to learn to get into how basic web development works. Once you're familiar with all that (and have learned the as-of-yet-barely-mentioned HTML/CSS/JS end of web development as well), I suggest moving to a more solid web development platform like ASP.NET - but that's not very good for starters.

I actually used Zocker's writeup to get me started with it however long ago. I have a quick MySQL primer here as well: http://www.dymeng.com/techblog/mysql-primer/

Cheers,
Go to the top of the page
 
GroverParkGeorge
post Aug 28 2015, 09:13 AM
Post#4


UA Admin
Posts: 31,239
Joined: 20-June 02
From: Newcastle, WA


PMFJI:

I don't have anywhere near the depth of experience of James or Jack, but I have maintained a family website with asp.net for a few years. As Jack says, the heavy lifting is beyond entry level skills, but I found I could manage a few basic things just fine once I got the hang of C# enough to do what I needed. Plus there are tons of examples and demos on the internet, some easier to follow than others.

So, from my perspective, I would say, yes, start with PhP, but don't be too hesitant to move on to asp.net if that's where your work takes you.
Go to the top of the page
 
Penguin629
post Sep 1 2015, 05:09 PM
Post#5



Posts: 11
Joined: 19-August 15



Thanks for all the help Zocker!
Go to the top of the page
 
Penguin629
post Sep 1 2015, 05:13 PM
Post#6



Posts: 11
Joined: 19-August 15



Thanks for the suggestions JLeach. I have got Phpstorm but still getting used to the IDE. There's a lot more going on there than in Visual Basic Editor. So much stuff to consume and that's why it feels so over my head.

I realize on a high level there are similarities in using php & mysql vs. ms acces f.e. & sql server back end. It's just when I open up an open source project then I get lost. I feel like I should be stepping through code to learn how a php application works but then I'm still figuring that out in Phpstorm.

Thanks!
Go to the top of the page
 
jleach
post Sep 1 2015, 05:58 PM
Post#7


UtterAccess Editor
Posts: 9,814
Joined: 7-December 09
From: Staten Island, NY, USA


Phpstorm has a lot of stuff, most of which you don't really need. Focus on the main stuff... Set up the PHP interpreter, write and debug code. Similar with breakpoints, step through, etc. Initial setup can be a bit of a pain. Ajax calls are harder to debug.
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    17th December 2017 - 01:10 AM