i am working on theming concepts in SAPUI5 application.
I got to know that the theming can be done by using UI Theme Designer (which is a tool in SAP backend).
I got to know this from here.
Is it possible to develop a custom theme in SAPUI5 with out using Theme Designer.
There is a range of options, Theme Designer being the easiest and least flexible one, a completely written-from scratch CSS file the other extreme.
In between there are options like copying an existing theme, renaming it, and appending CSS parts that modify the existing appearance (this is also possible in Theme Designer!).
One main deciding factor is how different your theme should look from an existing one, and what your upgrade strategy is. Very different themes might be best created using the "base" theme as... well, base. But whenever you create lots of extra CSS you need to be aware that you have to adapt it to new UI5 releases. The Theme Designer does this automatically, as long as you don't add any custom CSS.
Before writing a theme from scratch or vastly modifying one, you should look at how large existing themes are and estimate whether you want and can develop and maintain such a thing on your own.
(Why are they so complex? 200 controls - and that's only the OpenUI5 subset - and many of them very powerful with different appearances and responsiveness, working across devices, and also appearing in right-to-left mode,... that's something no other framework offers, so of course the UI5 themes are larger than those of much smaller frameworks.)
Related
The title already says it and we do have a working example. However, the library we have built does have it's own customTheme and uses styles to such an extent that we cannot just copy them to the projects importing the library.
Right now we do get the following error on multiple developer machines:
It looks like there are several instances of #material-ui/styles initialized in this application.
This may cause theme propagation issues, broken class names, specificity issues, and makes your application bigger without a good reason.
See https://material-ui.com/r/styles-instance-warning for more info.
Is there a best practice for creating Material-UI components in a library which can then be reimported into other projects with its styles and everything of course then inheriting colours etc. from the project the library is imported to.
I am evaluating the option to upgrade a project developed for Alfresco 4.1 to Alfresco 5.
The project contains mostly customisations of Alfresco Share. We have new pages but also customisations of OOTB pages (the document library for example).
I know that Aikau has been already introduced in some of the pages in Alfresco 5.
I am wondering how much of our code could be reused.
Because the customisations have been implemented using Surf, most of their logic is in webscripts. Is it possible to continue to use these webscripts with Aikau?
The biggest change made in Alfresco Share was between versions 4.1 and 4.2 when all of the WebScripts were refactored to move all the logic out of the FreeMarker templates and into the JavaScript controller (see the series of blog posts starting here). The purpose of this was to make customization easier as it enabled simple configuration tweaks as well as swapping out default Alfresco widgets for 3rd party extensions. This somewhat paved the way for the approach that Aikau then follows - namely to allow all customizations to be done through the WebScript JS controller but with Aikau the widgets are much finer grained.
Ultimately it is going to entirely depend on your customizations for 4.1. The main differences you'll find are to the header bar and to the search page. The toolbar and documentlist Surf Components were also merged to reduce the vertical space that they took up.
The main issue for other WebScript customizations will be that you'll need change how you were extending them, as code that was previously in the FreeMarker template in 4.1 will now be in the JS controller.
Aikau has already been introduce in 4.2.e, to check the full listing of functionalities developed in Aikau, check this link.
Aikau is built on top of spring surf, so most of your customisations (if not all) should still be viable. The only difficulty I think you may face is migrating your project structure from the old ANT SDK,to the new one based on maven! But this page should guide you through the use of the new SDK.
I started working on projects in GWT last month. It was all well until I needed drag and drop(DND). After trying gwt-dnd library like everyone else I got infatuated by smart-gwt widgets. But everywhere I read that its a very thin wrapper over Javascript. But I've still decided to go with it. I have some general questions regarding GWT.
Is it okay to write the GUI in a mix of plain-GWT and smart-gwt ?
Can I implement drag and drop only with plain-GWT without the help of external libraries?
Should I write the smart-GWT like widgets in plain-GWT myself?
No you shouldn't and neither is proposed from the smartgwt creators, There are some tweaks that can make it work, but it is at a per case base ...
You could try to achieve this, especially with the latest 2.5 version and its Elemental library.
Depends what you need and the resources you have for the task. You could make look-like lighter elements macthing the smartgwt ones, but it can be tricky if you are looking after operations like filtering etc. Bottom line is, you wouldn't be considering the smartgwt or any other similar library, if you had the time and resources to develop its widgets.
Our webapp is implemented in GWT 2.2, with heavy use of UIBinder. I really like UIBinder's ability to define styles either inline with the HTML, or at least in a <ui:style> section. As a programmer, this modularity really appeals to me, as it puts the styling right where it's used.
And for styles that are used in more than one place, I refactor them to a CommonStyles.css/CommonStyles.java, and refer to that in my *.ui.xml files.
This has worked great so far, but now the company has contracted an HTML/CSS designer to re-work the design. We spent a few days trying to get him up to speed on Eclipse & GWT, without much success. To meet a deadline, we ended up having him just deliver an old-school giant CSS file to us, which we then painstakingly refactored back into the various ui.xml modules.
My question: Is it better to maintain a single, old-fashioned giant CSS file for a UIBinder app, so that designers can work with it? It pains me as a programmer to do things this way, but it seems like it's the only practical way to have non-programmers work on the design.
Is it unreasonable to expect designers to know an IDE such as Eclipse or Intellij?
From the perspective of the programmer of a company with one programmer and one designer:
The designer on my team never used eclipse or Java before our current project. We started using UiBinder stuff heavily about two months ago and, with maybe a couple of hours of help from me, he's managed to become quite proficient. He's now checking finished & laid out widgets into the source himself, with perfect CssResource etc modularization. I still set up the corresponding .css and .java files for him, but then I throw the setup at him, he writes 90% of the ui.xml & .css bit himself, and I come back and implement his ui in java afterwards. Occasionally I have to change a <div> to a <g:Panel> or whatever. He has not complained about it being too hard. Now he's starting to explore the extensions to css that gwt provides, like constants and expressions.
I'd say you shouldn't have to give up the benefits of UiBinder for the sake of your designers. In my own project, I expect to have to set up all of the code and generate templates for all of the Java interfaces, but I expect my partner to be able to add his own styles, separate css intelligently (e.g. CommonStyles.java vs. ThisWidgetStyles.java), and understand what's happening when his style names turn into GVDWK.
General approach in GWT is to use Panels and then apply custom CSS themes to get a customized look. While I can achieve a certain extent of personalization of my GWT app through CSS tinkering, I was wondering how others generally approach styling.
Some of the suggestions I came across the web were to manage layout with plain HTML, through use of HTMLPanel's. This way one can straightaway use the HTML mock-up within the application without having to code all the layout.
So what in your opinion is the best and least painful way to approach layout and custom styling of GWT application?
So far, the best approach I found:
get rid of any default GWT theme
use UiBinder as much as possible
place your CSS in ui.xml that describes the widget
have one public Common CssResource with rules reused by many widgets
that way you don't need to maintain one global stylesheet which always is a pain (common problem: where is this rule used?)
It all depends - on you, your experience, your team, etc:
The usual/older approach of Panels, Widgets and Compositing will be easier to work with/more familiar:
If you are a Java programmer experienced with frameworks like Swing, etc. (I think that was the point of the GWT team),
Or if you come from the "desktop world" in general.
The UiBinder approach is the newer one:
Recommended if you are just starting your experience with GWT (it seems UiBinder is here to stay, and it allows more flexibility than the above approach),
Recommended if you have experience with web development (or desktop frameworks that use markup, like .NET's XAML, etc), since you'll be working in the familiar world of HTML/XML,
If you are working in a larger team, where you have designated designers in charge of the look of the web application (and they don't know/care about GWT). Cutting up the layout into HTML code should be pretty straightforward for them and you can, with little work, convert those templates into UiBinder's XML templates.
None of the above approaches is perfect - that's why it's worth to know their strong and weak points - but the end decision should be yours alone, since you know your/your team's capabilities best :)