Skip to Content
Author's profile photo Former Member

Best practices, guidelines, good architecture & lots of stupid questions, etc.

What am I trying to achieve here?

Well, a long time ago we were doing our first Web Dynpro Java project on what was then pretty bleeding edge technology from SAP.  My colleague Richard Tucker and I spent a lot of time determining the “best” way to componentise our efforts to ensure good re-use and maintainability.  So much so, Rich went on to give a session at that year’s SAPTechEd and also worked on a document/whitepaper for SAPInsider (if my memory serves me correctly.)  In short, we got to a really good end game in terms of template for componentising our WD Java applications that we’ve pretty much stuck to ever since.  I’d quite like to get some sort of similar, maybe less formal but equally useful template of apps, components, etc. within the SAPUI5 world, especially as the work I’ll likely be doing with it will be delivered by teams of people, rather than single developers who can control all objects.

Let’s get meddlin’.

Before I really get into this1, firstly let me apologise for the increase in quantity and decrease in quality of questions, comments and thoughts I’m likely to add to SAPUI5/HTML5 Space over the coming months.  For better or worse, I’ve got some time to actually get my hands a little dirty with some SAPUI5 development.  I’m more used to Java Web Dynpro development and indeed, even with that it’s been some time since I’ve really got my hands dirty with “proper code” 🙂

As mentioned, I’m now doing some SAPUI5 meddling in anger and as is my customary approach, I seem to be spending a lot of time reading documents, blogs and examples, and wondering about best practices and guidelines for building something, rather than actually coding the damn thing.  As I alluded to in one of my recent discussions, it seems I’m falling foul of one of SAPUI5’s great strengths – it’s flexibility.  There are just too many ways to achieve the same thing.

To try and get my head around some of the key concepts, I’ve set myself the task of building what is a very simple app:2

  • Simple one page with no page-to-page navigation
  • Designed and built primarily for desktop (but could use sap.m controls if needed)
  • Is a simple combination of some images above a data table with a few columns

All sounds pretty straight forward right?  Well, to make it more worthwhile, I also want to achieve/make use of the following:

  • Use a mock.json file to populate the table via model binding
  • Dynamically generate images (simple coloured DIV’s actually) based on the number of rows in the data table, so 3 rows of data mean 3 images
  • Control how the DIV is built based on values from each row, so one of the columns contains a value that dictates the size of the DIV for instance
  • Explore componentisation with the Component.js object, to create a single reusable UI component to represent the resizable DIV image and also a faceless component that acts as a data model between my table UI and the mock.json model, so I essentially end up with a reusable data access component too
  • Make use of i18n properties files to remove hard-coded texts
  • Ensure the project has a file & folder structure that makes sense and supports further componentisation, reuse and maintenance

To many of the afficiandos on these here forums, I’m still not probably setting the world on fire but for me, this is a first principals type of effort; a way of understanding how an application should be structured and built in a “best practice” manner; finally a way of creating a template app that I can quickly use as a quick-start for other app’s.

Here’s a rough mockup of what I’m aiming for:-


It should be obvious a slick UI isn’t what I’m aiming for here, and form certainly does follow function!

To start the ball rolling, I created a new SAPUI5 Application project (called TemplateCompApp) and started by building up a folder structure as a skeleton of where I wanted to end up in terms of content.  I allowed the wizard to create the initial view for me (calling it App) but I’m not 100% sure if this is the right or wrong thing to do.  On the one hand, I like when a wizard can do some of the heavy lifting for me but on the other, I worry what content is it creating for me that will be incompatible with any further entities I create – I guess we’ll have to wait and see.

I ended up with this:

SAPUI5 FolderStructure.jpg

This is quite an extensive folder structure, considering I haven’t actually built anything yet!  As I’m sat here building it up, I’m not sure if I’ve put the components folder in the right place.  With hindsight, I think it should actually sit underneath the “templatecompapp” folder.  I’m mostly happy with how I’ve got my individual components, with the UI and faceless ones having the relevant sub-folders as needed.  (Of course, I don’t really need to create empty folders just for the sake of it but this is a template/PoC after all.)

It’s also fair to say my logic in this regard is greatly influenced with how I approach Web Dynpro Java componentisation and re-use (see the opening paragraph for the background in case you’ve already forgotten.)  As I think about this more, it becomes apparent that yes, my components folder really should be within my “templatecompapp” folder, so a bit of shuffling leads me to this:

SAPUI5 FolderStructure2.jpg

At this point I’ve also decided to make my actual data table a separate UI component as well, and for the sake of completeness from a template perspective, I’ve renamed the components folders with a numeric suffix.  Ultimately I should end up with a main application and view, that re-uses one of the data table components and 0..n of the dynamic DIV components.  The data for the table will come from the faceless component.  See – it makes perfect sense when you say it quick like that…

