It would be great if there were some standard Javascript objects or a common
API to access UI elements too. Something like below:
<script type='text/javascript'>
JUI().use('parameters', function (Y) {
var parameters = J.jobParameters(); // this could return all the parameters
present in the UI if any
...
var select = parameters[0];
var remoteObject = <st:bind value="${it.getParametersProvider()}"/>
select.setValue(remoteObject.getNewValues());
});
</script>
Sometime ago we wrote a plugin that supports updating based on other job
parameters. For adding parameter types from other plugins we have to a) check
whether they use the taglibs or custom HTML elements, b) provide ways to
retrieve values and c) update the values in the UI.
I think having some kind of Jenkins javascript variables or standard objects
would help this kind of plug-in that relies heavily on the UI.
Thanks
Bruno
>________________________________
> From: Jesse Glick <jgl...@cloudbees.com>
>To: jenkinsci-dev@googlegroups.com
>Sent: Wednesday, May 28, 2014 5:49 PM
>Subject: Re: Refreshing the Jenkins UI
>
>
>On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi
><kkawagu...@cloudbees.com> wrote:
>> This is also an area where plugin config files are shielded from the raw
>> HTML tags through taglibs
>
>Well, only insofar as they choose to use those taglibs. In most cases
>they do, but there are some places
where plugins add raw <tr>s where
>they expect to be inside a <table>.
>
>> more dynamic content update in real time without page reloading.
>
>It would be nice (especially if we can finally kill Auto Refresh!),
>but you have to be very careful about the performance impact.
>ajaxBuildQueue and ajaxExecutors already impose a significant burden
>on the server when a lot of people are holding pages open. Anyone
>proposing to add *more* AJAX stuff had better promise to fix the
>performance of what is already there first. Being able to collapse
>these widgets is fine but they are
expanded by default and there is
>currently no way to leave them expanded yet impose minimal overhead.
>
>And the problem is that adding more dynamic updates in a modular way
>(i.e., friendly to plugins) translates to a lot of separate HTTP
>requests, and thus lots of overhead—unless you take care to define a
>new API framework for “stuff that may be contributed by various
>components and should be bundled in a periodic refresh when out of
>date”, which is starting to sound like a crappy reimplementation of
>Meteor.
>
>
>--
>You received this message because you are subscribed to the Google Groups
>"Jenkins Developers" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to jenkinsci-dev+unsubscr...@googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
