Closed PHP - Simple Sort Column

lilpatotie · Apr 11, 2019

4_19-localhost_php_-_simple_sort_column_index.php_.png

In this tutorial we will create a Simple Sort Column using PHP. This code will arrange the table data in a sortable way by changing to ascending to descending. This code use MySQLi ORDER BY by adding a parameter ASC or DESC to change the arrangement of data in the table list.This is a user-friendly kind of program feel free to modify it.
We will be using PHP as a scripting language that manage a database server to handle a bulk of data per transaction. It describe as an advance technology that manage both server and control-block of your machine.

Getting Started:
First you have to download & install XAMPP or any local server that run PHP scripts. Here's the link for XAMPP server You do not have permission to view the full content of this post. Log in or register now..
And this is the link for the jquery that i used in this tutorial You do not have permission to view the full content of this post. Log in or register now..
Lastly, this is the link for the bootstrap that i used for the layout design You do not have permission to view the full content of this post. Log in or register now..

Creating Database
Open your database web server then create a database name in it db_sort, after that click Import then locate the database file inside the folder of the application then click ok.

05_16-localhost_127.0.0.1_db_sort_phpmyadmin_4.8.3.png

Creating the database connection
Open your any kind of text editor(notepad++, etc..). Then just copy/paste the code below then name it conn.php.

<?php
$conn = You do not have permission to view the full content of this post. Log in or register now.("localhost", "root", "", "db_sort");
if(!$conn){
You do not have permission to view the full content of this post. Log in or register now.("Error: Failed to connect to database!");
}
?>

Creating The Interface

This is where we will create a simple form for our application. To create the forms simply copy and write it into your text editor, then save it as index.php.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" name="viewport" content="width=device-width, initial-scale=1"/>
<link rel="stylesheet" type="text/css" href="css/bootstrap.css" />
</head>
<body>
<nav class="navbar navbar-default">
<div class="container-fluid">
<a class="navbar-brand" href="<a href="You do not have permission to view the full content of this post. Log in or register now.">Sourcecodester</a>
" rel="nofollow">You do not have permission to view the full content of this post. Log in or register now.">Sourcecodester</a>
</a> </div>
</nav>
<div class="col-md-3"></div>
<div class="col-md-6 well">
<h3 class="text-primary">PHP - Simple Sort Column</h3>
<hr style="border-top:1px dotted #ccc;"/>
<button type="button" class="btn btn-success pull-right" data-toggle="modal" data-target="#form_modal"><span class="glyphicon glyphicon-plus"></span> Add employee</button>
<br /><br />
<form method="POST" action="">
<button class="btn btn-primary" name="asc"><span class="glyphicon glyphicon-arrow-up"></span> Ascending</button>
<button class="btn btn-danger" name="desc"><span class="glyphicon glyphicon-arrow-down"></span> Descending</button>
</form>
<br /><br />
<?php include 'sort.php'?>
</div>
<div class="modal fade" id="form_modal" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<form action="add.php" method="POST">
<div class="modal-header">
<h3 class="modal-title">Add Employee</h3>
</div>
<div class="modal-body">
<div class="col-md-2"></div>
<div class="col-md-8">
<div class="form-group">
<label>Firstname</label>
<input type="text" name="firstname" class="form-control" required="required"/>
</div>
<div class="form-group">
<label>Lastname</label>
<input type="text" name="lastname" class="form-control" required="required"/>
</div>
<div class="form-group">
<label>Position</label>
<input type="text" name="position" class="form-control" required="required"/>
</div>
</div>
</div>
<br style="clear:both;"/>
<div class="modal-footer">
<button type="button" class="btn btn-danger" data-dismiss="modal"><span class="glyphicon glyphicon-remove"></span> Close</button>
<button class="btn btn-primary" name="add" ><span class="glyphicon glyphicon-save"></span> Save</button>
</div>
</form>
</div>
</div>
</div>
<script src="js/jquery-3.2.1.min.js"></script>
<script src="js/bootstrap.js"></script>
</body>
</html>

