Openui5: Please please please CONVERT XML views examples to JS VIEWS

[RobertoMalatesta]

Inside companies there's a need of JS programmatical views for the examples shown in the explored sections of demos.
XML is such a no-no when you have programmatical editors.
It is sooo 90-ish and CUMBERSOME.

[aborjinik]

Thanks for your feedback I will redirect this to product owners.
Also support window (pressing Ctrl + Shift + Alt + S) and afterwards selecting a control from the control tree and then you should see the export section there you can see XML and HTML views option but there is no JS view option.

[akudev]

Hi Roberto,

XMLViews are the new cool thing, JS coding and JSViews have been the preferred way of creating UI5 apps in the 90ies. Well, sort of. ;-)

But seriously: while XML is very non-web-ish on first glance and indeed reminds of certain programming models from the dark past of web development, it has proven to be the most concise, most readable, best maintainable way of creating a complex UI. I have witnessed many discussions, where UI5 users swear they are so much better than JSViews.
Please join the OpenUI5 Slack channel and ask around what people are using, I bet more than 80% are in favor of XMLViews.
So we recommend (and prefer in examples) what users found most useful.

It's not like we are deprecating JSViews - everyone is invited to use what he likes most, but we can't/don't give all examples in all 4 or 5 view types. And just for understanding the samples it shouldn't be too hard to read the XML and transfer it to JS, so the value of documentation shouldn't be affected too much, even when it uses the "wrong" View format.

Even an automatic translator could be easily written, maybe this would be a nice thing for the Explored app ("View as JS")...

Regards
Andreas

[RobertoMalatesta]

Hi Andreas,

thanks for your support and solicit answer on this item.
I see that for some 20-year-or-so XML has been proven as the (apparently) most effective way to define interfaces or messages in a human-readable way, but today we have JSON, and every XML definition cannot do without a JS logic counterpart.
Programmatic approach allows me to define classes in Typescript, using interfaces and generics and have the advantage of completely forgetting loosely checked languages like html and xml.
Intellisense and syntax checking in atom.io, Visual Studio Code (free), Webstorm are so good that writing down a well-maintainable user interface is almost automatic without having to learn strange XML tags or mystic spell casts. This means having a team setting up and developing UI5 interfaces and applications in matters of hours or less.
Every IT development team I introduce to UI5 is enthusiast and immediately operative tinkering with old ux examples but are somehow rejected by the dev context-switching of XMLView approach.
Not to mention that programmatic code can be packed into a single js file and obfuscated through google closure thus giving some good level of protection from logic&components stealing.

It's not like we are deprecating JSViews
That's reassuring. No need to fork! :-D

everyone is invited to use what he likes most,
but we can't/don't give all examples in all 4 or 5 view types.
And just for understanding the samples it shouldn't be too hard to read the XML
and transfer it to JS, so the value of documentation shouldn't be affected too much,
even when it uses the "wrong" View format.

I'm not advocating to throw XMLViews out of the window (...even if cutting them out of code base could reduce the size of the library ;-)) and there are situations in which it can be seen as more productive (when output by an automatic RAD).

Even an automatic translator could be easily written,
maybe this would be a nice thing for the Explored app ("View as JS")…

That would be a good solution, especially to starters that want to grasp the code intricacies while being able to automatically update part of the documentation when/if increasing the # of examples.

Thanks Andreas for all the good work
Roberto

[qualiture]

Just a thought: How is writing (X)HTML any different from writing XMLViews?

• Both (X)HTML and XMLViews use the same (visual) structure (by means of tags)
• code completion for XMLViews can be had by including the XSD's so you write your views with the same ease as HTML

Next to that, virtually all UI5 developers -- I think Andreas is quite conservative with 'more than 80%' ;-) -- think XMLViews are much easier to read than JSViews (and tend to be smaller in size too because of less coding overhead).
In addition, JSViews allow for sloppy coding (i.e. putting logic in your views) whereas XMLViews enforce a strict MVC paradigm

Having said that, I think it is great foresight of SAP to have developers choose from XML, JS, JSON and HTML for view development, so you can use whatever suits you and your development team best :)

[RobertoMalatesta]

@qualiture

Just a thought: How is writing (X)HTML any different from writing XMLViews?

Well,if you decide to use a UI Library you're expected to have components, not tags,
else it's better to go straight HTML.

Both (X)HTML and XMLViews use the same (visual) structure (by means of tags)

Yes, maybe, but the former produces runnable code in a browser, the latter only oozles of COBOLese statements. It's like adding one level of indirection and complexity.
(Yes. I treat KISS principle as a good old friend and he never fails on me.)

Code completion for XMLViews can be had by including the XSD's so you write
your views with the same ease as HTML

With the same pain.
When me or one of my groups use UI5 they do it to avoid markup and have a good structured way to develop a sound interface with already built-in components.
From JS/TS code.
If to avoid HTML (simpler) they have to learn XMLViews (more complex and scope-limited) they will ask my money back and some more for the damages and I could not blame them.