From a slightly more abstract perspective, this is the kind of generic model I’m looking for from my SAPUI5 apps and components:

SAPUI5 ComponentStructure.jpg


At this stage, I’ve lost an hour or so creating and deleting various folders and files but still haven’t got near to creating content.  It’s important to me to get the foundations right with this sort of thing, hence me over-thinking all of this.  So now, over to the rest of you – what am I doing wrong, right, could do better, etc?  What are people’s opinions on componentisation, re-use and my approach to structuring the files & folders in my projects?  Many may say this kind of structure just doesn’t fit with the ethos of SAPUI5 and they may be right – all feedback is welcome 😉   Hopefully at some point I’ll get round to building something that actually does something too…

1 As with many of my blog postings, this started off as a long winded discussion but I thought it made more sense in this form – there are lots of implied questions throughout (where it’s obvious I don’t know what I’m doing!) so I hope this generates some decent conversation in the comments section below.

2 Luckily, one of my customers has a number of current projects with an element of 7.31 EP and SAPUI5 so I’ve had some inspiration from there – often I find building demo and PoC app’s for self-development is hampered by not knowing what to build.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo John Patterson
      John Patterson

      Hi Gareth

      Thanks for sharing, the questions you are asking are definitely the questions others will be thinking of.

      I dont have the right answers, but think its a discussion worth having so will share my thoughts.

      The first thought I had looking at the folder strucures was UI5 modules are accessed via the defined global name

      eg templatecompapp.components.facelesscomp1.models.mock.json

      a bit verbose

      you could use shorthand at the top of the IIFE

      eg var nsModels = templatecompapp.components.facelesscomp1.models

      but that makes it hard to do a where used search on functionality

      maybe flatten or use accronyns


      the other thing i thought of was the constraints associated with NWDI, why we used to have VC and FC components, the same constraints dont apply here.

      also with the dynamic DIV you may need controls and tests folders also



      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hi John,

      I hoped a blog of me "thinking out loud" would be beneficial as its mostly covering content that is a bit higher than pure technical details and functionality and (I hope at least) will be useful for many others.

      Thanks for your thoughts and suggestions - I'll take them on board as this evolves.



      Author's profile photo DJ Adams
      DJ Adams

      Hi Gareth

      Thanks for sharing your thoughts and questions, as JSP says, they're not dissimilar to what others may well be asking themselves too.

      I'll wade in with one comment for now, picking up on the " I've also decided to make my actual data table a separate UI component as well" bit.

      I know you may want to punch me lightly for this, but I'm wondering whether it's all that time that you spent in the Java world, that has caused you to overthink or overengineer things 🙂

      There's nothing wrong with making things separate and reusable, indeed it's a worthy aim, but not at any price, such as complexity and overengineering. So if you want to make the data table "independent", try making it a separate view, with its own controller. And if that doesn't give you the component independence you want, at least you know how that works and can then make a more informed and war-scarred decision. Plus it won't take long to build a view and controller.

      I'll finish this comment with a couple of acronyms that have stuck with me, and came to mind as I read your very interesting post:

      YAGNI - You Ain't Gonna Need It (referring to the large amount of potential complexity)

      TMTOWTDI - There's More Than One Way To Do It (referring to your early comment about "too many ways to achieve the same thing")



      Author's profile photo John Patterson
      John Patterson

      lol much better answer than mine

      I like the acronym KISS especially the quote "perfection is reached not when there is nothing left to add, but when there is nothing left to take away"

      and BDUF cause it sounds like it is.


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hi DJ,

      In short, you've hit the nail on the head with your comment about Java.  If I'm 100% honest, I'm looking at how simply I can knock something up with the SAPUI5 framework and I'm scared I'm not doing it right!

      Again, thanks for the comments, they have been taken on board and the next evolution of this testapp will be all the better for it...



      Author's profile photo Former Member
      Former Member

      Hi Gareth,

      Thanks for this I be following your progress with interest. I reflect John and DJ points above, and had great fun the tail end of 2012 building an architecture.

      Which I am now looking at and rebuilding with the much improved documentation, be prepared for the same as well.  SAPUI5 is changing and evolving all the time.

      The big area I am looking at now is using the sap.m name space as the previous code was all built on sap.ui.

      If I can offer one word of advise, and this is my own view from experience.  If your solution will be used on any mobile device, stay away from the SHELL control.  Its great for desktop and large format screens, but does become an issue for smaller devices, and needs a few hacks to work nicely.

      KISS is the best, like you I come from Web Dynpro Java and will try and use SAPUI5 anytime I get a chance not to use that again, the MVC approach and FPM were seriously complex to meet the design pattern.


      Author's profile photo Former Member
      Former Member


      Just quick edit from me, as had a question back on this.

      The issue we faced was with the shell control from the core controls and not the mobile.  And the real issue was using overlays.  As when moving to smaller devices you lost a large amount of real estate which for our needs we wanted back.