Elegant PHP Architectures? 118
akweboa164 asks: "I work as a lone developer creating small to medium scale PHP/MySQL websites for different clients. I have been doing this for about two years now, and have tried different things as far as website layout/architecture goes. With sites that use the fusebox architecture, front controller (thanks J2EE), N-tier, to having a simple 'include(config.php);' line at the top of every file, I am left with the feeling that all of the sites I have created are 50% elegance, and 50% nasty kludge. I am left with a sinking feeling because I know that they could be better, but I lack to expertise and experience to make them that way. I am looking for overall architecture that is open and fits within the constraints of PHP (ie. relying little on OO) and separates logic, makes updates easy, etc. I wanted to ask Slashdot's crowd of web developers what their most elegant code layout/design web solutions were, and what advice would you dish out to new developers, as well as seasoned professionals."
Relying little on OO...? (Score:3, Insightful)
I am looking for overall architecture that is open and fits within the constraints of PHP (ie. relying little on OO)...
Why relying little on OO? What's wrong with PHPs classes and objects?
Simon.
(a semi-newbie to PHP)
Re:Relying little on OO...? (Score:5, Interesting)
PHP5 promises great features, but PHP4 still lacks lots of OO concepts.
You can do OO-like stuff without the points above but at the expense of no encapsulation and ugly hacks.
Some elegant constructs are hard to achieve in PHP, a statement like this (in java) would have to be dereferenced one by one by hand: Somebody who has already done some OOP would be able to find workarounds but PHP would not be a good way for a newbie to learn OOP.
Re:Relying little on OO...? (Score:2, Informative)
object.person.bart_simpson.say("Bite Me!");
wouldn't need to be dereferenced by hand.
However, this would:
object->person()->bart_simpson()->say("Bi te Me!");
Method calls that return an object can't be immediately dereferenced in the same statement. Those would have to be dereferenced one by one.
But I know what you mean though. It sucks that you have to do that
Re:Relying little on OO...? (Score:2)
From Object to Bart Simpson: that's a generalization/ specification, but the notation is more or less a class namespace thingy (either that, or an aggregation -- like System.out.println()).
This stuff is more confusing than the average teacher's example
Re:Relying little on OO...? (Score:3, Informative)
PHP5 promises great features, but PHP4 still lacks lots of OO concepts.
ok PHP hasn't the great OO features that other languages have (like java), but most of the PHP programs are written by one programmer and for producing HTML code which isn't the same thing as developing huge projects in an enterprise logic.
You can do OO-lik
Re:Relying little on OO...? (Score:2)
Let's say you want to use only one connexion handler in your database class (so that objects inheriting from it can use shared "insert" and "update" methods). What you'd do in a real OO language is to use a class attribute, shared by all your class instances.
Re:Relying little on OO...? (Score:2, Interesting)
Let's say you want to use only one connexion handler in your database class (so that objects inheriting from it can use shared "insert" and "update" methods).
PHP uses persistent connections for both mysql and postgresql (which i know), so I don't need to use only one connection handler, PHP will automatically use the same db connection anyway
These two examples are ugly, but only because of the language limitations.
Nope, poor design again. And I think that you are still missing the point. The langu
Re:Relying little on OO...? (Score:1)
kinda like a reference [php.net] to your database object, or any other object inheriting from it. Then to call $this->db->query(). You could possibly even just include() the db class and db::query() from your object as php will use the same mysql connection as the poster above mentioned.
you have to use global variables
Not always, thats just one way. Each update to PHP brings changes such as tighter variable types and enforcing the syntax more, imo its matur
Re:Relying little on OO...? (Score:3, Insightful)
I love the product I'll mention, below. I'm not selling anything, either, but am just a "hooked" developer.... So, here goes.... (No flame wars, please.)
I'd look at CodeCharge Studio at their http://www.codecharge.com/ [codecharge.com] web site. It generates excellent PHP, does excellent database and forms work, and lets you adapt the code it generates. It's also a full-blown IDE.
Now, it DOES make heavy use of OO,
Re:Relying little on OO...? (Score:2)
WTF does this mean? How is object orientation incompatible with open APIs? Do you know what you are talking about, or are you just a marketing idiot?
Re:Relying little on OO...? (Score:2)
Did you read my comments in the context of his request?
In other words, this product does not address every goal he had, but many of the things he wanted are in there.
Re:Relying little on OO...? (Score:1)
At the risk of being modded down as a troll, frankly there is no objective open evidence that OOP is superior. All the cliches about reuse and abstraction and making long-term maintenance easier just do not hold water upon closer inspection.
Sure, OO may fit the way that *some* people think better, but every head is different.
Re:Relying little on OO...? (Score:1)
As far as web backend development goes, I haven't really seen much of an advantage using OO as opposed to just batches of functions. As you said, it can depend on how your mind works. It does keep things a little neater, but is it worth it at the cost of performance?
Can anyone offer a particular technique they've used in PHP which could not have been done without OO?
Simon.
Re:Java View/Model/Controller (Score:5, Informative)
There is no Java MVC for the web. You either roll your own or use Struts or Webwork or Maverick et al. MVC is a design pattern, which was correctly stated.
That, however, was the extent of any correctness. The Model is the data, which in her case would be the MySQL held data. The view would be a generated html page, JSP, Velocity Template, XML/XSLT pipeline, or whatever display technology you would use. The controller would be something that receives requests from a web browser and then decides what action to take (pull data from a database, massage it, return it, and show a results page). Accessing the data is handled by Data access objects or delegates.
If you don't know what in tarnation someone is talking about, don't moderate it down or up, just leave it.
I am going to start using that line at work though. "If we use java this way we will be akin to apple!"
Re:Java View/Model/Controller (Score:1)
Re:Java View/Model/Controller (Score:2)
Dude, don't worry about it. (Score:3, Funny)
Re:Bite the bullet... (Score:1)
Re:Bite the bullet... (Score:2, Informative)
web apps just aren't there yet (Score:5, Informative)
Personally, I deal with different technologies, using ASP.NET (the horror!) to craft a rather random assortment of inhouse management tools for an IT organization, but many of the issues we face are the same. From ye olde days of ASP 3.0 with the ugliness of "includes" to a modular, n-tier approach, I'm always left with an unshakeable feeling that things could have been done better. The kludge that is modern web application interface (that is to say, HTML, J(ava)Script, etc) are too scattered and poorly supported to make anything approaching an "elegant" web application. (Btw, I'd love to be proved wrong here
Here are the few suggestions I have which I can confidently say have improved my productivity. There probably the same things that everyone has come across, but maybe if I throw them out here I can invite some discussion.
Separate the task-at-hand and its implementation logic from the presentation layer. For instance, I normally write all of my business logic and database code as if it were just going to be an entirely separate library, and not particularly targetted towards web dev. This not only enforces solid library design principles, but allows me to debug and test using simple command line interfaces to the library. Approaching your code from a new direction (in this case simple user apps) frequently opens up entirely new ideas and perspectives. Once you've done this, the majority of your "behind-the-scenes" web code can just be a wrapper for this library, and then all you have left is the presentation logic. This has helped me immensely in the areas of scalability/integration and portability.
Second, never ever do any cosmetic presentation work until you're absolutely sure you have a beta (or better) quality base of business logic you're prepared to stand by. Adding the presentation logic to a web app too early is sort of like munging in command line options to a good ole console app: if done improperly, things quickly get out of hand and you have to code in more global scope hacks than you'd like to admit. Personally, after many bad experiences with this problem, I do *all* my testing on blatantly ugly hand-crafted html pages until I'm sure I've got things right.
Third, don't focus on a "page" as a discrete, targeted development object. Rather, the actual pages should be afterthoughts. Try to engineer solid "user-interface" components, and then plan on the final web pages as simple composites of these components. I estimate that, when I sketch out my initial concept of the pages and interface layer of a web app, more than 50% of the various tasks presented to the user will change drastically in scope before I'm even done developing. You realize that certain tasks just aren't needed, certain things are inconvenient, etc and using a component model to the presentation layer helps reconfiguring immensely. One of the biggest frustrations with web application is that, when different ideas are flying through your mind, its difficult to figure out all that must be coded in order to test them out. You think, "hmm this might work!" and find yourself having to chase down random bugs and make changes in five different files just to get a prototype working. Using a component model helps quite a bit in this department.
In terms of architecture, the only vaguely successful model I've come across is (once you've got a solid library backing you up...) model your application as a set of distinct user tasks. Allow each task to develop independently, and the step back and look at where the overlap is and what components are a good candidate for integration. Taking things on a task-by-task basis at the beginning helps immensely in bug detection also, because you're only focusing on one coherent progression of logic at a time.
I realize that most of this is probably old news to any qualified web dev, but this is the stuff I have to continually force myself to do after two years in the biz, so perhaps it is of some use. Any comments, suggestions, rebuttals, etc I'd be glad to hear.
Mike
Re:web apps just aren't there yet (Score:2)
Re:web apps just aren't there yet (Score:3, Insightful)
Agreed. HTML+DOM+JavaScript is optimized for e-brochures, and not business forms. Web stuff gets tricky when one tries to make HTML forms behave like real GUI's.
What we need *is* real GUI's over HTTP. Candidates include XWT, XUL, and SCGUI (my pet fav).
However, if we must live with HTML+DOM+JS for now, then my adv
Re:web apps just aren't there yet (Score:2, Insightful)
Thanks, reading now...
Don't forget the CSS. By using overflow:auto on a fixed box you can make scrollbars, and emulate many types of layouts previously impossible without crummy old frames.
Re:web apps just aren't there yet (Score:1)
What we need *is* real GUI's over HTTP. Candidates include XWT, XUL, and SCGUI (my pet fav).
What about converting "web apps" to web services? seems like this would solve the problem rather nicely, at least foo certain types of applications. You can write the back-end in whatever you want, using standard web languages, but instead of an http front end, you just write up a client, which would be relativley easy, as all it does is gather the info and send it out over http (or SOAP). Since the fornt en
Some suggestions (Score:5, Informative)
I like PHP alot for web development. I found it easier and less to code when compared to perl (I've done both for 3 years each). You've made a good choice with it. I haven't tried python, but i do hear good things about it.
One important advice I would give is.... learn from your repetition. Meaning.. if you see that you code very similar functions or code segments that very ever so slightly, maybe there's a new function in there, that could emcompass them all.
For example:
some times the elegance is in the hack. I rewrote an art project at the company I work for, using our product for the front end, and php for the backend within 6 hours. He originally wrote his from concept to product in a year. Not bragging, just saying. =)
Look into some of the templating engines, like smarty.php.net, it's srecommended at a number of sites (I haven't used it yet), but it will allow for cleaner code, and that's what is important. Accessing code you can easily fix, and change the presentation when needed.
Re:Some suggestions (Score:1)
I am skeptical of that. Do you have a specific code example? Many things that are put into "objects" could have been put into dictinary arrays instead, for example.
Re:Some suggestions (Score:2)
the poster asked about php for web development and I respond in terms of his request. I've done enough web development over the past 6+ years, with open source software specifically, to respond.
Re:Some suggestions (Score:1)
PHP handles OOP (Score:2)
Granted, it isn't Java, but that isn't any reason to avoid them altogether or to avoid the tremendous amount of benefit that can be obtained from one.
jason@php.us
My PHP tips (Score:5, Informative)
I don't claim to be an expert PHP developer, but I have spent a fair amount of time with it. Here's what I've found works:
Re:My PHP tips (Score:3, Informative)
Re:My PHP tips (Score:1)
Re:My PHP tips (Score:2, Informative)
Not only that, but in case you have some code in base.php that is not called as a function (for example your DB link), put something like this at the top of base.php:
if (!isset($somekeyvar)) die();
Then make sure you set $somekeyvar in everypage. This will make sure that code isn't accidentally run when some (non-)malicious user goes looking around.
Alternatively, include base.php from a path which the webserver does not serve, but still has access to. For example, crea
Re:My PHP tips (Score:3, Funny)
if (!isdefined("real")) die("hacker");
and
define("real", 42);
would be better.
Re:My PHP tips (Score:1)
Re:My PHP tips (Score:1)
Re:My PHP tips (Score:1)
If your include files are just classes or functions, then the user will just get a blank page. No output will be shown because no functions are called.
If they're not just classes or functions then...er...they're wepages and you want them to render
duh, don't put them in your public web tree (Score:2)
Re:My PHP tips (Score:1)
that way the code is run by default (not displayed) but you can also tell apache to handle
its also just a good way to tell the difference (like using
Re:My PHP tips (Score:2)
Take what the above poster said, but use base.php instead of base.inc.
No, use inc and use an .htaccess file to block all requests for files with extension ".inc". You don't want these include files to ever be executed unless it is from inside of a PHP script. As Rasmus Lerdorf calls it, "executing code outside of its context".
Re:My PHP tips (Score:2)
Template Systems (Score:2, Insightful)
Imperator wrote:
There are some who would strongly disagree with you on this point. For some interesting arguments against templating systems written in PHP, check out this article at phpPatterns [phppatterns.com].
Re:Template Systems (Score:2, Informative)
If you have to hand off your code to another person who will be doing primarily design, for instance customizing the "look and feel" then using separate templates is really valuable. You will drastically cut down on "bugs" caused by changes in the logic introduced by a designer changing code accidentally.
Even if PHP is the templating engine, separating the logic is important.
Re:My PHP tips (Score:1)
That is very difficult unless you stick with a wimply SUBSET of both OO and relational, getting the worse of both worlds. OO and relational are two very different things that don't match up one-to-one for the most part. Further, relational can be a high-level tool if you know how to use it, not a low-level service to just be wrapped over with flat API's.
If you mean putting wrappers around raw SQL calls, then I fully agree. But, you don't need OOP for tha
Re:My PHP tips (Score:1)
Re:My PHP tips (Score:2)
Re:My PHP tips (Score:1)
Just Another Hacker's Advice (Score:4, Interesting)
(Sorry about the code formatting. Slashdot's messing with it, and dinner's on, so no time to futz with it).
I make few claims to writing elegant PHP, and I'll generally sacrifice a few extra CPU cycles if it will save programming time. I have yet to run into a situation, even on high traffic sites, where this isn't a worthwhile tradeoff, as long as you're not writing horrendously inefficient code. If there are bottlenecks, I'll look to sections of code that are getting hit a lot and optimize on that level. You might have guessed that I'll take the performance hit and use objects if I feel like it will make my job easier. There are fancy names for most of this stuff, but never mind those for now.
What I do depends largely on the scope of the project, but there is one rule that I follow without exception. Nothing goes into the page that's being displayed but control flow statements and variable output. No assignment, no (god forbid) database calls, nuthin'.
For simple, one page, this-will-be-dead-in-a-year stuff, I put this at the top of the page:
and all the work goes into index_code.php. Beyond that, for this level of work, I don't worry much about elegance beyond the usual rules of breaking discrete bits into functions rather than allowing everything to string on for screens and screens of scrolling. This is mostly for my own sanity.
if($foo) { doStuff(); } else { doSomethingElse(); }
is much easier to make sense of than if all the work is sitting in between those conditionals.
For larger applications, I use a config file that contains any configuration I might need. Again, as little logic as possible. This is likely to be shared site-wide. An initialization file, also often shared, contains any beginning work that might need to be done. Checking to see if variables should be pulled from $HTTP_POST_VARS or $_VARS, calls to authentication routines if necessary, etc.
This will be driven from one file who's job is to figure out what needs to be done, and dispatch the work accordingly. Again, depending on scale, this may also contain common footers and headers. For bigger projects, all this does is dispatch the calls, and HTML is pulled from a template file, with content being inserted into it.
The dispatcher will call the appropriate code file and a matching file that contains the HTML and any required control flow stuff (as above) for content display. The code file doesn't contain anything "deep." Anything remotely heavy is done with classes included from a lib/ directory.
This structure gives the following benefits:
One last note. I don't use a templating engine. Things like smarty are nice and all, but with a little discipline, you can achieve the same effect with no added complexity.
Seeing as the post has a zero flame content, I will add that nothing I do in PHP ever feels "elegant." For me, PHP is a pragmatic choice (widely available). The language itself (to me) has a cobbled-together feel. I'm sure that will change as it matures, but I find that things I do in PHP often have a cleaner feel in perl. I'm learning Java, and so far I'm getting the impression of language-elegance from it as well. On a purely aesthetic level, I think the language you chose has a strong impact on how elegant your solutions feel.
Re: I agree (Score:2)
I'd never want to embed SQL/LDAP/etc calls in a page and I always cringe when I see that. I'd rather have a function:
get_user_realname($username);
which might call:
db_connect();
db_get_data(key=>'username',valu e =>$username,retur n=>"realname");
db_close();
return($realname);
(and then I'd right db_connect, db_get_data, db_close as my own functions s
Please list URLS people!!!!! (Score:2, Interesting)
Please, show me some really well done mySQL/PHP stuff, who is setting the trends?
Re:Please list URLS people!!!!! (Score:1)
I can't really point you to any URLs as I don't really know any. I can tell you what we do at dealnews.com. That may not be what you want, but it is all I have to offer.
We have a library or as we call it codelib of about 300 different files. Some are classes, some
Re:Please list URLS people!!!!! (Score:1)
So, yeah, check that out.
Page based doesn't scale (Score:2, Insightful)
Re:Page based doesn't scale (Score:2)
I think of my web-apps as applications, not websites, where the browser is the display component. I write one index.php that has a "command line" (an HTTP GET) variable that defines what the "action" is (and any number of other variables necessary)
the action defines what "page" you're looking at, and then I use a templating language (acutally, I hacked together a very ugly perl html::template port so i can use html::template syntax wh
Re:Page based doesn't scale (Score:2)
I definitely agree about page-based thinking not scaling. We've got an in-house CMS that has a page based admin feature that started to bother me about half way through development. It includes modules for more complex functionality that you add to each page. I would have tossed it for another metaphor, but quickly realized there was no way we'd be able to get client's heads around something without folders and pages. So I hid as much of what's actually going on as I could behind page metaphors.
Dying for
what I do... (Score:1, Informative)
Separating code and presentation: well we all should realize 100% separation is impossible, but you should try as much as possible. I've been having good luck with Smarty. Basically you write a bunch of PHP code that computes all
Re:what I do... (Score:4, Insightful)
I hope you are not implying to use objects for the sake of using objects. I use objects where they are needed. But in a language that is not bound to them, they are not needed all the time. I remember someone wanted to have a String class be part of PEAR. Why on earth do you need a string class in a language with such great string functions? I have seen object overkill and it is not a pretty thing.
Where do I use them? When I need to keep stuff "behind the curtain". We have a class to display large tabular data that we use. It is the right choice as we just call $report->addrow("data", "data"...); and the class keeps up with it all in vars for us and there is no mess.
So, use them where they are appropriate, is my advice.
Brian.
Phorum.org
ez systems (Score:1)
It's a cms system, written in object oriented php, and seems pretty comprehensive.
I'm holding out for a good server-side open source ecmascript interpreter(maybe mono?) with built in support for xml(e4x).
Good luck!
Here's an elegant way out... Drop PHP (Score:4, Insightful)
One kludge I rather dislike about nearly all server-side programming is the necessity of a connection to a relational database. Invariably, you must get into a lower level to get your data; often you are forced to write SQL for your data, and if your database is complex your queries can get pretty convoluted. There are tools to try to make that transparent, but the cure is often just as bad as the disease.
There are better ways, however. Zope [zope.org], a web application platform based on the Python [python.org] programming language, is my current favorite. The big feature that I like best about Zope, aside from the excellent builtin security framework (which is head and sholders above PHP, BTW), is the persistent object database -- with it, Zope can entirely eliminate the necessity of an external database. Not that you can't connect to an external database if you really feel like it; Zope has a built in connectivity API, and there are plugins for all your favorite relational databases.
Zope has many elegant means of managing your content, from your standard header-footer includes to context-based acquisition, to the many content management frameworks already built for you on top of Zope like Plone [plone.org]. Zope comes with two powerful templating languages if you don't like straight Python: DTML [zope.org] and Page Templates [zope.org].
That said, there are drawbacks: Zope is its own server, so you have to find a hosting company that offers Zope if you don't maintain your own servers. Zope.org lists a few free hosts on the main page. Using the object database is great, but because it's transactional your disk space can quickly bloat if you running a website whose data changes frequently, like, say, a popular forum or blog.
As for the language changes... if you left perl for php because perl was ugly (and believe me, I agree), then you should try python. The language is elegance personified. It's a scripting language, so it lacks the performance of Java or C++ for computation-oriented stuff, but the stuff it does, and the simplicity! Often I've seen three short lines of Python code take tens of lines of Java code to accomplish the same task. Python is so readable you rarely need to comment your code if your variable names are well named. It's also fully object oriented, but if you don't like OO for some odd reason, you can do your stuff with just functions.
Wow... what started off as just a few lines turned into a novel. Now I'm all tired and stuff. Can you tell I really like Zope and Python?
Re:Here's an elegant way out... Drop PHP (Score:1)
Re:Here's an elegant way out... Drop PHP (Score:2)
I should say that I was _never_ in the 10 years I program know for preaching my language/plattform of choice, but if you have gone to zope you'll love it and will never look back (at least surely not if you came from php/perl, and I did them both).
Just to add two things which I think randolpho above didn't mention (just skimmed the text), these are transaction safeness (never ever write db->commit() ) and it very friendly community.
Re:Here's an elegant way out... Drop PHP (Score:1)
Re:Here's an elegant way out... Drop PHP (Score:2)
Re:Here's an elegant way out... Drop PHP (Score:1)
For my own part, I just want to put up some pages (at home) without getting hacked during the next 14.13 seconds of running it. I don't know if that applies to Zope, but Zope _do_ use WebDAV, that on MS platform at least, has had some problems...
Re:Oh, the pain of Zope (Score:1, Informative)
Zope's documentation is painfully, hopelessly bad. That makes difficult to move to more challenging projects.
I love PHP's online manual. The inline comments left by other users frequently help me figure out some odd error I'm having.
I'd go on and on here, but I'm really supposed to be paying attention to my lecture here
Froggie!
Re:Here's an elegant way out... Drop PHP (Score:1)
Thanks... I'm really hot to start building stuff but not sure where to start...
---
Re:Here's an elegant way out... Drop PHP (Score:1)
I have been doing some interesting work... (Score:3)
Using PHP objects and the State Machine concept, I have been doing some things I think are unique, or at the very least interesting.
I am unable to send you to a specific site, since the bulk of my development has been for internal sites, developer/qa tools and so on. I can however say that taking this approach has made modifying my applications significantly easier.
I would be happy to talk further with this in email. I can be reached at the email address listed in my profile if anyone wants examples.
Designed urls, a cache, templating... (Score:4, Interesting)
Design your urls so that they're content based, and not implementation based, so where possible hide PHP from the user. Hide filename extensions from the user unless they need them. Use slashes to show content hierarchy (eg. domain.com/story/2003/6/4/ rather than domain.com/story.php?year=2003&month=6&day=4). The HTTP GET key=value pairs should be avoided where possible, unless there is no hierarchy or many items. You'll probably need url rewriting for this.
The url should pass to a script that checks the cache, and obviously request a fresh copy if it needs it.
The backend architecture depends on the app. PHP is usually for the web, and elegant architecture for HTML involves themes. Here you have three options,
Building the page as a string means that it's easier to have HTML flaws caused by one module affecting another (as PHPNuke has found). However, this is the most flexible method, if you want bizarre HTML. Dealing with strings is the older way of doing it, and I don't have much good to say about it this. In many templating engines the goal is to try and invent a simpler syntax, and then 2 years later they've implemented their own programming language. There is no such thing as simple logic when it comes to layout and HTML, and these "simple" languages often have little thought put into them, and don't allow reuse, or extensions via modules. They often end up being hacks. There are some mature examples that have solved this problem (PHP Smarty, who have simply implemented PHP in a templating language!) and these may be suitable.
Building the page using an OO means that you have a IMAGE object that has properties such as ALT text. That body object can only have certain other objects attached. You have a programatic way of dealing with a page, and you're not limited to a templating software's mini-language. However, you'll probably need to be a programmer to change the themes so you can't hand the code off to designers. It's the ASP.NET model, although there are better ways of doing it.
Building up a page in XML is elegant, in that you can refer to an XML node and attach/remove branches. You can pass nodes to PHP modules and let them attach content, knowing that all tags will be closed. You can enforce a schema/dtd on your content, and maintain a high-level language up until the moment that you publish to HTML, probably using XSL-T to theme the page.
The XML method is the best balance, IMO. XSL-T is very suited to formatting HTML, and if you want you can go to PDF via XSL-FO quite easily. I recommend building an XML file like XHTML 2.0 and then XSLTing that down to XHTML1/HTML for the cache.
As for how you handle the data, I don't really care. Personally I'm waiting for PHP5 to bother OOing my PHP.
My main gripe with PHP is that not enough is included in the default build that comes with distros and is offered for windows download. So that the generic hosts don't have the feature you need. The people who care about trim build know how to trim it more than those who don't care and end up avoiding features.
I was trying to respond earlier, but Slashdot still haven't unblocked a large...large range of IPs from posting (presumably it's not something I've done, as this account is available). Don't even bother emailing them folks, my 3 emails haven't got one answer :(
Can this be done?? (Score:1)
make_secure_connection();
do_login();
get_use r _profile();
do
{
display_menu();
}
while(do_stuff(get_choice()));
do_logout();
break_connection();
I just wish - things could be done so easily on the web. Most of the web sites that I'm developing could very easily have been console apps. But I'm stuck with PHP and tousands of $ signs that come with it.
Well, I've tried a lot to separate Business Logic from Presentation Logic - but it just doesnt happen, even though each php script o
Re:Can this be done?? (Score:2)
Daniel
Controller (Score:2)
Daniel
Re:Controller (Score:1)
Page based is not scalable (Score:2)
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^(.*\.html$|.*/$)
that way when a request for a page that ends in
the world is an easier place when
http://www.thebigchoice.com/Graduate_Jobs/IT_an d _M anagement_Systems/York/
is the URI instead of
http://www.thebigchoice.com/show_jobs.php?
Re:Page based is not scalable (Score:1)
It's not for people to read (Score:2)
url's provide a context for the content
s'all about the page ranking
The search parameter order randomness is not unworkable, it already does that for the last two items
http://www.thebigchoice.com/Graduate_Jobs/York/
and
http://www.thebigchoice.com/Graduate_Jobs/IT_an
yield (almost) the same page (the url affects the H1 you see)
SSTP (Score:2)
I feel you with every bit of my soul (Score:1)
Even with all this, I feel I'm programming faster, but still I can't get anything architected properly. I've examined hundreds of open source PHP classes and apps (freshmeat & phpclasses), but none of them really use a good architecture.
I'm beginning to feel like it's not
Re:I feel you with every bit of my soul (Score:1)
Use tools and frameworks (Score:1)
Recently I had to work in PHP as well; a friend of mine wanted a small website. It was quite a change!
I know Java has its drawbacks, but the tooling is becoming really good: Eclipse, code beautifiers, Javadoc, Junit, StrutsTestCases, Hibernate
Tooling for PHP is another matter. There are editors, there are Eclipse plugins, but nowhere near the level of Java (
Core Control (Score:2, Insightful)
I usually centralize the system initialization in a single file, ie index.php, system.php or core.php. This file usually performs the rudimentry stuff that all pages need, ie including config file, init database, calling authentication functions,
elegent architecture? try OpenACS (Score:1)
I agree very much with Randolpho's post. Ditch PHP if you really want an elegent architecture. If you really need to stick with PHP, try out Midgard [midgard-project.org]. Otherwise, you really ought to at least look at the alternatives. Zope and OpenACS are probably the best open source web application systems/environments/architectures, whatever you want to call it. I prefer OpenACS (there's just something about using a system that was built primarily by highly intelligent MIT and CalTech alumni...).
OpenACS [openacs.org] is based on AOL [aolserver.com]
Drupal (Score:2, Interesting)
Drupal [drupal.org] is a CMS which doesn't use the OO features of PHP, but has nonetheless an OO design: for example all content is a "node", and you can "subclass" a node getting a story, an image, a forum topic etc.
It uses hooks so it can be expanded easily; it has both themes a-la *nuke and templates. Of course it has a good user management system.
The core is maintained by few people (not me) in a very strict, almost maniacal
It's fast and powers sites like Kernel [kerneltrap.org]
You really want Zope... (Score:2)
PHP4 is problematic archectecture for what you ask. PHP makes profoundly stupid architecutral blunders like lack of namespaces for library functions, which makes it hard for someone else reading your code to determine where function X came from? Inline includes.evals of code are bad, bad, bad too.
You really want a MVC-ish sort of seperation of concerns, I suppose? Zope will do this: XHTML or XML Zope Page Templates, which are valid XML (code via attributes and XML namespaces) using the TA
Re:You really want Zope... (Score:1)
PHPTAL --- ZPT's for PHP [sf.net]
I have used all the other templating systems, Smarty, phplib, and have used templating systems in perl such as TT2 and find that ZPT's work out very well for keeping the designer happy and me as a programmer happy... Like Smarty PHPTAL is a pre-compiling templating engine, so you end up with quickly executing templates.Re:You really want Zope... (Score:1)
Easy enough to fix yourself, but I can send you an updated version if you don't like to bother with redo-ing work.. Just reply to this if you're interested.
Elegant PHP? That's tough. (Score:1)
I mean, first of all, how are you even going to load your libraries? Say you have a directory that contains your library of code. Call it "lib/TOGoS" (that's what mine is called). Now, say I have 'lib/TOGoS/TSDFEntrySet.php' and 'lib/TOGoS/TSDFParser.php'. TSDFE
Re:Elegant PHP? That's tough. (Score:1)
Re:Elegant PHP? That's tough. (Score:1)
I wasn't aware that you could put that in a
php_value include_path
As I was googling for how to do it just now I found that you can also do this:
ini_set('include_path','../lib');
Never knew of that function before, but it works!
It seems to be time for me to clean up my scripts, again.
Re:Elegant PHP? That's tough. (Score:1)
$base_fs_path = $_SERVER[DOCUMENT_ROOT];
require_once($base_fs_p a th . "/lib/file.php");
require_once($base_fs_path . "/lib/other.php");
If it's the case your app hangs off of the document root such as http://server.com/application then you would edit the $base_fs_path to be like this instead:
$base_fs_path = $_SERVER[DOCUMENT_ROOT] . "/application";
Now, this of course much more useful if you use a single "controlling" script fr
my solution (Score:2)
There are one or two hackish and/ or purely practical things about this solution, but you can write fast and elegant PHP code with it (which is why it was made -- I too found PHP lacking on this). The database
try this (Score:1)
Then I use composition or inheritance to extend these generic concepts into specific applications. (To continue my example, the child cl
Frameworks out there. (Score:1)
Phrame [sourceforge.net] has already been mentioned.
Eocene [eocene.net] (Looks very promising)
php.MVC [phpmvc.net]
Use MVC of Course! (Score:1)
mysite.com/control/index.php
whereas in my apache config, the control script performs controller type logic (e.g. request parsing and handling, session initialization, parameter encapsulation, etc.) and then requires the PATH_INFO as the the model (e.g. an Action if you were using Struts). Use Smart
Re:The only elegant PHP layout... (Score:1)
Cue stock footage of explosion at the punctuation factory...fade to black...
Re:The only elegant PHP layout... (Score:1)
I think you misunderstood elegant for unreasonably complicated and illogical.
And what is it with elsif? If you have a grudge against the e, trying to take it out of every situation possible, can you please keep this issue locked up inside?
PHP is just a better language in many ways. The only downfall of that is that bad programmers realize that, and learn to write programs before they learn to write good programs.