> We (AxKit and Cocoon teams) spent about 2 months on the > [EMAIL PROTECTED] list hardening the XSP spec between the two teams, > and made promises to never break backwards compatibility (though we did > deprecate a couple of things, which you'll get warnings about in your > error log if you use them in AxKit).
> Hope that helps. It does. Hearing stuff like this is good news. > Seems to me like we need to add a task to the TODO list - an XSP "Best > Practices" document, that covers this sort of thing. That would be great. > I consider the taglibs on CPAN (and thus the ones we're using in the demo > site) excellent for quickly hacking together single purpose throwaway > scripts, but not useful for large applications. That is, in my opinion, > why TaglibHelper and SimpleTaglibHelper kick ass, and make AxKit's XSP > much better than Cocoon's (even though they're ultimately the same beast). I also got this impression but, your right Willers module does kick ass ;-). > Then they become single-use. *That* is the point. With XSP you don't have > to return XML, you return a structure like you might normally from a > method call. That way your code behind the taglibs becomes your > "Middleware" - useable from a multitude of applications, not just XSP. I see your point about single-use. However, with the requirements of our next site that is not the case. They would be multi-use. Here is an example. Requirements ============ - Provide internal objects/services/etc... That will return data in XML and ultimately transformed. - Provide external access to certain objects/services/etc... Implementations (that I know of right now :-) that will use xml data) ===================================================================== 1. "Regular" ole pages that will get/transform/display data. 2. A "service" that a customer will be able get meta-data/data from. 3. A "service" that we may use to get data from for a client side binary admininstration application that we may be distributing to our customers. Example Implementations ======================= Say I ran a content driven site and I needed to provide a list of catagories. - For Implementation 1. As you can imagine I want to display a list of categories on my left navigation lets say. For this I will use the typical get/transform/display data. I need to get the data in XML so my returning xml from objects holds true. - For Implementation 2. The various customers we have need to get a weekly updated list of categories. They will then use this data to build links on their site to our categories. Our "services" will be enables via soap. So returning xml from the objects will fit well into simple soap wrappers. - For Implementation 3. We will also use the soap services. So right now I dont need a non-xml public interface. But, you are correct it could be a problem at some point. I am going to try and not make this mail too long and I am going to follow up this week with some contrasting sample code of XSP vs. CGI (or Mason or ASP) but, in the meantime I have a couple general questions about taglibs... It seems they export a functional interface. Do we then lose the benefits of OO programming? Or do I have to write my whole object model and make it available to my web app via wrapper taglibs? Here is an excerpt from "Writing Apache Modules" that concerns me. On p.44 Stein is talking about the functional vs. OO interface to CGI. In the footnote he states the following... "Although it's handy to import function definitions in this way, there's a significant memory overhead for every symbol you import. If you have alot of scripts that import from CGI.pm your httpd processes will eventually become too large. Your can avoid this by precompiling and importing CGI's function calls from withing the Perl startup script by using the command use CGI qw(-compile :all). Alternatively, you can use CGI.pm's object-oriented calling syntax, which does not carry the symbol importation" Does this illustrate a weekness with a functional symbol heavy interface performance issue regarding tablibs. Maybe not for a small site, but with any kind of usage it would seem it your site is "taglib heavy" this could be an issue. A better implementation of taglibs would be an OO interface?! JF ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
