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"
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. Ross On 3 August 2012 08:11, Scott Wilson <[email protected]> wrote: > On 3 Aug 2012, at 07:02, Chris Geer wrote: > >> On Thu, Aug 2, 2012 at 7:48 AM, Franklin, Matthew B. >> <[email protected]>wrote: >> >>>> -----Original Message----- >>>> From: Scott Wilson [mailto:[email protected]] >>>> Sent: Thursday, August 02, 2012 10:28 AM >>>> To: [email protected] >>>> Subject: Re: AW: Allowing users to add widgets without page refresh >>>> >>>> On 2 Aug 2012, at 14:21, René Peinl wrote: >>>> >>>>> 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. >>>> >>>> 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é. >>> >>> Personally, I am not a huge fan of grabbing rendered HTML via AJAX calls >>> and stuffing it into the page. What do others think? >>> >> >> Matt, I agree with you. I'd much rather find a way to do it client side in >> this case. > > 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. > > 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. > > 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. > >> >> >>> Scott- what issues did you find? >>> >>>> >>>>> Regards >>>>> René >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Franklin, Matthew B. [mailto:[email protected]] >>>>> Gesendet: Donnerstag, 2. August 2012 13:48 >>>>> An: [email protected]; [email protected] >>>>> Betreff: RE: Allowing users to add widgets without page refresh >>>>> >>>>>> -----Original Message----- >>>>>> From: Scott Wilson [mailto:[email protected]] >>>>>> Sent: Thursday, August 02, 2012 7:16 AM >>>>>> To: [email protected] >>>>>> Subject: Allowing users to add widgets without page refresh >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> 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). >>>>>> >>>>>> 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. >>>>> >>>>> 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. >>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> One possibility is to move the region_widget.tag code into client-side >>>>>> JS templating. However, there is then an issue with localization. >>> >> >> 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? >> >> Having the chrome client side also has the advantage that we could >> enable/disable menu items and such client side as well. >> >> >>>>>> 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. >>>>>> >>>>>> Can anyone think of any better solutions for this? >>>>> >>>>> 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. >>>>> >>>>>> >>>>>> S >>>>> >>> >>> Chris >> >> [1] http://docs.opensocial.org/display/OSREF/Localization > -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
