This is something I've wondered about ZenPhoto for a long time. I thought about bringing it up when i read bug #391, but decided to ignore it. But I just had a conversation about the same topic in a different scenario, and it got me to thinking about ZenPhoto again. So, I want to ask why ZenPhoto generates XHMTL instead of HTML?

Before answering, take the time to read http://hixie.ch/advocacy/xhtml, and the Surfin' Safari article on the same topic. I agree with the conclusions of those articles. I think that unless you have a specific reason to target XHTML, you should be writing HTML 4.01 markup. In fact, I write all of my HTML to the 4.01 Strict DTD.

Those were some very good reads, I very much agree with the idea that one shouldn't use the newest technology just because it's there.

When I wrote Zenphoto originally it was my habit to write (and serve) true xhtml documents -- it went with the mantra at the time, of standards-based XHTML+CSS content+design (which is of course still good with HTML). I had fully intended to make Zenphoto XML-compatible for many of the advantageous reasons, but of course none of that panned out because of various reasons, mainly Internet Explorer.

It still pains me that we're reduced to not using a valid XML format [i]simply because Internet Explorer cannot handle application/xhtml+xml[/i]. By no fault of its own of course, it's just an older browser, but we have to deal with so much incompatible crap because of it that one more thing just drives me up the wall.

But, given that the intended use of Zenphoto is to render in a browser, and not be parsed by some XML system, I agree that HTML is the way to render it. My philosophy before was sort of "If internet explorer didn't exist, and we were moving forward, what would be the best format?" and of course XHTML makes perfect sense in a world that supports it fully. It is by nature a more general, abstract, and useful format from a developer's standpoint.

Frankly I entirely disagree with the sentiment that people are using the XHTML 1.0 doctype for "no good reason" - I mean, that at least gives you stricter validation from the W3C, and people are then more likely to have good code that's mostly compatible with DOM traversal etc., more likely to use CSS for layout, more likely to pay attention to their (X)HTML code, and thank God for the deprecated tags! Good riddance to ``, especially, and if that's the only thing to come of it, then that's good enough for me.

The argument is simply that we should use an older HTML spec because a) it's correct for what we're rendering, and b) it's easier to make it right (escaping `` problems, etc., and c) works better for older browsers.

So, I agree with you, we do not have a specific reason. But I am also not convinced that using the newer spec is in all ways worse, because I like XML in general and the idea that HTML can be defined in terms of this broader more flexible markup is very cool and general and certainly not worth [i]nothing[/i]. And even though that is a future ideal that isn't terribly useful right now, it also works in the real world as-is, so why [i]not[/i] use it and help the 'tag soup' approach a more generalized standard?

Originally XHTML should become the successor of HTML 4, but now that the W3 sort of officially abandoned that in favor to HTML 5 (whenever this might be ready) this might be seen as another reason to use HTML again.

BTW, hopefully someone saves us from Microsoft's idea of version targeting...

Quote:"Frankly I entirely disagree with the sentiment that people are using the XHTML 1.0 doctype for "no good reason" - I mean, that at least gives you stricter validation from the W3C, and people are then more likely to have good code that's mostly compatible with DOM traversal etc., more likely to use CSS for layout, more likely to pay attention to their (X)HTML code, and thank God for the deprecated tags! Good riddance to , especially, and if that's the only thing to come of it, then that's good enough for me."
Using the XHTML 1.0 doctype doesn't necessarily give you stricter validation. That entirely depends on the DTD you target. You recently changed ZenPhoto's target from Strict to Transitional XHTML. You did it for a couple of reasons, but the most applicable to this discussion is that ZenPhoto's "Strict" XHTML was definitely not strict. You can get just as strict validation by writing HTML 4.01 Strict markup. The same elements that are deprecated in XHTML 1.0 are deprecated in HTML 4.01 Strict.

Personally, I think ZenPhoto shouldn't return any markup at all to the template engine. In this case, just PHP mixed with markup that calls some "template" functions. I think that only data should be sent to the template. The template author can then decide which markup style he prefers. As it is now, if I were to write a ZenPhoto theme from scratch I would have to write an XHTML Transitional document. I have no choice of using HTML 4.01 Strict because there [i]will[/i] be some markup inserted into the template that I didn't write.

As for HTML 5. I haven't kept up with it. I've been busy with mathematics. But completely abstracting the data from the presentation makes it a moot point.

Quote:Personally, I think ZenPhoto shouldn't return any markup at all to the template engine. In this case, just PHP mixed with markup that calls some "template" functions. I think that only data should be sent to the template.
Some functions do return combined things like printPageListWithNav, that would get a lot more complicated for the normal user. But generally I agree that the template functions should return as less markup as possible.

I don't see what the "normal user" has to do with it. The only person that would be concerned with it is the template designer. I bet if you took a poll, most of them would prefer to have only the data. It allows them a lot more freedom with their design.

Let's look at the specific case you brought up. Here is ZenPhoto's nav list function:

