Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 88967 invoked by uid 500); 17 Mar 2003 16:33:38 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 88954 invoked from network); 17 Mar 2003 16:33:38 -0000 Received: from out004pub.verizon.net (HELO out004.verizon.net) (206.46.170.142) by daedalus.apache.org with SMTP; 17 Mar 2003 16:33:38 -0000 Received: from verizon.net ([139.85.116.194]) by out004.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030317163340.PWFO7930.out004.verizon.net@verizon.net> for ; Mon, 17 Mar 2003 10:33:40 -0600 Message-ID: <3E75F8E2.9080007@verizon.net> Date: Mon, 17 Mar 2003 11:33:38 -0500 From: Vadim Gritsenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [PROPOSAL] Continuation in objectModel, Was: Discussion of Flow Issues References: <3E721CE1.3030308@verizon.net> <3E735557.4050205@apache.org> <3E74E5CA.2060204@anyware-tech.com> <3E751D4C.4030208@verizon.net> <3E752DBF.9000103@verizon.net> <3E75332E.5090804@verizon.net> <3E753728.3040709@verizon.net> <3E753945.9050907@verizon.net> <3E753B3C.4030607@verizon.net> <3E753F90.3000300@verizon.net> <3E7547B7.2010904@verizon.net> <3E754BF1.6040407@verizon.net> <3E75D177.1050403@verizon.net> <3E75ECD8.3030803@verizon.net> In-Reply-To: <3E75ECD8.3030803@verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [139.85.116.194] at Mon, 17 Mar 2003 10:33:40 -0600 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Christopher Oliver wrote: > Vadim Gritsenko wrote: > >> You may discourage usage of these objects for the sake of perfectness >> of the MVC in the documentation but I don't think you should insist >> on disabling access to them (like in FlowVelocityGenerator). >> >> Fair? > > > I think you're right. > > JSTL seems to take the approach of exposing session, request, and > application properties as "implicit objects" in its expression language. > > "The JSTL expression language defines a set of implicit objects" > So, do you think the same can be done with the elements of the object > model? Umm... XSPs should be compared to JSPs, and yes, we already have set of built-in objects (see any XSP java source file, or see XSPGenerator.java): /* Built-in parameters available for use */ // context - org.apache.cocoon.environment.Context // request - org.apache.cocoon.environment.Request // response - org.apache.cocoon.environment.Response // parameters - parameters defined in the sitemap // objectModel- java.util.Map // resolver - org.apache.cocoon.environment.SourceResolver The only thing which is missing is flow continuation and bean (new kids), but these are provided by jpath logicsheet. And I can't built them into core XSP because people want to separate flow into the block. > * pageScope - a Map that maps page-scoped attribute names to their > values > * requestScope - a Map that maps request-scoped attribute names to > their values > * sessionScope - a Map that maps session-scoped attribute names to > their values > * applicationScope - a Map that maps application-scoped attribute > names to their values Sidenote: If you want scoped XML variables in XSP, take a look at xscript. Vadim