> > Well, I don't think its anti-taglib sentiment as much as it is > pro-provider cheering. Taglibs definitely have their place, and IMHO > can be a much more powerful mechanism for developing web applications > than conventional PHP or ASP code can. However, Providers are just so > much more powerful than Taglibs that I shudder at the thought that I > might one day have to go back to using PHP. >
Well, I guess I could come in on the other side... I LIKE taglibs for some things. They have some disadvantages, but its easy to avoid some of the pitfalls. My philosophy is to only use a taglib as a thin wrapper over some underlying perl modules. So in no case is there any LOGIC in my taglibs to speak of beyond "Go get the current user object from the session and call XYZ::somefunction(user)" or somesuch. In my XSP I can then deal with some of the XML generation, things like "Oh, I need to add in the links this user is able to see if they're an admin" kind of stuff. It also lets you tweak certain things. For example often I might have a link on a page that can only be seen from that page and otherwise my navigation is the same as all the other pages, so instead of having a different stylesheet template etc you can just have something like <sidenav> <nav:getstandardnav/> <morelinks> <link ..../> </morelinks> </sidenav> and my standard XSLT sidenav rendering template knows to add those extra links into the page if it finds any. And if you need to conditionalize them you can do it with an <xsp:if/> etc. Not that a provider can't do all that too, but then you have to figure out WHICH page your dealing with in the provider and have logic there to figure it out, or everything has to go in some datastore someplace, whereas if you defer that stuff to XSP it can be packaged up with the page. Not sure why everyone thinks XSP is hard to debug, you just have to be disciplined about your exception handling... These days I rarely run into much problem there since whatever classes I'm wrapping are always well tested and most other errors are either XML syntax or just bad logic in XSP (which I keep pretty simple anyway). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]