Creating PHP Query
This code contains the php query of the application. This code will save the employee data inputs to the MySQLi database server. To do that just copy and write this block of codes inside the text editor, then save it as add.php.

<?php
require_once 'conn.php';
if(You do not have permission to view the full content of this post. Log in or register now.($_POST['add'])){
$firstname = $_POST['firstname'];
$lastname = $_POST['lastname'];
$position = $_POST['position'];
You do not have permission to view the full content of this post. Log in or register now.($conn, "INSERT INTO employee VALUES('', '$firstname', '$lastname', '$position')") or You do not have permission to view the full content of this post. Log in or register now.(You do not have permission to view the full content of this post. Log in or register now.());
You do not have permission to view the full content of this post. Log in or register now.("location: index.php");
}
?>

Creating the Main Function
This code contains the main function of the application. This code will sort the data in the table when the button is clicked. To make this just copy and write these block of codes below inside the text editor, then save it as sort.php

<?php
require 'conn.php';
?>
<table class="table table-bordered">
<thead class="alert-info">
<tr>
<th>Firstname</th>
<th>Lastname</th>
<th>Position</th>
</tr>
</thead>
<tbody>
<?php
if(You do not have permission to view the full content of this post. Log in or register now.($_POST['asc'])){
$query = You do not have permission to view the full content of this post. Log in or register now.($conn, "SELECT * FROM employee ORDER BY lastname ASC") or You do not have permission to view the full content of this post. Log in or register now.(You do not have permission to view the full content of this post. Log in or register now.());
while($fetch = You do not have permission to view the full content of this post. Log in or register now.($query)){
echo "<tr>
<td>".$fetch['firstname']."</td>
<td>".$fetch['lastname']."</td>
<td>".$fetch['position']."</td>
</tr>";
}
}else if(You do not have permission to view the full content of this post. Log in or register now.($_POST['desc'])){
$query = You do not have permission to view the full content of this post. Log in or register now.($conn, "SELECT * FROM employee ORDER BY lastname DESC") or You do not have permission to view the full content of this post. Log in or register now.(You do not have permission to view the full content of this post. Log in or register now.());
while($fetch = You do not have permission to view the full content of this post. Log in or register now.($query)){
echo "<tr>
<td>".$fetch['firstname']."</td>
<td>".$fetch['lastname']."</td>
<td>".$fetch['position']."</td>
</tr>";
}
}else{
$query = You do not have permission to view the full content of this post. Log in or register now.($conn, "SELECT * FROM employee") or You do not have permission to view the full content of this post. Log in or register now.(You do not have permission to view the full content of this post. Log in or register now.());
while($fetch = You do not have permission to view the full content of this post. Log in or register now.($query)){
echo "<tr>
<td>".$fetch['firstname']."</td>
<td>".$fetch['lastname']."</td>
<td>".$fetch['position']."</td>
</tr>";
}
}
?>
</tbody>
</table>

There you have it we successfully created Simple Sort Column using PHP. I hope that this simple tutorial help you to what you are looking for. Enjoy Coding!

NOTE: I don't own this tutorial or application. I just share this for more knowledge.
Credits to the Owner

Yakultza · Apr 11, 2019

Para saan to paps? I.T.? Program?

lilpatotie · Apr 11, 2019

Kuehado-senpai said:
Para saan to paps? I.T.? Program?

IT po bossing. For website po baka magamit nyo.

Yakultza · Apr 11, 2019

lilpatotie said:
IT po bossing. For website po baka magamit nyo.

ah sige sige. salamat salamat

Arimsolavs1430 · Apr 11, 2019

pixkit · Apr 12, 2019

Cool but who is the owner so we can credit him?

pixkit · Apr 12, 2019

I'd prefer if we split the frontend from the backend api though so that they are:

not tightly couple
makes things simpler to read
makes the backend api reusable.

I'll try today to give an example of what I mean

aa1012 · Apr 12, 2019

