I've been working on a little hobbyproject from time to time the past 1½ years, and have recently released it (http://phpFe.vigge.net/). It's basically a lightweight directory and file explorer/lister with some extra features such as sorting, RegEx enchanced searching and "friendly" URLs, and can be extended by an addon to turn it into a file manager (moving around and deleting files, renaming and uploading, etc.).
I'm interested in some critique on how I've implemented the features, and anything else you can come up with. Currently the admin addon defines some functions which the script attempts to use if the user is logged in (if ($admin) admin_firstcol (); for example), but I have thoughts on converting everything into a more OO-friendly approach and make it modular to easily add support for things like thumbnail generation and maybe some kind of gallery. However, as I don't have any OOP-experience I was wondering if any of you had any ideas on how turn this project OO in a efficient way, which I could then try to base my re-coding on.
Anyway, onto the code which, as it is pretty long I didn't know whether to post them here or not, I posted it on one of these so called pastebins, which will hopefully make them easier to read.
phpFe (0.7.2): http://pastebin.ca/510107
phpFe_admin (0.4.2): http://pastebin.ca/510112
Thanks in advance =)
Critique wanted for a small project - server file explorer
Moderator: General Moderators
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Well, I had a look at the demo and it looks nice. Visually attractive, valid XHTML, simplistic interface, URLS are great; well done.
Then I had a look at the code and that doesn't look so nice. OOififcation would be great but it would take me a small book's worth of writing to explain how you should go about doing it.
Then I had a look at the code and that doesn't look so nice. OOififcation would be great but it would take me a small book's worth of writing to explain how you should go about doing it.
Any specific recommendations when it comes to the code apart that I should aim to turn it OO?
I personally don't like to have both functions, output (and output handling) along with the general script in the same file since it makes it kinda hard to find stuff to begin with. However, as I'd like to keep the whole thing lightweight and simple I haven't decided to split everything up into multiple files. I will most likely do so when I convert it to OO, but I guess that won't happen too soon consider my lack of experience in it
Turning the output handling into some kind of template system has crossed my mind, but once again I'm thinking of the performance and lightweight-iness (in lack of another word to use) and the impact that would have.
I personally don't like to have both functions, output (and output handling) along with the general script in the same file since it makes it kinda hard to find stuff to begin with. However, as I'd like to keep the whole thing lightweight and simple I haven't decided to split everything up into multiple files. I will most likely do so when I convert it to OO, but I guess that won't happen too soon consider my lack of experience in it
Turning the output handling into some kind of template system has crossed my mind, but once again I'm thinking of the performance and lightweight-iness (in lack of another word to use) and the impact that would have.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Numerous. But it takes on average two full years to fully apply OO.Any specific recommendations when it comes to the code apart that I should aim to turn it OO?
"Premature optimization is the root of all evil". Maintainability and the quality of your code is of much greater importance especially when you clearly have no performance issues currently.as I'd like to keep the whole thing lightweight
You code looks very complex to me. If it was nicely refactored (no doubt this would involve separate classes in separate files) then I would be simpler. This is a book I can't recommend enough.and simple I haven't decided to split everything up into multiple files
Well don't. If you continue to do so you are a fool. If you know where something is likely to be a performance problem, like I know putting 10,000 individual pixels in GD is slow or moving a large file from one server to another via a internet connection is slow, then worry about it and plan for it otherwise you code for the benefit of yourself and other human beings. If performance was that important we'd all still be writing in assembly. If at the end you have something slower than you would like, use a profiler such as xdebug to tell you where you application is slow and you will be able to make informed performance tweaks that will have a large effect.once again I'm thinking of the performance and lightweight-iness (in lack of another word to use) and the impact that would have