>
> 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]