it would be more sophisticated if we separate the data access and the frontend coding. it will be easier to manage, read, test and maintain in the future. It is also more secure. it would also be better if you use stored procedure or ORM in your sql queries to avoid injections and how data is persist from the database.

lilpatotie · Apr 12, 2019

Yes. It's also open for more development and suggestions. It will always be depends to the creator. Isn't it?

pixkit · Apr 13, 2019

aa1012 said:
it would be more sophisticated if we separate the data access and the frontend coding. it will be easier to manage, read, test and maintain in the future. It is also more secure. it would also be better if you use stored procedure or ORM in your sql queries to avoid injections and how data is persist from the database.

You are mistaken. Sorry.

Whether you go with my suggestion or go with the original tutorials workflow, both are flawed security wise. Both implementations are NOT SECURED. Period. I find it comical that you think what you are saying is secured. How can you say it's secured? There's no authentication in the first place, for example. Where's the encryption and enforced security policy?

Stored procedures are thing of the past. Why put your business logic in stored procedures? You are coupling your business on a particular db implementation.

Both implementations (mine and the tutorial) are open to SQL injection. But that's the not the point I am pointing out. I am pointing out that original implementation has tight coupling and makes the backend api not reusable.

Coupling and security are two different concerns. Bad coupling though makes security solutions harder to implement. Loosely coupled systems are easier to address.

-FakeNewz- · Apr 13, 2019

araling koto .salamat

pixkit · Apr 13, 2019

Sharing You do not have permission to view the full content of this post. Log in or register now.

You do not have permission to view the full content of this post. Log in or register now.

S01T004718 · Apr 13, 2019

add.php line 5-7 is a waste of space, line 9 is vulnerable for sql injection, use parameter binding instead.

pixkit · Apr 13, 2019

codewar007 said:
add.php line 5-7 is a waste of space, line 9 is vulnerable for sql injection, use parameter binding instead.

Well to be fair, most of tutorials like this one are just meant to be just a general tutorial. Security is really up to the person or team implementing the solution -- otherwise the tutorial will be huge if it's gonna cover everything. But you do bring a good point so for someone to say this pattern in the tutorial is more secure is indeed a myth.

aa1012 · Apr 13, 2019

pixkit said:
You are mistaken. Sorry.

Whether you go with my suggestion or go with the original tutorials workflow, both are flawed security wise. Both implementations are NOT SECURED. Period. I find it comical that you think what you are saying is secured. How can you say it's secured? There's no authentication in the first place, for example. Where's the encryption and enforced security policy?

Stored procedures are thing of the past. Why put your business logic in stored procedures? You are coupling your business on a particular db implementation.

Both implementations (mine and the tutorial) are open to SQL injection. But that's the not the point I am pointing out. I am pointing out that original implementation has tight coupling and makes the backend api not reusable.

Coupling and security are two different concerns. Bad coupling though makes security solutions harder to implement. Loosely coupled systems are easier to address.

You might just missed my point sir. The only thing Id like to point out is the way or his approach in making query of data from the database. and, in general, the coding scheme he use in the above tut. There will never be a secured approach weather you use repository and unit of work pattern, weather you implement tight security management elsewhere from the network level. nor from other implementations of security. it is a far achievable. only, I am giving advise to the op to at least apply the best practices.

"Coupling and security are two different concerns. Bad coupling though makes security solutions harder to implement. " - You seemed to be contradicting from this statement brother. In the first place, we(including you), programmers are following the implementation of repository pattern and unit of work for an instance, because of not just a decoupling to underlying data persistence but also for security reasons. why would you follow such pattern for nothing when you can just implement just like op did to his tut isn't it? so for me, following these good practices means a lot to securities concern, not directly equates but it has a tight relationship.

Impostor Syndrome · Apr 13, 2019

aa1012 said:
it would be more sophisticated if we separate the data access and the frontend coding. it will be easier to manage, read, test and maintain in the future. It is also more secure. it would also be better if you use stored procedure or ORM in your sql queries to avoid injections and how data is persist from the database.

