New and improved!

[smalpierre]

I removed the Slim framework as a dependency for my apps. Slim is about 500k, so it's small, but it has disadvantages.

1. It's another bit of third party software, and removing dependencies is good!

2. You build routes in index.php by calling a function passing the route match, and an anonymous function to call the controller, and whatnot - so you have at least 5 lines of code added to index.php for every route.

3. It does a lot of things I don't need, and I had to modify it to make the newest version work .. so if I download a fresh copy of the dependency I've got to hack at it AGAIN. Why wrap my head around that much code just to fix their bug?

SO - I replaced it with about 100 lines of PHP and a database table with 3 fields - an id (which isn't REALLY necessary, but my standard is to have an autoincrement primary key) and 2 varchar(255) fields. They could be longer, but my charset is utf8 which is multiple bytes per character (count on 3, possibly 4), AND the fields are indexed, so that cuts them back to 767 - but I have to divide by 3 to get my total field length ..

Anyway - 100 lines of code, and 1 table with 3 small fields - not bad!.

Slim has get and post methods (also put and delete I think) defined in the routes, and I'm not sure if I have to do anything special to make that work, but the primary stage is done.

Tonight, I'm going to add in all my routes (no admin tools yet, I've got to add them via sql queries so far) and test them - including routes that post. If post doesn't work, I'll fix that, then I'll export a table create script for mysql, strip it down to a barebones site with no frills whatsoever.

Right now my basic test site has a responsive layout that uses jQuery for the menu (yech! it's got to go, but I hate front end coding so it's there for now haha!), a few images, home, contact, login form, it's got the beginnings of a blog system, and a user login/register system, and - and it's UNDER 2kb! Keep in mind, that's including the SASS, and the CSS it generates for my template ..

I suspect it'll be around 1k or less stripped down to it's most base form with a basic working no-frills example.

 

[smalpierre]

Got it working with different request methods, but I haven't tested put and delete since they don't work with html forms - I'll have to test with xhr calls.

Well - technically it worked with whatever method, but you had to have a unique link. I added a method field in the database of varchar(6), and set a unique index of slug text + request method.

Major bugs are worked out afaik.

Tomorrow I'll strip it down, then I'm going to upload it to a server and start preliminary performance testing.

@"Genesis" It only took 4 days of coding, it was a lot easier than I thought it would be!

 

[smalpierre]

Ok, I take the easier than I thought thing back ...

It's all in matching a url to a link, but some things in the url that appear to be a directory are actually variables. It was late, and I borked it the first go around so I rebuilt the matching algorithm. That's when the headaches started.

I got it working again, but then I noticed it wasn't always matching correctly - so after staying up til 4am tryig to brute force it into submission, I called it a night and slept til 2pm. Now I'm back at it fresh, and had an epiphany - why didn't I think of this before???

I'm worried about the possible performance implications, but I'm sure I can work those out!

 

[strokerace]

Sounds like you are trying to reinvent the wheel!.

 

[smalpierre]

No, not really. I haven't found one that works the way I want. The system I've been using is close, but I don't like having all the routes hard coded in the index file, I want them in the database.

The pattern matching has somewhat kicked me in the soft bits though. I can match the strings up but it's inefficient. I've called in some of the big guns for backup though.

---

The performance issue is that I have to call a result set based on the first parameter from the url, then filter and sort in PHP instead of in the database before the record set is returned. Ideally I'd be able to send a request url and method to the database and pull a single record, but I haven't got that far yet.

 

[strokerace]

Like I said, its like reinventing the wheel. Have you files make calls to the DB will increase load on the server.
You can do the samething by creating a separate file and that will take the load off. They say the quickest way between 2 points is a straight line. Cut, reduce and throw away.

 

[smalpierre]

It's faster to read the database then parse a file by far. Especially when you start getting into a few hundred or thousands of links.

It's also faster for the database to make the match then it is to have a script do it.

It's also easier to manage. Also especially when you get into hundreds or thousands of links - AND when you have something like a blog, or forum where you have to create a route to user created content.

It's much easier to insert new routes for user created content - what are you going to do - parse the file, see if it exists, then write the route to the file? That's like a flat file database - extremely slow, clunky, and error prone.

The database IS the straight line in this case.