On 28 May 2014 21:37, Kohsuke Kawaguchi <[email protected]> wrote:
> On 05/26/2014 06:54 AM, Tom Fennelly wrote: > >> 1. Jelly + Stapler are not the easiest to work with. At least I've >> >> found it quite difficult to figure out where to make changes. >> Sometimes it was obvious.... other times it was anything but e.g. >> tweaking the project config page to get Jelly to create a series of >> <table> elements (Vs one uber <table>). In the end... I found it >> easier to do it post-rendering via Javascript, which is not good imo. >> 2. What will be the effect on plugins of changing project config >> >> layout. I already see some strange behaviour e.g. I added an >> "Execute shell" build step... it works fine in the "uber >> <table>" layout, but is screwed up after I manipulate it - prob easy >> to fix, but still an indication that some of the plugins are >> sensitive to changes in their surroundings. >> >> 3. Use of <table> for layout seems to be quite popular Vs using <div> + >> CSS. >> > > Let's work together on this --- getting rid of <table>s in favor of > <div>s. It sounds like that's a necessary step to enable other people to do > more aggressive experiments. > > The config page layout is the most complex part of Jenkins views by far. I > think I can speed you up. > > This is also an area where plugin config files are shielded from the raw > HTML tags through taglibs, and our control over the lower Jelly layer > allows us to do some backward compatibility magic if need be. > > So I'm still somewhat optimistic about this. And if this exercise makes me > appreciate the problems in Stapler, that's good for me, too. > > Can we schedule a two hour window (ideally your 5-7pm time which is my > 9-11am time) that we do this in http://jenkins-ci.org/hangout? Perhaps > other people might be interested in chiming in. Actually I was going to suggest that Tom head up to Dublin (where there is actual high speed broadband) and him and I spend a good chunk of that trying to refactor /lib/form to use divs rather than tables... At the very least that would be helpful getting Tom up to speed. If there is anyone else nearby I have no issues with turning it into a more open hacking session... though we might have to hunt a location to do the hacking from... similarly no objections to open it up as a hangout, though it would more be a shared hacking session as I would want to focus more on the task and unblocking Tom. > > > > After a few brief conversations with some of my colleagues at CloudBees >> (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most >> "doable" approach for now is to stick with making changes to what's >> there right now i.e. jelly templates, javascript and CSS. We also >> talked (not in detail) about the possibility of working towards more >> modern technologies and approaches e.g. a Single Page App using the >> Jenkins REST API Vs the current server-side approach with Stapler and >> Jelly. To do that now, however, seems a bit like trying to "boil the >> ocean" (quoting one of the guys there). What do you guys think? >> >> So I hope there's an appetite/interest in this and I hope people will >> let us know where they would like to see this go (or not, as the case >> may be). And of course, if anyone is interested in getting involved in >> a "hands-on" way, then that would be even better :) I think the next >> steps are for me to gather peoples opinions and formulate an actionable >> plan that people can see and comment on if they want to. >> > > One thing that's missing from the list in this thread so far is, more > dynamic content update in real time without page reloading. I think this is > one of the concrete feedbacks I hear when people talk about Jenkins UI. > > For example, the list view should be updating itself all the time based on > what's going on. > > > > > -- > 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. > -- 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.
