Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 63828 invoked from network); 25 May 2006 18:00:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 May 2006 18:00:33 -0000 Received: (qmail 95684 invoked by uid 500); 25 May 2006 18:00:32 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 94960 invoked by uid 500); 25 May 2006 18:00:30 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 94934 invoked by uid 99); 25 May 2006 18:00:29 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 May 2006 11:00:29 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [216.193.217.213] (HELO meteor.lunarpages.com) (216.193.217.213) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 May 2006 11:00:28 -0700 Received: from c-66-30-112-28.hsd1.ma.comcast.net ([66.30.112.28] helo=[192.168.1.101]) by meteor.lunarpages.com with esmtpa (Exim 4.52) id 1FjK7s-00083q-CA for dev@struts.apache.org; Thu, 25 May 2006 11:00:00 -0700 Message-ID: <4475F095.3060106@fdar.com> Date: Thu, 25 May 2006 13:59:49 -0400 From: Ian Roughley Reply-To: ian@fdar.com User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Struts Developers List Subject: Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion) References: <44735B23.4080701@fdar.com> <17821.170.201.180.137.1148412700.squirrel@webmail.chiron.lunarpages.com> <6821.170.201.180.137.1148480573.squirrel@webmail.chiron.lunarpages.com> <35741.170.201.180.137.1148481976.squirrel@webmail.chiron.lunarpages.com> <60803.170.201.180.137.1148486143.squirrel@webmail.chiron.lunarpages.com> <2872.128.146.93.64.1148501118.squirrel@webmail.tracerdigital.com> <4475B3CE.4020001@fdar.com> <4475DE20.5010701@tracerdigital.com> In-Reply-To: <4475DE20.5010701@tracerdigital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - meteor.lunarpages.com X-AntiAbuse: Original Domain - struts.apache.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - fdar.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Brian Dittmer wrote: > Ian Roughley wrote: >> So, you are saying that your preference would be to include no ajax >> integration and leave the framework and let users integrate this as >> required - either directly in the HTML or by creating custom themes? >> >> /Ian >> > No, I definitely would love to see ajax support...I just think it > needs to be done right. Integrating DWR looks like it might get a bit > messy. Taking ideas from DWR, maybe even some of the code and/or the > js libs, and building the support directly into SAF2 would be a better > option. That way the look and feel of writing ajax enabled actions is > the same as writing other actions. But this IS the goal. The action will be exactly the same as writing non-ajax called actions - the data may potentially be populated differently. > This keeps the SAF2 code simple (e.g. you don't need to worry about > the glue holding together SAF2 and DWR breaking when a new version of > DWR comes out, developers don't need to jump between the DWR codebase > and SAF2 codebase) We will use DWR under-the-covers to provide the glue - it is mentioned here only because it is the dev list and those on the list are most likely interested in the enabling technology. The problem found with using dojo is that the user is pulled into the dojo source, and way too often. I'm not sure that re-inventing the wheel is a good idea, but we will control the integration and upgrades to DWR and work closely with Joe to ensure that the are no issues with releases. > and will be easier for users when configuring their apps (everything > is configured in xwork.xml or annotations, no dwr.xml, no servlet > extra config in web.xml, etc.). This is also the case - my reading the package/action configuration there is NO additional DWR configuration on a per action case. There may be an additional web.xml servlet entry, but I think this is acceptable. > That's just my two cents, I know it's kind of reinventing the wheel > but I think it would definitely pay off in the end. > > Brian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org