From dev-return-6357-apmail-rave-dev-archive=rave.apache.org@rave.apache.org Fri Aug 3 09:32:33 2012 Return-Path: X-Original-To: apmail-rave-dev-archive@www.apache.org Delivered-To: apmail-rave-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3A1B191C0 for ; Fri, 3 Aug 2012 09:32:33 +0000 (UTC) Received: (qmail 36012 invoked by uid 500); 3 Aug 2012 09:32:32 -0000 Delivered-To: apmail-rave-dev-archive@rave.apache.org Received: (qmail 35973 invoked by uid 500); 3 Aug 2012 09:32:32 -0000 Mailing-List: contact dev-help@rave.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@rave.apache.org Delivered-To: mailing list dev@rave.apache.org Received: (qmail 35955 invoked by uid 99); 3 Aug 2012 09:32:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Aug 2012 09:32:31 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of scott.bradley.wilson@gmail.com designates 74.125.82.49 as permitted sender) Received: from [74.125.82.49] (HELO mail-wg0-f49.google.com) (74.125.82.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Aug 2012 09:32:25 +0000 Received: by wgbez12 with SMTP id ez12so378853wgb.6 for ; Fri, 03 Aug 2012 02:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=dgKat6piMuOBWq3v/DuOrL8YgJBlG4ReZVpCd/F/eMY=; b=W+lK+uaqmzLIblibpeHv1NHhjAkQtvFxS7Z6xjlAyDRh3woyet222a2ZOq+hNpNbnd e6R0aFspE8reoSuUOlDKLEuyYHvxb/7iVyF7wCIIokcJHw75rN+x4nAZ6SgAJSXGg2de CHYwyg7mxQKKD1L0/v+Z0jJuTRL4UDSKBsWNLEwI/7/nhohIY4qAAhcQ8c9Y6ZndINgW o34BJfsaLLHYcsIZJ76OsdWnO/q8ki9Bv29fobSXqhxHLbdw9iBcOUFKhsNtQveVMXjd nHA6d49dSAFPaxjBeZkvu189uh5P5y2Ny8Ikn9NO1mLfgA4MX5+hbeIqtHc/B2t39lwC KA8g== Received: by 10.180.86.226 with SMTP id s2mr2864532wiz.9.1343986325082; Fri, 03 Aug 2012 02:32:05 -0700 (PDT) Received: from [10.20.4.53] ([87.213.34.158]) by mx.google.com with ESMTPS id t8sm38530304wiy.3.2012.08.03.02.32.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 02:32:04 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: AW: Allowing users to add widgets without page refresh From: Scott Wilson In-Reply-To: Date: Fri, 3 Aug 2012 11:32:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36CFD045-4083-46E2-844D-36ECBB28B1C4@gmail.com> References: <2E45169E9A237B4DA78078A68962F9EF06A73F18@IMCMBX01.MITRE.ORG> <003e01cd70a9$4e5d3e50$eb17baf0$@hof-university.de> <2E45169E9A237B4DA78078A68962F9EF06A74361@IMCMBX01.MITRE.ORG> <6CB17881-DA83-4B3A-AF27-0929440207A0@gmail.com> To: dev@rave.apache.org X-Mailer: Apple Mail (2.1084) On 3 Aug 2012, at 10:55, Ross Gardler wrote: > I'm afraid I don't recall any useful details, but I do remember > someone at a conference waxing lyrical about a fantastic client-side > JS templating library that gave "JSP like functionality" >=20 > I realise this is not much to go on but might be worth 15 minutes on a > search engine to see if it is applicable here. There is a nice article here by an engineer from LinkedIn on selecting a = JS templating library: = http://engineering.linkedin.com/frontend/client-side-templating-throwdown-= mustache-handlebars-dustjs-and-more >=20 > Ross >=20 > On 3 August 2012 08:11, Scott Wilson = wrote: >> On 3 Aug 2012, at 07:02, Chris Geer wrote: >>=20 >>> On Thu, Aug 2, 2012 at 7:48 AM, Franklin, Matthew B. = wrote: >>>=20 >>>>> -----Original Message----- >>>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com] >>>>> Sent: Thursday, August 02, 2012 10:28 AM >>>>> To: dev@rave.apache.org >>>>> Subject: Re: AW: Allowing users to add widgets without page = refresh >>>>>=20 >>>>> On 2 Aug 2012, at 14:21, Ren=E9 Peinl wrote: >>>>>=20 >>>>>> Hi everybody, >>>>>> couldn't you establish a new JSP page that renders only one = widget on >>>> the >>>>>> server-side and then insert the result into the existing page = using >>>> AJAX on >>>>>> the client-side? >>>>>> The only problem could be the page context, that might play a = role for >>>> the >>>>>> widget and would not be available be default in this solution. >>>>>=20 >>>>> Having had a go at using a client-side template and encountering a = lot of >>>>> problems with impact on other scripts, I think this may be the = best >>>> approach - >>>>> thanks Ren=E9. >>>>=20 >>>> Personally, I am not a huge fan of grabbing rendered HTML via AJAX = calls >>>> and stuffing it into the page. What do others think? >>>>=20 >>>=20 >>> Matt, I agree with you. I'd much rather find a way to do it client = side in >>> this case. >>=20 >> I think that would work in the longer run, however doing it = client-side now results in two, possibly conflicting, processes for = adding widgets to a page, one in JS, one in a taglib, and I can see this = breaking easily. >>=20 >> I'm proceeding for now using the approach of calling a JSP via = $().load() to render the widget as a HTML partial, using the taglib, as = it results in the least new code and least amount of functional = duplication. >>=20 >> In the future, we could opt to switch to client-side-only rendering = of widget wrappers, e.g. using Mustache or dustjs. However that would be = a more significant redesign/refactoring of the portal. >>=20 >>>=20 >>>=20 >>>> Scott- what issues did you find? >>>>=20 >>>>>=20 >>>>>> Regards >>>>>> Ren=E9 >>>>>>=20 >>>>>> -----Urspr=FCngliche Nachricht----- >>>>>> Von: Franklin, Matthew B. [mailto:mfranklin@mitre.org] >>>>>> Gesendet: Donnerstag, 2. August 2012 13:48 >>>>>> An: dev@rave.apache.org; rave-dev@incubator.apache.org >>>>>> Betreff: RE: Allowing users to add widgets without page refresh >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com] >>>>>>> Sent: Thursday, August 02, 2012 7:16 AM >>>>>>> To: rave-dev@incubator.apache.org >>>>>>> Subject: Allowing users to add widgets without page refresh >>>>>>>=20 >>>>>>> Hi everyone, >>>>>>>=20 >>>>>>> We have a requirement from the OMELETTE project to add widgets = to the >>>>>>> page without the user having to refresh the page - for example = for a >>>>>>> "page helper" widget to find and then add a widget to the page = for the >>>>>>> user. (see RAVE-743). >>>>>>>=20 >>>>>>> The basic approach would seem to be adding an RPC method for = adding a >>>>>>> widget to the page and then rendering it in the page. So, e.g. >>>>>>> rave.api.rpc.addWidgetToPageAndRender. >>>>>>=20 >>>>>> For what it is worth, IMO this is 2 calls. One to the API = endpoint that >>>>>> already exists and another to a new rave function that does the >>>> rendering. >>>>>> I don't think that the api js namespace should be involved in = rendering. >>>>>>=20 >>>>>>>=20 >>>>>>> I've looked into the requirements for this, and what I'm = currently >>>>>>> stuck against is the use of JSP tags to render the widget = "chrome"; >>>>>>> this isn't accessible from the client side so its not really = possible >>>>>>> at the moment to add a widget to the page without a page = refresh. >>>>>>>=20 >>>>>>> One possibility is to move the region_widget.tag code into = client-side >>>>>>> JS templating. However, there is then an issue with = localization. >>>>=20 >>>=20 >>> I know one of the concerns raised about doing it client side was >>> localization, but I know OS has client side localization [1] so = can't we do >>> something similar with the container? >>>=20 >>> Having the chrome client side also has the advantage that we could >>> enable/disable menu items and such client side as well. >>>=20 >>>=20 >>>>>>> Alternatively, the logic could be moved from a JSP tag into a = Java >>>> class >>>>>> and executed via RPC. >>>>>>> However, that will make for some really messy code. >>>>>>>=20 >>>>>>> Can anyone think of any better solutions for this? >>>>>>=20 >>>>>> I think that the best approach might be to generate a client side >>>> template >>>>>> for a widget using the JSP tags. This might take some tweaking = of the >>>>>> existing template, but would allow you to make one more call to = the >>>> tags to >>>>>> render out a hidden template that can be used to render new = gadgets. >>>>>>=20 >>>>>>>=20 >>>>>>> S >>>>>>=20 >>>>=20 >>>> Chris >>>=20 >>> [1] http://docs.opensocial.org/display/OSREF/Localization >>=20 >=20 >=20 >=20 > --=20 > Ross Gardler (@rgardler) > Programme Leader (Open Development) > OpenDirective http://opendirective.com