I don’t think this would work. It would have to be forwarded also. One other option would be to have “someone” have to deal with this kind of “lost” tickets.

Nevertheless … it’s a great ideia!

Your concern makes sense, so here’s my solution. You can have two kinds of situations:

1- You’re dealing with an external or outsourcing developer so you want to stick with his/her e-mail address on the @author tag. This way, if there’s a problem in the future the developer will be automatically contacted by the ticketing system.

2- You’re dealing with an internal developer, so the e-mail address will something@yourcompany.com, right? If the developer leaves the company you can and should immediately create an forward of his/her e-mail address to someone else.

I think the problem is not with this attempted implementation but with company policies regarding their employees.

Just one note though …

“At a first glance, I could use the Reflection API to get meta-information about the code. Tickets could then be created and assigned to the appropriate person based on the @author doc tag.”

We live in a mutable world. At first glance I loved this idea but then I start thinking “but there can be many authors, employees often change companies”, etc

How do you propose to solve this kind of issues?

Just my two cents

Since it can include a series of templates, I thought it was in the same family as smarty. Silly me.

Maybe i’ll do a test case… the same document (huge table?) generated both by smarty and xslt and time the results.

One obvious advantage on using transform with xslt is that the View stays platform independent. That’s why I’m curious to test it performance-wise.

Thanks, you’ve given me stuff to think about.

André, regarding XSLT, I had some experiences using it but not for a whole website.

XSLT is the exact opposite paradigm of the Template View Pattern: the Transform View Pattern.

That means that it must render or “burn” any document before it is served to the browser. I’m not sure if it will scale, but you can of course deploy a cache layer on top of it.

I’m using those techniques at www.adegga.com and it has really been useful to use the Template View Pattern (with Smarty) to organize and schedule development.

Bruno, on the topic… have you ever worked with XSLT for templating a (whole) website? Do you have any idea whether it scales well or not?