Thanks for the advice Robin. The main scalability constraints I am finding are:
1) Performance - from benchmarks and real world testing approx 100 requests per second give or take is the mean. From what I've read Axkit has much greater throughput. 2) Extensibility - Mason is a nice app server package but some parts of it (i.e. error handling) have become intimately tied to the Mason structure in the latest branch. Also most of Mason's functions are tied to a request, so if I want to manipulate a template from within perl-space (i.e. on a cron basis have a script evaluate a template's contents) I have to generate a request object and component stack. I'm hoping that will be simpler with axkit. 3) XML compatibility - yes I could use mason as a filter like you suggested but I'm still limited by the performance constraints of the component structure. I'm hoping to use server-side includes or something similar with Axkit to emulate this kind of template structure - I'm sure it will be more work but I'm at the point where I need to process thousands of requests per second as opposed to hundreds and integrate with other vendors using xml standards. Axkit seems to be the 'big kids' Mason equivalent. Thanks for your help! I'm sure I'll have more questions as time goes on. Regards, Fred Moyer > Fred Moyer wrote: >> I have a large mod_perl application which uses perl modules for the >> application and object processing and relies on HTML::Mason for >> content delivery and templating. Needless to say I am starting to hit >> Mason's scalability limits and am considering replacing Mason with >> Axkit and porting all the templates. From what I have learned so far >> I will need to use either XSLT or XPath for the templating and >> delivery needs. > > AxKit isn't really complicated, it's just that there's a lot of stuff > (same goes for XML). I'd say step one is to get a feel for every option > from 30.000 feet and then to figure out what you need to get started > and which options sound saner to you (knowing that you can look into > other options later). To be perfectly honest, it is very difficult if > not impossible to tell someone else how they should be using AxKit, it > really is TIMTOWDI :) > > Reading the Wiki (http://axkit.org/wiki/view/AxKit/DefaultPage) if you > haven't already is absolutely vital. > > There are several ways to generate content (XSP, Providers) and several > ways of transforming content for display (XSLT, XPathScript) with > varying degrees of dynamicity. > > Coming from a Mason background, you may feel more at home with > XPathScript. However, it may be that the similarities it bears with > Mason's templating system are precisely what you want to get away from. > >> Can anyone here who has undergone such a migration offer some advice? > > I migrated in a brute-force manner (ie rewrote a lot), quite a long time > ago now. I can basically split my former Mason content in two parts: > the bits where the code was mostly separated into another module with > the page only calling the API, and the bits where the pages had way too > much code in them. > > For the former the switch is easier. You can wrap the same modules into > an XSP taglib (using TaglibHelper or SimpleTaglib) in order to generate > an XML structure corresponding to your data, and style that with XSLT. > > For the latter it is less fun, you may have to refactor quite a bit. > What I did was to keep Mason running and port segments of the sites one > by one, time allowing. Note that Mason can be used as an input to AxKit > (using the filter provider) so that you could modify the HTML in your > Mason pages to be XML, and filter that through AxKit to style it with > the XSLT that styles your pure-AxKit stuff. > >> xml schema definitions > > *bzzzzzt* It's very likely that you will never need those :) Doing > without them will make your life a *lot* easier. > > > PS: If you don't mind telling us about the "scalability limits" you've > found in Mason that are inciting you to switch to AxKit, I'm sure > people on the list would be glad to hear about that. > > > -- > Robin Berjon <[EMAIL PROTECTED]> > Research Engineer, Expway http://expway.fr/ > 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488 > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
