On Fri, 9 Nov 2001, Gunther Birznieks wrote: > I think this is correct if you are talking about a P5EE > wrapper API, but I also think that documentation is > still quite reasonable. ie Documenting the current items > of CPAN that can be used to duplicate a P5EE system.
that's definitely a good goal, one stephen's started to achieve. i'd like to see his list expanded to include discussions of each component, pros and cons of each module, and highlighting of the holes or areas that need improvement. sounds like a subproject in and of itself. > I don't know if this is actually correct for Perl that > it requires an API orthogonal to servlets as "the way" > to building web applications in Perl. i wonder if there was opposition when somebody first suggested MakeMaker. "i don't know if it's correct for perl to require 'the way' to build modules in perl". the point of a webapp spec is to make things easier for people building webapps and for people running webapps. it's not to force everybody into a style. i've just finished a first draft of a servlet wrapper for mason. i took my simple example servlets from wombat-webapps and rewrote them in mason. other than the fact that there are some new implicit objects available in your mason page ($request, $response, $application, $session, $config, $page), the mason pages look exactly the same in the servlet environment as they do outside. it's pretty neat. as a coder, your style doesn't have to change. you suddenly have a lot more tools to work with inside your preferred environment, be it mason, tt, xsp, whatever. sessions, pool-managed database connections, etc etc. and they work exactly the same whether you are running them under wombat or (hopefully someday) OpenInteract or whatever. so you can release your perl webapp and have reasonable confidence that somebody will actually be able to use it besides you. > However, I am not sure servlet API is the way to do it. > If we were to do it as a Perl way without prior > precedence from Java, then the most accepted API is > CGI.pm. Thus, thin wrappers should rather exist around > Apache::Request and Apache::Cookie that emulates the > CGI.pm API. Likewise, if someone using CGI wants a > CGI-Lite, it would do everything CGI.pm does now but > smaller. that is a possibility. but what is the real difference? CGI & Apache::Request give us $r->param(), libservlet gives us $request->getParameter(). are the naming and parameter passing conventions really that much of an issue? i've already said i will go with the majority on that. other than this issue, can you enumerate specific advantages of CGI.pm over libservlet? i'll be happy to consider them. as i've said before, the servlet api was a starting point. i'm happy to break from it given sufficient reason. > Session handling is the next most major thing that > servlets give you. Apache::Session should be morphed > then into something that is more comprehensive (such as > Servlets offer). Everything else about servlets is a bit > of icing on the cake. a partial list of icing: a structured execution environment provided by ServletContext, application and session lifecycle events, request dispatching (including and forwarding), filtering, response buffering, app-specific class loading, locale/encoding support, ssl attribute exposure, rules for distributed apps, unified configuration of all of the above, specification of recommended application directory structure, programmatic security, declarative security, container-managed authentication (including form-based mechanism) > If this were a purely technical merits discussion, I > would say we should throw away the servlet API in favor > of the Perl-isms that exist. But as this is also an > attempt to make things orthogonal to Java, Servlet API > would take precedence I think. no, i think it's an attempt to fill some functional slots that aren't currently filled. i think what i'll do is create a document similar to stephen's component list that 1) describes a function or component provided by the servlet spec; 2) prioritizes the function or component; 3) show how the spec implements it (ie the api itself); 4) shows how to achieve the same end with existing "perl-isms". then we'll have a firm basis for discussion. right now you're really just saying "i don't like the servlet api cos it doesn't like perlish", which is blowing right past my "i like the servlet api cos it provides a lot of things _in a consistent, unified fashion_ that don't exist in the perl world or that weren't built to go together".
