On 05/28/2014 01:49 PM, Jesse Glick wrote:
On Wed, May 28, 2014 at 4:37 PM, Kohsuke Kawaguchi
<[email protected]> 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>.
We'll check this with git-grep. I agree this is an issue, and I've done
this myself before, too, but I still think it's manageable --- by
combining (1) adding additional tags to let those plugins avoid the
direct <table> use , (2) intercepting HTML generation at a lower level
in Jelly to notice out-of-place table generation and correct it, and (3)
convincing ourselves that it's not the end of the world if we end up
breaking a few plugins given the need for changes like this.
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.
I was mentally picturing WebSocket that allows various scripts inside a
page to subscribe to the events happening on the server. I also wanted
to build client-side representation of the model objects on the server
in the same form as the @Export-ed data model, and allow scripts to
declare the properties that they need through the tree path expression
we use in */api --- when the subscribed event actually happens the
client gets the model that it asked for.
So if one script wants jobs[displayName,url] and another wants
jobs[url,result], at runtime we can mechanically combine them to be
jobs[displayName,url,result] and that's what the client gets.
I don't know much about Meteor if this is starting to sound like one.
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
