Page 1 of 2
Updatable applications
Posted: Tue Apr 10, 2007 11:33 am
by Luke
I am writing an application that will be used by more than one client (this is the first application I've written that will be used by more than one client!!

) and I'm wondering what steps I can take to make sure that later on, as I find issues with the code, and I need to make updates, that it is easy to do so for all of my clients regardless of the visual confinements I've made for each of them. So, any advice you guys can give me to make my application as "updatable" as possible? Thanks!
Also, I'm thinking that some clients will need extended functionality that other clients will never need or pay for. I'm using the Zend Framework, so I'm also looking for ways I can make certain aspects modular so that updates do not effect how these features interact with the application. I hope this makes sense. Thanks.
EDIT: also, these modules need to be independently "updatable". This is getting quite complex, huh?
Posted: Tue Apr 10, 2007 12:23 pm
by Oren
You want it to update each application automatically?
I don't see how you can do it in real-life, you want to log into their servers and then have PHP automatically replace old files?
This can lead to serious security flaws...
I believe that the best way is to do it manually for each application... after all, how many clients will run this application? 3,4,5?
If you still want it done automatically using some software, I think you should search for something else - not PHP. Maybe C?, Java? I really don't know.
Anyways, good luck and don't forget to update us during the whole process so we can learn from your mistakes/problems and from the good things too
P.S Maybe there is a real way to do it with PHP without any serious security flaws or any other permission issues which I'm not aware of, but currently I don't think this is the case. I'll change my mind once someone shows me a specific way/idea how this can be done with PHP.
Posted: Tue Apr 10, 2007 12:27 pm
by Luke
Oh no, it doesn't need to be automatically, I'll update the files, I'm just looking for design advice to make the application capable of being easily updated. I'm sorry for the confusion.
Posted: Tue Apr 10, 2007 12:40 pm
by Oren
I see. If so, then what's the problem?
Keywords: OOP, encapsulation, design patterns, coding guidelines and well-documented code.
Posted: Tue Apr 10, 2007 12:53 pm
by Chris Corbyn
You could set up a PEAR repository and update via PEAR?
Posted: Tue Apr 10, 2007 12:54 pm
by Christopher
I find one of the things that that makes this easier is to have an outer main view that defines the wraparound layout, and then have the specific modules only generate content for specific areas, usually the content area. I also have standardized module naming and put their files in sub-directories in the application code directory. I use the same code over and over by just editing templates and adding a new custom module or two.
PS - using a main View and the Response will hopefully be a good part of the
discussion about an example ZF application. As you are using ZF it would be great to get your comments about what is working and not working for you -- as well as comments about how you have implemented specific things.
Posted: Tue Apr 10, 2007 12:58 pm
by Luke
that's the kind of advice I'm looking for arborint (just fyi to other posters). When I get a minute, I'll come back and discuss this a little. Thanks guys.
Posted: Tue Apr 10, 2007 2:29 pm
by Kieran Huggins
I'm curious about auto-updating applications:
say one in 5000 page views triggers an update check, writes new files to the local file system. Feasible? Thoughts?
Posted: Tue Apr 10, 2007 3:01 pm
by Ambush Commander
Auto-updating is tough, mainly because there are sometimes other things that need to be updated.
On the simplest side, it may just be files. But there also may be DB schema changes, new configuration options, functionality that breaks plugins, etc, etc.
I think the first thing to address when designing an auto-updating application is a sane release policy. Make sure that there are no major changes in 1.0.x releases, etc. Then you can start tackling the technical and political issues. I sure as hell don't want PHP code that mutates automatically, so I'd want to turn auto-updating off.
Posted: Tue Apr 10, 2007 3:08 pm
by bpopp
I had a similar requirement at my previous job. I built a framework to manage websites for a half-dozen different customers, each with their own fairly unique website. All the websites did the same kinds of thing, but in very different ways. What I did was create a base class and central repository of objects that all the sites shared. The objects were things like People, Classes, Courses, Wikis, Forums, etc. Each of these modules in the central repository had its own default views (form.htm, index.htm, etc).
Each "site" was just a series of PHP pages that referenced these objects and each site had it's own Module directory that resembled the main module directory. The controller would look first in the "site" for it's corresponding view, and then resort to the default view if there were no customizations. This way, each site could invoke these base modules and still have it's own very unique views, images, css files, etc. We even gave some customers access to their own views so they could customize the look of the site without affecting other customers.
For the most part, it worked very well. The worst part about this system was that each site invariably had it's own views and when you made significant changes to a module, you might need to go change all the corresponding views. Early on this was a pain because I hadn't learned about using CSS to control styling and was making a lot of custom views for each site. I later learned to only put structured content in my templates and keep the design in CSS.
If I was going to recreate my engine, or improve upon another one, I'd set the view class to be able to accept multiple "view" directories as an array and then tell it to render the view by trying each one in order. I haven't seen a framework where this was documented, but it was very useful in this situation. That way you could do something like:
$this->view->SetViewDirectory ( array ( $appdir . "/views/", $enginedir . "/views" ) ); // most likely performed during configuration
$this->view->Render("index.htm");
If index.htm exists in the first directory, it would be rendered, otherwise, the view class would look in the second dirrectory.
Hope that helps some..
Posted: Tue Apr 10, 2007 3:31 pm
by Luke
thanks bpopp, it does.
Posted: Tue Apr 10, 2007 5:51 pm
by onion2k
Kieran Huggins wrote:I'm curious about auto-updating applications:
say one in 5000 page views triggers an update check, writes new files to the local file system. Feasible? Thoughts?
Updates should always be pushed to the user in my opinion. Relying on a site to get a certain number of hits before it checks for an update is too risky; it might be a quiet site with a huge security issue.
Posted: Tue Apr 10, 2007 5:53 pm
by Ambush Commander
Ideally, you'd have a cron job checking for updates. On a high traffic site, a probabilistic method (each hit has a 1 in 5000 chance of triggering an update) works quite nicely. For a low traffic site, you'll need to figure something else out.
Posted: Tue Apr 10, 2007 8:26 pm
by Weirdan
cron + pear + cascading everything like it's done in symfony (configuration, templates, etc.) looks like a solution to me. It doesn't solve the problem of db schema changes though.
Posted: Tue Apr 10, 2007 8:34 pm
by Ambush Commander
You really should take a look at MediaWiki's updating system. Open-source + heavy traffic + constant updates = a really good example!