Next to that, virtually all UI5 developers --
I think Andreas is quite conservative with 'more than 80%' ;-)
think XMLViews are much easier to read than JSViews

North Koreans if asked have the same percent of consent for Kim-Jong-Un.
This does not mean they are right or wrong.
Simply they did not see something different (not better, only different) .

([JSVIEW] tend to be smaller in size too because of less coding overhead). 

I have strong evidences this is NOT the case.
Unless you do cut-paste coding.

In addition, JSViews allow for sloppy coding (i.e. putting logic in your views)
whereas XMLViews enforce a strict MVC paradigm

Having sloppy coders put their hands in XML, where errors are less easy to track that in -say- VSC with intellisense, is a real crime against humanity (and paying customers).
Besides, with Xml+JS controller you have TWO places where The Sloppy Coder can perpetrate its crimes :-D (and, again, no help from a syntax checker that can block him).

Having said that, I think it is great foresight of SAP to have developers choose
from XML, JS, JSON and HTML for view development,
so you can use whatever suits you and your development team best :)

Today UI5 is the best platform for streamlined enterprise development.
Please see my remarks as they are: a small effort to keep it the best and funniest.

Rob

[qualiture]

@RobertoMalatesta Lets just agree to disagree :smile: As @akudev already proposed, I'd like to invite you to the OpenUI5 channel on Slack (http://slackui5invite.herokuapp.com/) and post your thoughts there. There are lots of knowledgeable UI5 devs on that channel who could provide more insights

[doniaZaela]

Hi,
I am kind of newbie and I find it hard to convert from xml views (available) in the documentation to js views. Do you have any resources out there which can help with that? Do you know about websites with sample sapui5 js views?
Thanks!

[RobertoMalatesta]

