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 <scott.bradley.wilson@gmail.com> wrote:
>> On 3 Aug 2012, at 07:02, Chris Geer wrote:
>>
>>> On Thu, Aug 2, 2012 at 7:48 AM, Franklin, Matthew B. <mfranklin@mitre.org>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
|