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
