JavaScriptSupport deprecations - Dynamic JavaScript generation?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JavaScriptSupport deprecations - Dynamic JavaScript generation?

David Taylor
Hello,

We are working on several Tapestry 5.4 applications that make extensive
use of Kendo UI components in addition to the standard Tapestry
components. We have created Tapestry components wrapping the Kendo UI
components, but see that the JavaScriptSupport methods we are using in
setupRender() to emit our JavaScript have been marked as deprecated. The
remaining non-deprecated JavaScriptSupport methods do not appear to
provide the functionality needed to dynamically assemble the required
Kendo UI Javascript initialization logic (e.g.
http://docs.telerik.com/kendo-ui/framework/datasource/overview).

What mechanisms exist in Tapestry 5.4 that can be used to replace the
functionality of the deprecated addInitializerCall() and addScript()
methods? The remaining methods in JavaScriptSupport seem to be focused
on the use of static JavaScript files which does not work well for
heavily JavaScript-driven component sets such as Kendo UI or jQuery UI.

While the approach we are currently using works well, it is clearly not
supportable long term given the Tapestry method deprecations. Any
feedback on how this logic should be structured in Tapestry 5.4 would be
greatly appreciated.

--
David Taylor
http://www.extensiatech.com



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JavaScriptSupport deprecations - Dynamic JavaScript generation?

JumpStart
This may help. Compare these:

        T5.3: http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/javascript <http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/javascript>
        T5.4: http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript <http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript>

        T5.3: http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/robust <http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/robust>
        T5.4: http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/robust <http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/robust>

        T5.4: http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1 <http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1>

Geoff

> On 27 Sep 2015, at 8:17 am, David Taylor <[hidden email]> wrote:
>
> Hello,
>
> We are working on several Tapestry 5.4 applications that make extensive use of Kendo UI components in addition to the standard Tapestry components. We have created Tapestry components wrapping the Kendo UI components, but see that the JavaScriptSupport methods we are using in setupRender() to emit our JavaScript have been marked as deprecated. The remaining non-deprecated JavaScriptSupport methods do not appear to provide the functionality needed to dynamically assemble the required Kendo UI Javascript initialization logic (e.g. http://docs.telerik.com/kendo-ui/framework/datasource/overview).
>
> What mechanisms exist in Tapestry 5.4 that can be used to replace the functionality of the deprecated addInitializerCall() and addScript() methods? The remaining methods in JavaScriptSupport seem to be focused on the use of static JavaScript files which does not work well for heavily JavaScript-driven component sets such as Kendo UI or jQuery UI.
>
> While the approach we are currently using works well, it is clearly not supportable long term given the Tapestry method deprecations. Any feedback on how this logic should be structured in Tapestry 5.4 would be greatly appreciated.
>
> --
> David Taylor
> http://www.extensiatech.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: JavaScriptSupport deprecations - Dynamic JavaScript generation?

David Taylor
Geoff,

Thanks for the 5.3/5.4 comparison links. Seeing non-trivial working
examples definitely clarified a few points for me regarding the new
approach. The modal dialog example is also very interesting in its own
right.

Looking at the examples, it seems the new module approach would require
us to develop some form of client-side JavaScript API to create the
necessary Kendo UI configuration objects. Parametrizing all of the
possible Kendo configuration options to work within the constraints of a
static JavaScript library would not be an easy task. The Kendo
configuration is very flexible and varies by component. Perhaps it would
be possible using a multi-step configuration approach, but I imagine
that wouldn't be very pretty.

Currently we generate the JavaScript code server side and emit it into
the page using the deprecated addScript() method. This allows us to
construct the Kendo JavaScript configuration taking into account the
configuration of the associated Tapestry-Kendo wrapper components and
data source information from our middle tier. The details of the
JavaScript code being generated are rather dynamic so it does not lend
itself to a static configuration approach.

Barring any additional approaches, it seems the addScript() method is
currently the most workable option. Does anyone know why this method was
marked as deprecated? Any chance it could be removed from the
deprecation list?

--
David Taylor
http://www.extensiatech.com


emailsig
On 9/26/2015 9:24 PM, Geoff Callender wrote:

> This may help. Compare these:
>
> T5.3: http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/javascript <http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/javascript>
> T5.4: http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript <http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript>
>
> T5.3: http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/robust <http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/robust>
> T5.4: http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/robust <http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/robust>
>
> T5.4: http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1 <http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1>
>
> Geoff
>
>> On 27 Sep 2015, at 8:17 am, David Taylor <[hidden email]> wrote:
>>
>> Hello,
>>
>> We are working on several Tapestry 5.4 applications that make extensive use of Kendo UI components in addition to the standard Tapestry components. We have created Tapestry components wrapping the Kendo UI components, but see that the JavaScriptSupport methods we are using in setupRender() to emit our JavaScript have been marked as deprecated. The remaining non-deprecated JavaScriptSupport methods do not appear to provide the functionality needed to dynamically assemble the required Kendo UI Javascript initialization logic (e.g. http://docs.telerik.com/kendo-ui/framework/datasource/overview).
>>
>> What mechanisms exist in Tapestry 5.4 that can be used to replace the functionality of the deprecated addInitializerCall() and addScript() methods? The remaining methods in JavaScriptSupport seem to be focused on the use of static JavaScript files which does not work well for heavily JavaScript-driven component sets such as Kendo UI or jQuery UI.
>>
>> While the approach we are currently using works well, it is clearly not supportable long term given the Tapestry method deprecations. Any feedback on how this logic should be structured in Tapestry 5.4 would be greatly appreciated.
>>
>> --
>> David Taylor
>> http://www.extensiatech.com
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JavaScriptSupport deprecations - Dynamic JavaScript generation?

David Taylor
Any additional thoughts regarding alternatives to the AddScript method
for JavaScriptSupport? Should I open a new bug report to capture this
issue and/or request removal of the AddScript deprecation?

--
David Taylor
http://www.extensiatech.com


On 9/26/2015 10:49 PM, David Taylor wrote:

> Geoff,
>
> Thanks for the 5.3/5.4 comparison links. Seeing non-trivial working
> examples definitely clarified a few points for me regarding the new
> approach. The modal dialog example is also very interesting in its own
> right.
>
> Looking at the examples, it seems the new module approach would
> require us to develop some form of client-side JavaScript API to
> create the necessary Kendo UI configuration objects. Parametrizing all
> of the possible Kendo configuration options to work within the
> constraints of a static JavaScript library would not be an easy task.
> The Kendo configuration is very flexible and varies by component.
> Perhaps it would be possible using a multi-step configuration
> approach, but I imagine that wouldn't be very pretty.
>
> Currently we generate the JavaScript code server side and emit it into
> the page using the deprecated addScript() method. This allows us to
> construct the Kendo JavaScript configuration taking into account the
> configuration of the associated Tapestry-Kendo wrapper components and
> data source information from our middle tier. The details of the
> JavaScript code being generated are rather dynamic so it does not lend
> itself to a static configuration approach.
>
> Barring any additional approaches, it seems the addScript() method is
> currently the most workable option. Does anyone know why this method
> was marked as deprecated? Any chance it could be removed from the
> deprecation list?
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JavaScriptSupport deprecations - Dynamic JavaScript generation?

JumpStart
Try asking the question over in the users mailing list where others may have dealt with similar situations. It’s a discussion worth having.

Parameterising options to static JS wrapping Kendo components might be too onerous - I don’t know. The closest I’ve come to it is parameterising for HighCharts, which I balked at initially but later found it’s actually not too bad. I wrote a separate static JS script for each style of chart that I wanted to produce, and each one has slightly different options.

Here’s an example, just in case it helps. The static JS script in it produces a 3D chart from 1 data series. The other scripts will have slightly different params.

        void afterRender() {
                JSONObject params = new JSONObject();

                params.put("id", chartContainer.getClientId());
                params.put("showLegend", false);

                JSONArray categories = new JSONArray();
                JSONArray series0 = new JSONArray();

                for (int i = 0; i < 5; i++) {
                        if (i < evaluations.size()) {
                                categories.put(formatDefault(evaluations.get(i).getStartAt().toLocalDate()));
                                series0.put(deNullForJSONArray(toInteger(evaluations.get(i).getSomethingOrOther())));
                        }
                        else {
                                categories.put("");
                                series0.put(JSONObject.NULL);
                        }
                }

                params.put("categories", categories);
                params.put("series0Values", series0);

                params.put("yAxisTitle", messages.get(“something-or-other-axis-label"));

                JSONArray yAxisLabels = new JSONArray();
                yAxisLabels.put(toLabel(YesSlightNos.N));
                yAxisLabels.put(toLabel(YesSlightNos.S));
                yAxisLabels.put(toLabel(YesSlightNos.Y));
                params.put("yAxisLabels", yAxisLabels);

                params.put("yAxisFloor", 0);
                params.put("yAxisCeiling", 2);
                params.put("yAxisMinRange", 3);
                params.put("yAxisTickInterval", 1);

                javaScriptSupport.require("components/report/highcharts/ClassicOneSeries3DHighChart")
                                .invoke("init").with(params);
        }

HTH,

Geoff

> On 29 Sep 2015, at 9:36 am, David Taylor <[hidden email]> wrote:
>
> Any additional thoughts regarding alternatives to the AddScript method for JavaScriptSupport? Should I open a new bug report to capture this issue and/or request removal of the AddScript deprecation?
>
> --
> David Taylor
> http://www.extensiatech.com
>
>
> On 9/26/2015 10:49 PM, David Taylor wrote:
>> Geoff,
>>
>> Thanks for the 5.3/5.4 comparison links. Seeing non-trivial working examples definitely clarified a few points for me regarding the new approach. The modal dialog example is also very interesting in its own right.
>>
>> Looking at the examples, it seems the new module approach would require us to develop some form of client-side JavaScript API to create the necessary Kendo UI configuration objects. Parametrizing all of the possible Kendo configuration options to work within the constraints of a static JavaScript library would not be an easy task. The Kendo configuration is very flexible and varies by component. Perhaps it would be possible using a multi-step configuration approach, but I imagine that wouldn't be very pretty.
>>
>> Currently we generate the JavaScript code server side and emit it into the page using the deprecated addScript() method. This allows us to construct the Kendo JavaScript configuration taking into account the configuration of the associated Tapestry-Kendo wrapper components and data source information from our middle tier. The details of the JavaScript code being generated are rather dynamic so it does not lend itself to a static configuration approach.
>>
>> Barring any additional approaches, it seems the addScript() method is currently the most workable option. Does anyone know why this method was marked as deprecated? Any chance it could be removed from the deprecation list?
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>