Hi, Thanks Felix for the API changes - the packages structure looks very understandable to me now, I think that's a great step in making Sling easy to understand.
On 10/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > Bertrand: > > ...7) SlingScriptEngine > > > > Should we have two eval() methods? > > > > eval(script, props, request, response) for servlet environments > > > > eval(script, props, reader, writer) for "internal" scripts > > I think eval(Script, Map<String, Object>) suffices it and should > encompass enough information needed.... You're right, but coming back to my original motivation for the second eval() above, I think scripts need access to the logging framework. Should be add a "log" variable to the standard scripting variables defined by SlingScriptEngine? > >... 9) Constants > > ... > > I'd also move that class to the "helpers" package - it is not > > interesting to study. > > I do not actually agree. But it is just sort of a guts feeling :-)... Ok to keep Constants right under the api package. > >... 10) SlingHttpServlet... > > I'd move these classes to the "servlets" package, and maybe move the > > SlingXMethodsServlets to servlets/helpers - that's what they are I > > think, and that would prevent the package from having too much stuff. > > I do not agree as the SlingHttpServletRequest/Response interfaces are > two of the central interfaces of interest to Sling programmers: These > are the first interfaces they are confronted with, so I would rather > keep them upfront.... Ok about them being important, but are they *so* important as to be right in the api package? Why can't we move them to their respective "request" and "response" packages? > > ...12) javadocs > > In general I find the javadoc comments too verbose for my taste.... > Well, I disagree :-) The API speficies a central part of Sling and as > such should be specific as much as possible to not run the danger of > being underspecified and thus create problems in the future, where > people might expect something, which does not match the implementation.... I did not mean to remove any information from the javadocs, just write things in a terser way. But this is not critical to getting the API right, so I'd suggest keeping this javadocs discussion for later. -Bertrand
