TEAMCITY PLUGINS FULL
Other minor issues include being required to download the full document every time we render an iframe and the frame content not having access to the current window object.
TEAMCITY PLUGINS UPDATE
When the frame’s content changes its height, we should update the height of the parent’s container accordingly (nobody likes double-scrollbars). For example, the sad one – TW-64595 – is caused by frame / container height synchronization. Instead we created an Adapter, which loads the tab in a separate frame and removes excess elements (like the header or footer). We did not rewrite the content of the tabs (or plugins). For example, we use iframes to show you the plugins for the Build Results page or when you open tabs from the classic UI in Sakura. In an attempt to avoid these issues, we’ve implemented a solution using iframes. So, any plugin more complicated than just-an-HTML potentially led to memory leaks. And worse, every time a Browser downloaded the plugin, it would also download JavaScript files and run them in the global scope without performing any cleaning. We had no reliable way to tell the plugin about the current context. Every time we navigated through an SPA, we would be required to download the plugin content using XMLHttpRequest. Since we released the Sakura UI, we’ve found a new issue: those JSP / HTML plugins are not fully compatible with Single Page Applications (SPA). To be fair, that was enough at the time, but the web has advanced beyond it. For example, we used plain JavaScript to put an HTML element anywhere in the DOM (for example, in the header, using the class-selector. Through the years, we figured out that this approach has some restrictions, and even we, the TeamCity developers, were writing some UI plugins in a less than ideal manner. In short, that’s it.ĭepending on your imagination, you could use the JSP as a template-container and compile it with the attached JavaScript, make requests, and update the DOM accordingly. Then, if TeamCity finds any plugins, it compiles the attached JSP and puts the output to the HTML-response. Whenever a browser requests a TeamCity page and the core meets the PlaceID container, it tries to find plugins that should be attached to this container. Here was our main idea for the workflow: to create a plugin, you should create a Java controller where you register the PageExtension.The PageExtension should have a certain PlaceID and some resources (JSP, JS, CSS files) attached to it.
If you have ever tried to write a TeamCity plugin, you probably used this guide. State of plugin development before Sakura UI For those who prefer React, we expose our internal components, so you can write a plugin composing existing components from the Ring UI and the Sakura UI – which means you don’t always have to write everything yourself.UI plugins are framework-agnostic, so you can use any library, framework, and bundler.UI plugins can be written in a more frontend-centric way, which involves modern web techs.All existing plugins continue to work as they worked before 2020.2.There is a way to integrate plugins with the Sakura UI.
Please let us know your thoughts and observations in YouTrack, the comments section under this post, or the TeamCity support center.
We want the API to be as useful as possible by the 2020.2 release, so your feedback on this update is very important to us. If you prefer to get straight to technical information, welcome to the updated plugin documentation. In this post, we share our experience, concerns, and motivation behind revising the plugin development pathway in TeamCity. Starting in 2020.2 EAP1, we are taking them a step further and offering you an improved way to write and integrate UI plugins, both in the Main and the Experimental UI (code-named Sakura). Since its very beginning, TeamCity has provided extension points you can use to improve its functionality and your experience.
0 kommentar(er)
