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" > > 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 > > Ross > > On 3 August 2012 08:11, Scott Wilson wrote: >> On 3 Aug 2012, at 07:02, Chris Geer wrote: >> >>> On Thu, Aug 2, 2012 at 7:48 AM, Franklin, Matthew B. wrote: >>> >>>>> -----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 >>>>> >>>>> 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: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 >>>>>> >>>>>>> -----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 >>>>>>> >>>>>>> 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