Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 88974 invoked from network); 15 Jun 2004 09:22:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 15 Jun 2004 09:22:23 -0000 Received: (qmail 30683 invoked by uid 500); 15 Jun 2004 09:22:47 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 30650 invoked by uid 500); 15 Jun 2004 09:22:46 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 30561 invoked by uid 99); 15 Jun 2004 09:22:45 -0000 Received: from [193.201.200.196] (HELO grover.luminas.co.uk) (193.201.200.196) by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 15 Jun 2004 02:22:45 -0700 Received: from media.demon.co.uk ([80.177.14.141] helo=[192.168.0.4]) by grover.luminas.co.uk with asmtp (Exim 3.35 #1 (Debian)) id 1BaA8h-0000YV-00 for ; Tue, 15 Jun 2004 10:21:55 +0100 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <40CEBD2B.4080603@apache.org> References: <40CD7782.1070009@apache.org> <40CEA9E3.4020909@apache.org> <40CEBD2B.4080603@apache.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-35--537552526; protocol="application/pkcs7-signature" Message-Id: <70927360-BEAD-11D8-BE03-0003935AD2EE@media.demon.co.uk> From: Jeremy Quinn Subject: Re: [VOTE] Unrestricting the FOM Date: Tue, 15 Jun 2004 10:21:53 +0100 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.618) X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --Apple-Mail-35--537552526 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 15 Jun 2004, at 10:11, Sylvain Wallez wrote: > Reinhard Poetz wrote: > >> Sylvain Wallez wrote: >> >>> Hi all, >>> >>> More and more, the limitations of objects provided by the FOM seem >>> like arbitrary constraints that go in the way of people and produce >>> confusion. Furthermore, these restrictions only apply to the JS >>> flowscript and not to JavaFlow, thus making JS flowscript a second >>> zone citizen compared to Java code. >>> >>> That's why I propose to remove these restrictions my having >>> cocoon.request, cocoon.response and cocoon.context providing the >>> full API defined by the interfaces in org.apache.cocoon.environment. >>> >>> Furthermore, I propose to add cocoon.avalonContext to provide access >>> to the various data held by this object. >>> >>> More background on this subject is available in the "Less is more... >>> or less" discussion [1] and my answer to Jeremy's problem [2] that >>> shows how simple it is to workaround the restricted FOM. >>> >>> Please cast your votes! >>> >>> - [+1] to remove restrictions on existing objects. >>> - [?] to add cocoon.avalonContext. >> >> >> I'm not sure about avalonContext.`What happens if we really drop >> Avalon as base framework? Do statements containing >> cocoon.avalonContext still work or will they be hidden (because >> Flowscript is interpreted) broken? If the user has to use the >> workaround and she recompiles the code with Cocoon 3.0 and the >> compiler doesn't compile her code anymore, she knows that she has a >> problem. Or will a possible legacy mode hide that she may have a >> problem? >> >> We should really try to make moving from Cocoon 2.x to 3.x as smooth >> as possible and users that only use Flowscripts and the sitemap >> shouldn't be forced to change their applications if they want to use >> Cocoon in the same way as they have been used to do. > > > Looking at the vote results, the general opinion is to remove the API > restrictions (got only +1's), Good > but not tie the FOM to a particular Avalon object (got lots of +0's > and a -1). This is more difficult to understand, but I could see why some were worried. > So let's drop this cocoon.avalonContext proposal. Firstly because it > becomes less useful if the FOM is unrestricted, and secondly because > we can easily add the ContextAccess I proposed to Jeremy as a utility > class. People using that class will know by doing so that their app > becomes tied to Avalon. That is fine by me. Shall I commit the sample class you provided? Do you have any preferences for where it should live? Or do you have a more sophisticated way of adding this functionality, that you would prefer to use instead? Thanks for your help, and thanks everyone for your votes. regards Jeremy --Apple-Mail-35--537552526 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJDCCAt0w ggJGoAMCAQICAwskYzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMxMTEzMjEwMTI0WhcNMDQxMTEyMjEwMTI0WjBKMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhqZXJlbXlAbWVkaWEuZGVt b24uY28udWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwu9abCH/mefGpJqCrbgn+ H3FX223ceivXU1FpwEciHb1edLiyhRDmeELKfS8RBh1fWeXPnsMsR+/JW1kFTjuU05vtu3zr4AC8 HH5qx5TexLkqHP9rfwQPwzlkbXa5m30niA4a642Wi9Q7i/sg1i41najIRr/W/no+MkOWgPypsqbG aWpUWIZyETfrJNhlyeYOXWivyv657l2Oc2qSzxOUnWvh9GiwF4Ru7kESViiCLwyDzPaN2yLreMKA 6ZU+0hv77iwtc0Ul8GDNWwYUiFA1RqDMtz90oKoOIEzNn/LCD1PMziPCmpXXipAuVnttv0eSXX6w /jlIQYf+k0MwAEw5AgMBAAGjNTAzMCMGA1UdEQQcMBqBGGplcmVteUBtZWRpYS5kZW1vbi5jby51 azAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBADJJWfPQFDb7d8YUlCxO1Fk9HgTY6SoO YqSofIBfqf4yUQ9YCyi8ea5dv+Nl17oNDAGetto14mI0uIj1BlWTrZ6SBpo9ou+s9juyZQNBDZ1v +9qB7/A4wpNUKuDfihrDh1gEdhC7sbh2pj4g/xZ98rWi+p5SCY0MzrQV1dWuf0d5MIIDPzCCAqig AwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuF Wqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDag NIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYD VR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkq hkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbq NOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLJGMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQwNjE1MDkyMTUzWjAjBgkqhkiG9w0B CQQxFgQUWD4JprmLFgcUrxZBrnF6ucJizy4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwskYzB6BgsqhkiG9w0BCRACCzFroGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLJGMwDQYJKoZIhvcNAQEB BQAEggEANnnWCShsHcQbVxWaksAXZqDsuOAl4Qo9INt5WNEaDMlhs+kzinguSCIjQHt9aGKxK+ec f7pExBRkIFd/TKc2ZhiGJgKzHKIwB84tPL67DjO7YtEBAyevOmqNvL1s0BVv/kNw66KmWWokCyjP +7ursMiipIp+H79nxUmvgaPUkAAPujq6hVIFRstMnbsn8DjUOeaeyKfg009dlfmQvoAznRuWTiuL W2mO64RGkYNnrzMfYUm9iXiemEbyzTaDnvzzkmf417jY6UdWs8zg1CeP7Lwgc+fKkMHBFgNGCLJR VzyCjD6DtgGs80FHOlRIlJyr4yYqN53HHkuBA5Ej6/NQLQAAAAAAAA== --Apple-Mail-35--537552526--