Paki linaw nga to? dahil hindi ganito ang modern web architecture implementation.
1. Paano naging sophisticated ang decoupling ng frontend(UI) at data access layer / server (API)? familiar ka ba sa REST API?
2. Paano naging flexible and scalable ang ganitong design? Let's say gusto ko gumawa ng native mobile version at desktop version nung app, paano ko yun gagawin kung yung data access layer ko ay tightly coupled sa presentational layer ko? Gagawa ba ako ulit ng server at database dedicated para sa mobile device at desktop version ko?
3. If SQL injection is much of a concern, does using ORM would be enough and guarantee security from injection? note: ORM's are just db abstraction

aa1012 · Apr 13, 2019

maskhäçk said:
Paki linaw nga to? dahil hindi ganito ang modern web architecture implementation.
1. Paano naging sophisticated ang decoupling ng frontend(UI) at data access layer / server (API)? familiar ka ba sa REST API?
2. Paano naging flexible and scalable ang ganitong design? Let's say gusto ko gumawa ng native mobile version at desktop version nung app, paano ko yun gagawin kung yung data access layer ko ay tightly coupled sa presentational layer ko? Gagawa ba ako ulit ng server at database dedicated para sa mobile device at desktop version ko?
3. If SQL injection is much of a concern, does using ORM would be enough and guarantee security from injection? note: ORM's are just db abstraction

Sorry pero ang pagkakaintindi ko kasi, a good software architecture should consists of loosely coupled components such as classes or objects. In that way, one component or object is less dependent to each other and doesnt require the other object's response or presence. Hence, equates to a scalability, flexibility and maintainability. In what way? for instance, the application encounters an error within the somewhere the components, if each component is loosely coupled, then pinning down this error would be easy and will be isolated in less tedious manner. Going back to the op's tut/sample codes, those area where the data is being gathered and sent back to the database are jammed all over the place when it is even possible to separate it using different class or object to make it easier to read and troubleshoot. Another scenario is when you need to update something from the area where the system does its user input calculations? In a tightly coupling, you will be needing to repack the entire solution just to implement the changes you've made only from those area.

Question, kung mas okay pala ang tightly coupling, paano mo implement yan sa isang malaking project? at paano kung group of dev kayo working on a 1 big project? when your components are tied and dependent together? paano ang disperse ng workload nyo?

I dont know much about the Representational State Transfer nor about SOAP.

Impostor Syndrome · Apr 13, 2019

aa1012 said:
Sorry pero ang pagkakaintindi ko kasi, a good software architecture should consists of loosely coupled components such as classes or objects. In that way, one component or object is less dependent to each other and doesnt require the other object's response or presence. Hence, equates to a scalability, flexibility and maintainability. In what way? for instance, the application encounters an error within the somewhere the components, if each component is loosely coupled, then pinning down this error would be easy and will be isolated in less tedious manner. Going back to the op's tut/sample codes, those area where the data is being gathered and sent back to the database are jammed all over the place when it is even possible to separate it using different class or object to make it easier to read and troubleshoot. Another scenario is when you need to update something from the area where the system does its user input calculations? In a tightly coupling, you will be needing to repack the entire solution just to implement the changes you've made only from those area.

Question, kung mas okay pala ang tightly coupling, paano mo implement yan sa isang malaking project? at paano kung group of dev kayo working on a 1 big project? when your components are tied and dependent together? paano ang disperse ng workload nyo?

I dont know much about the Representational State Transfer nor about SOAP.

That's your claim, not mine. Let me rephrase your statement, Ang sabi mo "it would be more sophisticated if we separate the data access and the frontend coding. it will be easier to manage, read, test and maintain in the future ". - so you're encouraging tight coupling sa data layer at presentational layer as how this tutorial thread does it.

