I'm exploring the UI5 Tool Header UI component.
As far as I can see, there is an option to implement such UI component either with sap.f.ShellBar or with sap.tnt.ToolHeader. Since both UI elements look pretty similar, what's the difference?
Is sap.f.ShellBar just a newer/modern implementation of the functionality, provided by sap.tnt.ToolHeader?
The Tool Header control is part of the sap.tnt library and this library "[...] targets the specific needs of the tools user group (typically developers and administrators)" (taken from the UI5 documentation). By contrast, the Shell Bar is part of the sap.f library with controls specialized for application-oriented UIs.
Further details and guidelines on these two specific controls can be found in the SAP Fiori design guidelines for the Shell Bar or rather the Tool Header.
Related
According to the latest Fiori design guidelines, there is a new concept called Me Area which contains user-specific and context-aware information and shortcuts.
But, there is no documentation or reference to get that control. Has anyone able to apply that on to their SAPUI5 Page.
The Me Area is part of the SAP Fiori Launchpad, and not a UI control in the SAPUI5 library. Technically, it is a view with name sap.ushell.components.shell.MeArea.MeArea.
I've been studying sapui5 framework for some time now and I always used javascript views in my applications.
The question is - are there reasons why should I prefer xml views over javascript, if I should do it at all? If there are some, what are they?
If I want to start trying to write xml views, what is the best place to learn the basic syntax and where can I find API reference for controls created using xml? The SAPUI5 API is written for use with javascript.
Thanks.
Major reason, in my view, is strict separation of concerns. XML views, by their nature, preclude code. Your XML view is therefore strictly presentation logic - a great outcome for professional enterprise development. It also reduces the significant lines of code to code out the ui and thus improves readability and maintenance of code.
the reason I use XML views is because this is the standard approach of the Fiori apps by SAP. It creates a situation where developers only have 1 approach. Also to me they are easier readable.
Generally speaking I see that in the mobile library the xml views are used while in desktop usage js is still leading. On SCN you can find many similar questions.
The library of examples can be found in the same API page under tab EXPLORED.
Perhaps using the webIDE (which offers a local) install can provide a really good base for you to start development using xml based views.
Where you say the API is written for js views, this is true because the controls are written in JavaScript. Look at it this way if you have a namespace in your xml like xmlns:l="sap.ui.layout" any xml element prepended with l like <l:GridData ...
becomes a call to sap.ui.layout.GridData and if you look at the api for this control you can see what attributes you can add to this control / element.
Also if you have xmlns="sap.m" in your namespace block then anything like <Page /> <Table /> become sap.m.Page or sap.m.Table so the api is still a valuable resource and the explored section is great to see controls in action.
I'm investigating Adobe CQ5 and would like any advice on how to integrate its drag-and-drop UI to create a responsive website. It seems as if it works on a concept of fairly bland templates with components that can be dropped in pretty much anywhere, including things like "three-column control" - which would make designing a responsive grid structure very hard (as it would be hard to prevent users from dropping in a control that could ruin the layout).
Does anyone have any experience or advice on this? I'm really looking for deep technical details on the structure of templates vs components (paragraphs), and where/how to manage to the CSS.
CQ5 offers ways to control what can be done within a template, so thinking that components "can be dropped in pretty much anywhere" may be misleading. Page templates are designed and configured so that you control which components can be added to a certain area of a page. This allows you to only make those components available that will work with the template layout, excluding components that would wreck the layout. Then authors are only allowed to use things that will work. If they attempt to drag a component onto a paragraph (parsys) where that component has not been configured as available, the UI will not allow them to use it there. So CQ actually makes it easy to prevent users from dropping a control somewhere that would ruin the layout.
This is outlined a bit here:
http://dev.day.com/docs/en/cq/current/howto/components_develop.html#Adding%20a%20new%20component%20to%20the%20paragraph%20system%20%28design%20%20%20%20%20mode%29 which states that
"The components can be activated (or deactivated) to determine which
are offered to the author when editing a page."
When it comes to CSS and JavaScript, you can create a client library and then include the relevant client library on the page. Backend CQ functionality will take care of combining multiple CSS (or JavaScript) files into a single minified file to allow for a single HTTP request of an optimized file. This it outlined a bit here:
http://dev.day.com/docs/en/cq/current/developing/widgets.html#Including%20the%20Client-Sided%20Code%20in%20a%20Page as well as
http://dev.day.com/docs/en/cq/current/howto/taglib.html#%3Ccq:includeClientLib%3E
So you might develop several components that share a client library, then when any of the components is added to a paragraph the client library will be included on the page. You may also want a CSS library that applies to all the templates to give a common look and feel, yet allow components to add their own when they are used.
These guidelines for using templates and components outline how you provide control, yet flexibility:
http://dev.day.com/docs/en/cq/5-5/developing/developing_guidelines_bestpractices.html#Guidelines%20for%20Using%20Templates%20and%20Components
I'll document our successful WIP experience with RWD and CQ5
Assumptions:
A well documented style guide.
Our First Steps:
Modified existing column control component css to utilize twitter bootstrap grid css.
Create a base page property allowing two different classes on the grid container to be set and inherited by child pages. (container||container-fluid).
Leverage out-of-the-box components where ever possible.
All component widths inherit the width of their parent container allowing for components to be dropped into any location within a template.
Issues:
The out-of-the-box column control component can not be nested.
We are looking into building a custom column control component.
Takeaways: this is an evolutionary project and we are constantly iterating.
With the recent launch of AEM 6.0, they have an example website called as Geomatrixx Media. This website is responsive.
You can take this example as reference and start building on top of it.
I have some data that is displayed in a bar chart, using Google's Visualization API. Was simple enough until designers redesigned it... Now it appears to be something that is beyond what Google can help me with.
Given the attached mockup (and note the finer details like reflection and gradients!)- how would you go about building it? Using some existing graphing libraries? Homebrew from the ground up?
Thanks for any advice.
If you need to adhere to the custom design requirements as depicted in the image above, I would build a charting application using a more generalized graphics library such as Rapheal.
While it doesn't provide a simple API for plugging data into a chart, it does provide the ability to build a chart with the following:
a variety of shapes (i.e. the bars)
gradients
embedded images (i.e. the background)
You can change the visual effect using CSS.
Ofcourse you can use chuckx recommendation of Rapheal which is a SVG based Javascript Library. It can accept JSON values so say if you have JSON from Google API you could feed in directly.
Option 2 : HTML Canvas. There are lot of HTML 5 canvas libraries like Kinect, fabric.js powerful javascript canvas libraries
I am chewing through a specification for an iPhone Web App (NOT native). The request implies a lot of general charting functionality, mostly line chart and bar charts. On the implementation side of things, it means a lot of re-formatting of existing web content using an iPhone Web App framework (most likely JQTouch).
Given the capabilities of the device browser, is there a specific charting library you'd recommend, which runs acceptably on the mobile Safari with reasonable overhead?
We are interested in the following charting functionality:
Line and bar series
Legend display on chart area or outside
Dynamic series support (e.g. show/hide series)
Dynamic series creation in JS
I have looked at Flot so far.
The free and excellent Google Chart Tools lets you create both static image charts and interactive (javascript) charts.
They look quite nice:
There are several jQuery based plugins for that (including Flot):
http://www.reynoldsftw.com/2009/02/6-jquery-chart-plugins-reviewed/
And the Filament Group has a nice one as well:
http://www.filamentgroup.com/lab/update_to_jquery_visualize_accessible_charts_with_html5_from_designing_with/
I've used the latter though we eventually scrapped it when we realized we only needed bar graphs and it was easier to just roll-our-own simple implementation using a bit of jQuery animation and some divs.