The bigger issue is not of client or server side controls. What's sorely missing is a recommended best practice pattern that mod-perl people should follow to package and deliver chunks of functionality. I'm sure everyone here has his/her own little framework of serving javascript, css, and html. I might release a super cool grid control to CPAN but it'll come with it's own perl code, it's own javascript code, it's own CSS , it's own images! There should be a well established usage pattern so someone just downloads the grid module, run the installer and it puts all the files in 'right' places. Of course, it's not possible currently since everyone has a different framework and different concept of 'right' place.
This is the biggest advantage of ASP.Net - not server or client side. One can be productively using a complex Charting control just by dropping a DLL in the right place. Choice is good but so is some order. It's about time mod-perl geeks start publishing at least suggested patterns to make this work. If anything, it's probably simpler to do in mod-perl world. - Praveen ----- Original Message ---- From: Michael Peters <[EMAIL PROTECTED]> To: Boysenberry Payne <[EMAIL PROTECTED]> Cc: Modperl Mailing List <modperl@perl.apache.org> Sent: Wednesday, April 25, 2007 12:52:36 PM Subject: Re: Perl and ASP.Net Boysenberry Payne wrote: > One of the draw back that seems to be evident to me as I've looked > into the client side frameworks is changes in the code are ought > of your control. WIth a purely server side solution it would seem > to give the coder the choice to upgrade when there is time, etc. > With the 3rd party frameworks they choose when you upgrade. > For the more stable solutions this is less of a problem. For the > newer technologies I've heard a lot of grumbling about having > to recode every time there is an upgrade... Huh? The JS in your project is always under your control. It's just like any 3rd party component (like CPAN modules). You only upgrade it when you want to. The only case that I know of where people pull in 3rd party JS components that aren't locally controlled are those that use YUI and pull in their publicly hosted files. (And this is only to boost download time since if every site using the YUI libraries uses the same URL, a browser should just be able to use a cached version). But even then you can specify specific versions. -- Michael Peters Developer Plus Three, LP
