Slashdot Log In
Gallery 2.0 Released
Posted by
Zonk
on Tue Sep 13, 2005 05:18 PM
from the pretty-pictures dept.
from the pretty-pictures dept.
uss_valiant writes "From the Gallery website: "We are incredibly pleased to announce the release of Gallery 2.0! Over three years of design and development have gone into creating the best online photo management product possible. Gallery 2.0 is the natural successor to Gallery 1, and we hope that you like what you see. Don't wait, download Gallery 2 now!" From a developers point of view, the Gallery 2 framework is particularly interesting because it's written with modern programming patterns (OOP, extreme programming, test driven development, MVC, factories, modularity, ...) in mind which is rather unusual for PHP based projects. Over 1500 unit tests ensure correct functionality and its architecture is really impressive."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
FYI (Score:4, Informative)
The Gallery Project is an open source PHP project enabling simple management and publication of photographs and other digital media through a PHP-enabled Apache or IIS web server. Photo management includes automatic thumbnails, resizing, rotation, and flipping, among other things. Albums can be organized hierarchically and individually controlled by administrators or privileged users.
+5 Insightful! (Score:5, Insightful)
Re:+5 Insightful! (Score:5, Insightful)
Mods: The parent post was *informative*. See how it works? Not insightful, but informative.
Parent
Gallery (Score:3, Insightful)
Re:Gallery (Score:5, Informative)
All of this has now been fixed, with a robust user/group model with a permission "tree" ("view all sizes" implies "view full size" and "view thumbnail" for example), and the images stored in a dedicated data directory outside of the web server doc-root. They've also fixed that annoying "feature" of 1.x.x where it would output image URLs with the explicit host name used during the install. This meant for my old gallery, that all the image URLs were prefixed with my internal host name for the server, so you got no images when browsing it from outside (unless you had a real non-proxied connection to the Intarweb and could edit the local hosts file
Gallery 2 demonstrates the ease of use of a mature project. Upgrading within 1.x.x release used to be a bit of a chore, but after unpacking Gallery 2 to a new virtual server, a couple of MySQL commands to create and permissiona new database, all I had to do was browse to the new server, and tell it where the data was for the old gallery and it just got on with it. Detected all the image tools and preserved all the comments and metadata.
The "help n fill" on the local server paths is a bit spooky, but handy. The upload options are comprehensive, even supporting Xo's "publish to Internet" function, although I can't really reccomend that - it's very slow. The best option is to use Gallery Remote - a swing app that lets you just drag images, or folders or zip files of images onto it to upload to your gallery.
It even acts as a shop, letting your customers select images to buy from smaller versions and then making them a handy zip archive for checkout time.
Now I don't have to bother emailing pictures to family and friends - I just made them a user id each, created some groups, permissioned up the albums (and it supports inheritence too for permissions) and mailed people the link
Fantastic job guys.
Parent
PHP != Crap Code (Score:5, Interesting)
PHP has been a wonderful language in which to "put together quick solutions which grow into large projects" for me in fields from accounting to my current work in Industrial / Manufacturing! The interfaces you can write to control PLCs and generate plant floor intelligence using *good* PHP and a web server are light years beyond what is usually available on a shop floor with PanelViews and Vorne displays (Light bars...) Someone out there would be smart to write a PHP-for-software-engineering book.
Re:PHP != Crap Code (Score:3, Insightful)
This is the primary problem with languages like PHP. There is *NO* structure to them, no type strictness, no standard practices. ASP (original) suffered from the same problems.
JSP and ASP.NET have a lot better structure to them, and standard practices, not to mention tools that follow them.
Re:PHP != Crap Code (Score:4, Interesting)
I spent 4-5 years trying to get JSP to work as a "rapid development prototype to full scale application" environment, and I constantly ran into issues with Tomcat, Jasper, JAR file surprises, all of the warts that come with the Java language, etc... I switched to PHP for all "non-transactional" code when I did a study whereby I analyzed the amount of time it took one of my teams to react to "changing customer requirements" utilizing PHP/Apache as opposed to how much time it took another team of mine to react to similar requirement changes using JSP/Tomcat. I am not saying that JSP couldn't have worked, it's just that it seemed to not really have as many benefits as I would have liked for an environment that required as much agility as that which I found myself in.
I have to admit, my experience with ASP is nearly nill, as I have not been able to convince any clients to allow me to test out MS platforms controlling plant floor hardware.
All that being said, when my company writes something that requires "transactional integrity", we do pick Java for the backend... it's just that those situations in my field really are few and far between.
Parent
Re:PHP != Crap Code (Score:5, Interesting)
The problem with most PHP applications is that they don't scale. I don't mean that in a "PHP SUXORS! YOU CAN'T WRITE S$!@ IN IT"... I mean that most PHP applications aren't built with any real caching implementations (like this gallery software, or phpbb, or nuke, etc...) and the PHP frameworks that I looked at don't really provide that functionality.
The stuff availble for Java is just so much more powerful. You have the Hibernate [hibernate.org] OR mapping package that provides an amazing amount of OR work for you, including the ability to plug in multiple transactional caches, session caches, database connection pools (including the ability to have clustered caches across multiple boxes.) You have complex messaging architectures to talk to and keep multiple machines in sync. You have great web service APIs and great search engines that can be plugged in. Stuff to that degree just doesn't exist for PHP.
It often shocks me to see so many "Enterprise Level" PHP apps released with no caching implementation... you shouldn't see ANY home page hit a database on every hit. (And yes, you can easily avoid stale content by eviction, injection routines.)
So yes, you can definitely write decent stuff in PHP. But for the highly scalable enterprise environment, the libraries and packages that exist for Java and ASP just don't exist.
The other thing I hate about PHP is that there just is no IDE that is of the caliber of Eclipse for PHP (and PHPEclipse just ain't there yet.) A professional IDE allows me to introspect objects, trace stacks, change variables on the fly per hit and control each thread individually. This kind of power makes debugging and performance testing so much easier and more powerful than a PHP app. Good luck trying to seriously profile a PHP app...
So yea, PHP has it's place. It's wonderful for quick one-offs. I just wouldn't want to code a massive user load, transactional, high availability, multiple machine cluster application on it.
Parent
Marketing (Score:3, Funny)
Of course, it were a Microsoft product, the natural successor would be 'Gallery Super Uber Ultimate Edition'.
Re:Marketing (Score:3, Funny)
You sure you're not thinking of the "Street Fighter" series?
buzzwords check passed (Score:4, Funny)
Slashdotted (Score:3, Informative)
http://66.102.7.104/search?q=cache:EYRwD7JSrCoJ:g
How are the Debian packages? (Score:3, Interesting)
Hey, has anyone tried out the Debian gallery2 package? Does it do a good job of migrating the data, or does it install stand-beside? I have a gallery 1 installation that my whole family uses, and I'd like to know if it's safe to upgrade, or if I should wait for the bugs to be worked out.
Re:How are the Debian packages? (Score:5, Informative)
FWIW, I uploaded version 2.0-1 of the Debian gallery2 package this afternoon - it should be available in Debian unstable as of this afternoon's archive run.
Parent
Unit Test 1501 (Score:4, Funny)
Working download link (Score:5, Informative)
top three favorite features (Score:3, Informative)
- Upload a huge honking zip file of compressed images and create an album
- Integrated "Publish to Your-Special-Gallery" from WindowsXP "My Pictures" folder
- Easy to customize permissions
This (along with gnump3d) are my two FAVORITE web apps for linux.Give me a break. (Score:4, Interesting)
From the code I saw, everything is extremely over-engineered (read: too freaking complicated). It looks like they have some input sanitization functions but they aren't used consistently.
The coding style throughout isn't consistent (but who cares?).
On the plus side, they have used PHPDOC or some similar syntax to document their classes and functions (makes for good API docs). They have used external libraries for some things like templating and database abstraction (can't say much for their choices but at least they didn't rewrite those from scratch).
The error handling also looks particularly nightmarish:(repeated 12 times in one 100 line file!!!!)
Re:Give me a break. (Score:5, Informative)
As for the coding style not being constistent, could you please give an example? G2 has very strict code style guidelines that have to be followed for a patch to be accepted (you can find them on the g2 codex site which is currently getting hammered). The code may appear complicated but if you take the time to read things it's actually quite legible and it makes sense. Usually people who have not worked on very large team projects feel intimidated by something as large and complex as Gallery2, I know I was when I first started working on it.
I admit the
The error handling code works and I challenge you to find a cleaner way to let the developer know exactly where an error occured so they can fix it. Why does it occur so often? Because error checking is good, it's just too bad more people don't do it.
Parent
Re:uhh ohh (Score:3, Insightful)
But my favorite part is the bit about "test driven development." Of course it's test-driven... that's how programming generally works.
And Zonk... please tell me what the program is before telling me to "Clickey here! Download Now!". I'm not really looking for online photo management software at the moment, thank you.
Re:Nope, Not offtopic!! Re:What the fuck is Galler (Score:3, Informative)
Re:Uhm, been running on my server for months.... (Score:5, Insightful)
I've been using it in a high-volume production environment since April Fool's Day. We plan on dumping it next week and moving to our own code. It's a very nice system (and a tremendous leap forward from Gallery 1), but it's wedded to a folder organizational metaphor, and we need a richer taxonomy to support potentially tens of thousands of users.
Parent
Re:Big deal. (Score:4, Interesting)
Parent
Re:Not from my experience (Score:3, Informative)
Users who have reported "weird" redirects (you may be the third), always had a misconfigured webserver, which made their Firefox use the built-in (FF) google "I feel lucky" feature. So if you give your webserver a weird name and misconfigure the webserver, you end up on a I feel lucky hit from google for that search term.