`function printPageListWithNav($prevtext, $nexttext, $oneImagePage=false, $nextprev=true, $class='pagelist', $id=NULL) {

    $total = getTotalPages($oneImagePage);

    if (&#36;total < 2) {

            &#36;class .= ' disabled_nav';

    }

    echo "";

    &#36;current = getCurrentPage();

    echo "n";

    if (&#36;nextprev) {

            echo "n  ";

            printPrevPageLink(&#36;prevtext, "Previous Page");

            echo "";

    }

    for (&#36;i=(&#36;j=max(1, min(&#36;current-2, &#36;total-6))); &#36;i  1 ) ? &#36;smarty->assign('prev', 'true') : &#36;smarty->assign('prev', 'false');

if ( $total_pages != 0 ) {

/* Numbered links. */

for ( &#36;i = 0; &#36;i < &#36;total_pages; &#36;i++ ) {

    &#36;nav[&#36;i] = &#36;i + 1;

}

} else {

$nav = NULL;

}

/ Next page. /

( &#36;page < &#36;total_pages ) ? &#36;smarty->assign('next', 'true') : &#36;smarty->assign('next', 'false');

&#36;smarty->assign('page', &#36;page);

&#36;smarty->assign('nav', &#36;nav);`

Which, as a designer, would you rather have? The pre-formatted list that locks you into a design? Or the array of numbers? Agreed, they will most often be placed into a list and styled with CSS, but someone might have a different approach.
`

jsumners, if you wanted to start pulling the template code out of the function and put it back into the theme I'm sure no one would have a problem with that. It's a delicate balance but when the choice is made to put the template code into a function instead of the theme page, the function always accepts id and/or class names for theme reasons.

I haven't the time to overhaul how ZenPhoto's theming works right now. I'm able to contribute small patches during the little free time that I have right now, but something like that would take much more time than I can currently devote. The whole code base would have to be converted at once. If it were done little by little then third party themes would constantly be breaking. One huge conversion means everyone's themes would break, but they would only have to fix them once.

Yes, the current method of accepting custom themes and ids is a good approach for the theming as it is. But it still limits the designer to using the markup generated by the software. Which in turn limits the designer to the document type that the software targets (XHTML 1.0). Which we have already established is not relevant to the way ZenPhoto works right now.

I am merely suggesting that if it is decided to switch to HTML instead of HTML, completely abstracting the data from the presentation should be seriously considered. It would make any future doctype changes much easier.

Just to come back shortly: Regarding the flexibility of the printPagesListWithNav() (to stay on that example) to design, we have all the functions of these combined functions in separate versions, too.
But again I agree that the -markup in printPrevPageLink() for example is not really necessary and could be also added in the normal template html.

Okay, but that means there is a lot of redundant code that has to be maintained. All of that redundant code is also loaded every time the script is run. So by removing the markup from the source code you are not only making the source code easier to maintain, you are also making the program a little faster.

Jsummers:

Your argument seems to be that theme designers want to write all the code out to do their page. I doubt that is a universal desire. Even your example above decries this view. You have just created a "different" version of the support for printing pages--your 'smarty' object.

Personally, I'd rather have what makes my job easier. In some cases that is the underlying structure, in others it is the pre-canned output.

I suppose you can look at it that way, and in this case it is very much like that. On my site I use Smarty as a simple templating engine with caching support. There is very little "code" in my presentation templates. I let Smarty take care of merging my HTML with my PHP. So, my "index.php" contains nothing but PHP and allows me to concentrate specifically on the code. My "index.php" decides what data to pull from the database, assigns some template variables, and then sends control to the template engine.

But you're right. As ZenPhoto is now, that templating "engine" would be the template author dealing with all the data himself. If I were to branch ZenPhoto myself to implement the changes discussed in this thread, I would probably incorporate Smarty.

Take a look at http://www.smarty.net/rightforme.php and http://www.smarty.net/crashcourse.php. I think you'll have a better understanding of what I am trying to say. Of particular note, this is from the second link:

Quote:"As you can see, Smarty cleanly separates your presentation elements (HTML, CSS, etc.) from your application code. However, it does not necessarily separate logic entirely from your templates. With respect to Smarty's design principles, so long as the logic in the templates is for presentation only, it is permissible to use it. For instance, looping over table row colors or including one template from another would be considered presentation logic. This is something the application should not need to accomodate (it just supplies an array of data.) The idea is to keep the template designer role and application programming role separated. You should be able to completely tear down the templates and rebuild them without touching the code base, all while retaining full control of the presentation."
I think that states my position much better than I have been. Hopefully you can see how that would make your job easier overall.

jsumners, you're completely correct, and if I rewrote zenphoto that's exactly what I'd do.

"I haven't the time to overhaul how ZenPhoto's theming works right now." -- that's exactly why we haven't done it either. We're very much operating on a real-world working basis. The template functions were designed to output HTML and make creating a simple theme as fast and easy as possible at the time. Because I was starting from scratch, a lot of that ended up being abstraction of repeated HTML code, and thence was zenphoto born. More of my attention was focused on the image processing, data modeling, and administration aspects -- indeed the whole idea of themes was just to load a different set of PHP views based on a folder name. The theme engine was built this way because it was the simplest that worked, not because it was the correct or most elegant way. And it works for 99% of cases, and in those where it doesn't, Zenphoto's model is also flexible enough to only output data. If it makes more sense from an MVC standpoint, the template functions are helper functions for an HTML view layer. You could just as easily create a smarty template engine for zenphoto, or whatever else. Just replace template-functions.php with the view layer framework you want to use instead, or none if you please and keep all your view code in your views, but that would be equally messy.

It's not 100% correct and it's not always pretty but it works in nearly all of the cases Zenphoto is designed to support, and in cases where something else is required, it's still easy to get at the data. I think this is elegant in its simplicity and understandability and usefulness for its intended purpose.

I'm beginning to agree with you on converting to HTML 4.01 Strict, but I'm still a pragmatist and if XHTML 1.0 is working (which it is, without any complaints from the real world yet, afaik) then I don't see a reason to divert coding time to address the issue quite yet. I do see your point very clearly though, and if you want to do it you are certainly welcome to.

And, for the love of God, don't branch Zenphoto. It is a three-year-old project with a lot of built-up cruft and any good programmer knows you're better off starting from scratch at that point. If you would like to begin on Zenphoto 2.0 then we have some talking to do. ;-)

Glad someone sees my point

I understand where Zenphoto has come from, and I understand how a project can snowball to a point where fixing it is a headache. That's why you don't see me saying "this must be done now!" But if the code base really is going to be overhauled, and I've seen indications that it might be, then I want to get this topic on people's minds. That would be an excellent time to implement the changes.

I don't mean "branch" as in take the current code and start a new project with a new name. I mean take a current snapshot of the code, implement the changes, and submit it for possible merging with trunk. (As an aside, you'll probably find this article interesting.)

I might begin on Zenphoto 2.0 or whatever you want to call it after this semester. That's only ten weeks away. But right now, I have to focus on my senior project. I've actually been wasting precious time by browsing this site when I should be doing research I also have to see how busy summer semester will be; I'm thinking not very.

What any good software company knows is that you can never "catch up" when rewriting an application. That's because unless you freeze the current one, the target is a moving one. And, if you freeze the current one, then people stop using it, so there is no reason to replace it.

j - I've read that article, Joel makes some very good points as usual, but there's a point where major architectural decisions trump code re-use. That's how Zenphoto got started in the first place. My idea was originally to branch Photostack, but their "object-oriented" model contained two classes - a "Photostack" and an "Organize" - for the gallery and admin functions respectively. No OOP benefits to that and not much code re-use possible (especially as the rest of the architecture was of similar caliber).

I would of course use a lot of current Zenphoto code if we were to start developing ZP 2.0. The current zenphoto is built fairly well and has a great generic persistence framework that can be extended easily. For ZP 2.0 it's mainly refactoring and re-thinking that I'm talking about, so I think we both seem to have the right idea.

@stephen - It depends on how bad the original software is and how hard it has become to develop new features after 10-20 years of buildup ;-) I'm currently working on a scratch re-write of a major enterprise package (day job) and we've "caught up" and then some in a matter of months using new and better technologies that make development and maintenance orders of magnitude faster. The idea is to work on making the development process fast and efficient, then everything gets better real fast.

So while Joel is correct about code re-use in most situations, there are always exceptions. Or competitor's software is on top of a 15-year-old package built for aerospace engineering, they moved markets entirely, and hacked on new parts on top of the old technology just so they could go fast in the initial market. But now huge companies are suing them because the software can't do what they advertise; they simply can't make it scale or do anything efficiently. This is a case where a full re-write would have made enough sense, but it didn't make economic sense because they still have zero competition and probably wouldn't be able to catch up anyway. So we're doing it for them. So, I do not agree that rewriting from scratch is never a good idea -- I think that a good software company would not be afraid of doing that if it made sense economically, but that would be a very rare situation ineed.

Zenphoto is not in this situation. We've got a good codebase and a good foundation, so we'll be able to use a lot of it in refactoring with some new ideas as they come. Let's get there gradually though, 1.2, 1.3, 1.4, and then we'll think about 2.0 once we see how far we've come.

And, James, you going to join our development team already? ;-)

I'm up for joining if the team feels they want, or need, me. I like ZP, and had plans to continue its development on my own if it hadn't picked back up before I graduated. Of course, we know that has happened and I'm back to submitting patches. ZP is almost exactly what I thought I would have to write myself when I started looking for gallery software.

Cool! Well keep up the good work for now, I'll get the opinions of the other team members and see what happens.

I don't find anything wrong with XHTML 1.0 Transitional. Some people use HTML 4.01, others - XHTML 1.0. But I think most of today's websites are built using the XHTML 1.0 Transitional standard (a bit more rarely - 1.0 Srict).

If I was invited to vote, I'd have chosen the XHTML option ;-)

Cheers!

optimiced: Do you have any real reason for that choice? Or do you just choose it because that is the trend? If you read my first post, and the articles linked within, you will learn that there are very few reasons to actually use XHTML. In fact, there are many reasons why you shouldn't use XHTML over HTML.

I don't really view this as a matter of opinion. It is a technical matter.