@doniaZaela documentation on JS is scarce and outdated (you'll find examples related to the old ux3 package around in the groups)
Best (only) thing to do is to download the SDK, --the SDK, not the runtime-- unzip it under a web server with directory browsing allowed and look at the samples under .../test-resources/sap/
There's a lot of material there, albeit rather _unordentlich_.

--R

PS: switching from xmlviews to JS (or even better, TypeScript) can be intimidating because of the lack of proper documentation, but once you're operative you will experience a 10x productivity.

[derwaldgeist]

I want to support this. These XML views are just crap, IMHO. They lack simple features like if-else, unless you figure out how to use the preprocessor -- which I didn't, because of bad documentation for non-WebIDE users. When I tried to use JS Views, I got stuck again because all of the samples only provide XML views.

Because I need conditional expressions this badly, I am trying to figure out how you can pass properties from an enclosing XML view to a custom JS view, just like you would pass props to child components in React. No chance, even after many hours of searching Google. And I am not a JS noob.

Sincerely, UI5 really sucks if you're an experienced programmer with knowledge in other frameworks. Why on earth are you trying to make everything sooo different than well-established standards?!

[stephania87]

And my opinion...
XMLViews are structured, easy to read and understand, maintain and extend, and they force coding standards as not everything can be pushed in the view, allow you to instantiate and modify XML in code (if needed).
https://www.w3schools.com/xml/xml_whatis.asp

Yes, complex structures are possible with XML, see SAPUI5 smart templates: https://experience.sap.com/fiori-design-web/v1-36/smart-templates/
Note that the UI is data driven, thus you can have your own template based on data by using expressions in XML. Communication between views also happens via data - one view updates something, passes it to the connected model, the model updates other UI bound to it.

For JSViews you need a good understanding of the framework to create a structure in code. If you take this approach you should have already been familiar with the XML structure and take the risk to add custom logic to alter the view based on custom criteria

For comparison:
XMLView: https://jsbin.com/yujedakipe/edit?html,output
JSView: https://jsbin.com/xuluhofopo/edit?html,output

[derwaldgeist]

Well, this might be useful if you’re using UI5 in a SAP only scenario. But getting all this stuff done on a pure web app is a nightmare IMHO. I finally gave up on implementing the preprocessor and am using factory functions now - which I found after 1 day of scratching my head. It would be easier if the samples were better designed. They often contain only snippets missing relevant parts.

[derwaldgeist]

Besides, all this XML parsing stuff is incredibly slow. Even if I open Explored, it takes about 10s+ to render. This is just crazy if you compare it to React.

[akudev]

Hi Tom and all,
let's start with something where I agree: the templating in XMLViews is quite complex to understand. When an app really needs a View structure which is dynamically decided and can vary a LOT, then this might be a reason to use JSViews instead, where you have complete control using the programming language you know well. Personally, I'm not keen on using templating myself, tbh.
But some limited dynamic decisions in XMLViews can also be solved by e.g. showing/hiding alternative areas and by using data binding. Maybe with factory functions like you do. Or maybe using the Device model, etc.

When XMLViews were introduced, speed has been discussed and analyzed a lot. I don't have actual numbers at hand, but rest assured that IF browsers have been optimized for anything from day one, then for parsing HTML/XML. That's their main business. I think I remember something like an overhead of few tens of milliseconds for an XMLView and it seems like this overhead has been accepted by most users in favor of defining the UI in a way that they consider easier to write and maintain.

When you see Explored (https://openui5.hana.ondemand.com/#/controls) loading in 10+ seconds then I am 100% sure it is not due to XML being parsed.
Of course it is still not good at all when it needs so long to load and it would be interesting to know what the cause is. Even with cache disabled and developer tools open and performance trace turned on and "Enable advanced paint instrumentation (slow)" turned on it takes only 2.5 seconds for me (Chrome). Do you have debug mode turned on (many single module requests) or a mobile data connection?

I won't repeat the arguments in favor of XML because ultimately it is of course also a matter of taste and a matter of what you are used to.
The UI structure can be easily seen in an XMLView but if someone is uneasy with XML because it's not "web-like", there's still JS to define the UI. Your choice. I don't think the amount of code to be written differs significantly and the control structure is identical (and easy to translate in both directions), so I would challenge the 10x better productivity claim from March 14th. It's the same controls, the same properties, the same binding syntax. But again: Your choice.

It is, however, true that the overwhelming user preference for XMLViews has led to JSViews being neglected in the documentation. I would have hoped that once it is understood how directly both ways can be translated into each other it does not really matter which way of putting the View together is used, because what you put together and how you do it is the same in both. But I can understand that beginners may feel uneasy to see no examples that can be used directly.

Maybe we really have to do an automatic translation for the Explored app samples... This would also address the original issue report filed here. I'll have a stab at least at the conversion algorithm itself. Even if it does not end up inside Explored, it could be of some use. Luckily XML is easy to parse, easier than let's say JS. ;-)

Of course it's sad to hear that the samples are often not helpful. Despite of 700+ pages of full-text documentation and almost 700 Explored samples we have apparently not successfully covered all potential ways how the framework and controls can be used. But I have a suggestion: if there is something very specific you are missing in the documentation, use the feedback button at the top right in the demokit/SDK. I cannot promise that every wish will be fulfilled and that improvements will come very fast, but all comments are definitely read over here and assigned to the responsible team if possible. The more reasonable and clear and helpful (and easy) a suggestion is, the more likely it will be implemented.
Or just file a bug report here for a documentation gap.
Yes, this very issue here could be given as counter-argument ("isn't done anyway"), but the request here is quite open and big and there's no Open Source framework which will immediately fulfill all wishes... There are hundreds of bug reports here which have resulted in improvements.

[RobertoMalatesta]

@akudev your post raises a lot of interesting discussion points.

On all of them but one I'm totally against --go figure.

I'm using OpenUI5 since it was called SAP UI 5 in 2012/2013 (still not on github) and I have it in production in several white-labeled products I sold to companies.
It still is the most robust and productive framework on the open, more than Angular or React, that I have used too.

I wrote an answer to your message, then I rewrote it and wrote it again.
Result, I trashed it.

Reason is I don't want to adhere to the internet sport of bashing technologies to emerge as a bright-minded singularity, I decided to dump my answers.
In no way I want to be of detriment to a project I do care for and to the work of the fantastic persons that produced it.

Since I spent a lot of time into the code, up to the point that I'm using it from wasm/C++ bindings (I do still sometimes use Typescript btw), and I have successfully introduced the technologies to some development groups, I don't even need to stress to make my points stand out.
The code's there. That's all I need and I must only say a big thank you to all the SAP people who contributed.

That said, your points are indeed worth discussing.
Mercilessly.
To make UI5 greater for us all.

--R

[akudev]

@RobertoMalatesta interesting post... thanks for the positive aspects.
Regarding the numerous points of disagreement, I'm open to a "merciless" discussion if you think it can lead to something. Maybe contact me in Slack?

Be aware of this, though: I don't have a strong opinion about _all_ the things decided in UI5 (I even disagree with some), but some things are hard to change even when you convince me. On the other hand, things in UI5 evolution _might_ be influenced easier. Plus, UI5 has to serve a wide range of developer types, so it anyway can't make all of them happy. Realistic suggestions are key.

[akudev]

As an experiment, I have just created a small and simple XMLView toJSView converter:
https://jsbin.com/jivopeb/1/edit?output
You can enter the URL of an XMLView at the top (a few example URLs from Explored are preconfigured) and it will translate it to a JSView and display it below.
There's even a live preview of the converted JSView. This preview does not react to user interactions, as there is no suitable controller connected (event handlers don't exist) and for the same reason data models are not available/filled (so the correctness of bindings cannot be judged).
Plain HTML and embedded Views/Fragments are not supported in this experiment right now.

May serve as base for further experiments regarding performance and maintainability.
Actually the structure still seems somewhat readable. It's interesting, though, how we are pushed from pure code towards declarative templating in renderers, but in Views we are pushed the opposite way...