Question, kung mas okay pala ang tightly coupling, paano mo implement yan sa isang malaking project? at paano kung group of dev kayo working on a 1 big project? when your components are tied and dependent together? paano ang disperse ng workload nyo? - I should be the one asking that to you. since you encourage tight coupling of backend and frontend layers.

Pixkit and I share the same understanding with your statement that's why pixkit disagrees on you claim. Kaya ko tinatanong kase baka na mi-misunderstood ka namin.

pixkit · Apr 13, 2019

aa1012 said:
"Coupling and security are two different concerns. Bad coupling though makes security solutions harder to implement. " - You seemed to be contradicting from this statement brother. In the first place, we(including you), programmers are following the implementation of repository pattern and unit of work for an instance, because of not just a decoupling to underlying data persistence but also for security reasons. why would you follow such pattern for nothing when you can just implement just like op did to his tut isn't it? so for me, following these good practices means a lot to securities concern, not directly equates but it has a tight relationship.

I don't see where the contradiction is. Coupling and security are two different concerns. It's like designing the structure of your house versus adding security cameras and bodyguards. Both concerns can be addressed separately BUT if you design the structure of your house in a bad way, installing cameras or other security tech might be a challenge instead of being a straightforward activity.

Of course a simple house may not be such a big deal (a simple hello world program for example), but imagine a multi-room, mansion, or condo, or series of properties (imagine enterprise programs). Then your small problem has become really huge pain in the a$$.

pixkit · Apr 13, 2019

aa1012 said:
Sorry pero ang pagkakaintindi ko kasi, a good software architecture should consists of loosely coupled components such as classes or objects. In that way, one component or object is less dependent to each other and doesnt require the other object's response or presence. Hence, equates to a scalability, flexibility and maintainability.

Yes, this is true but it doesn't end with loosely coupled classes or objects. Yes, it helps in scalability, flexibility and maintainability. BUT and a BIG BUT, you are only looking at the small picture. It's like you're saying a good organization starts with a diligent and smart individual. Yes, that's true but the success of an organization needs more than just an individual person. You need a smart and diligent individual. There's no question in that but it doesn't end there.

aa1012 said:
Going back to the op's tut/sample codes, those area where the data is being gathered and sent back to the database are jammed all over the place when it is even possible to separate it using different class or object to make it easier to read and troubleshoot.

I think you are barking at the wrong tree. You are speaking of service vs persistence layer. I am speaking of decoupling the frontend and the backend. You can still have your objects, classes, service, service, and persistence decoupling in the backend. In fact you must do that in the backend. On the frontend, you do the same. For example, if you are using React on the frontend, you don't tightly couple your presentational components with your state management.

It's like you are arguing who is the best actor and someone is arguing who is the best actress. But what I am arguing is the relationship between the actor and the actress.

aa1012 said:
Another scenario is when you need to update something from the area where the system does its user input calculations? In a tightly coupling, you will be needing to repack the entire solution just to implement the changes you've made only from those area.

Again you are barking at the wrong tree. You are the one who said it's better for systems to be tightly coupled. But it looks like you are changing your tune here?

aa1012 said:
Question, kung mas okay pala ang tightly coupling, paano mo implement yan sa isang malaking project? at paano kung group of dev kayo working on a 1 big project? when your components are tied and dependent together? paano ang disperse ng workload nyo?

I dont know much about the Representational State Transfer nor about SOAP.

Again it's you who said tightly coupled systems are better and offers better security. So I don't know why you are asking us that. We should be the one asking you.

REST and SOAP are totally different topics but again tightly coupled systems may make REST and SOAP difficult for your organization.

Closed PHP - Simple Sort Column

Eternal Poster

Attachments

Forum Guru

Eternal Poster

Forum Guru

Forum Veteran

Honorary Poster

Honorary Poster

Honorary Poster

Eternal Poster

Honorary Poster

Honorary Poster

Honorary Poster

Addict

Honorary Poster

Honorary Poster

Honorary Poster

Honorary Poster

Honorary Poster

Honorary Poster

Honorary Poster

Similar threads

Popular Tags

About this Thread

Online statistics