none
Large LOB application using the HTML client RRS feed

  • Question

  • I currently have a fairly large LOB application using the Silverlight client.  We are working on a new and even larger version of this application.  There will be a new external sql server database.  I would very much like to do this version in the html client but have some concerns.  Those of you who have built large LOB applications using the html client, can you please share your thoughts on these:

    -Large detail screens that display 100+ fields and have mutiple sets of tabs for related data.  This is handled in the HTML client by displaying links to separate screens for each child collection.  Is this adequate?

    -Adding data to lookup tables and refreshing the parent table query in a way that the user entering data does not lose their place.  This is accomplished in the Silverlight client by being able to open multiple screens at the same time.  Can this be done in the HTML client?  I want to avoid the scenario where the user enters half the entry, but then discovers the need to enter a lookup, but can't save the record due to validation, so they lose their place when leaving the main screen to add a lookup.

    -Custom modals and associated logic.  In the silverlight client, you can create custom modals and modal window pickers along with validation and business logic.  Can this be done in the html client?  Do you have to create custom js controls for this?

    -Do you find the data binding and change listners to be an adequate replacement for the INotifyPropertyChanged interface used by the SL client?

    -Complex search screens with 50+ parameters.  I currently use custom modal windows in the SL client to display all of the parameters when the user wishes to use an advanced search feature.  Can this be done using the popups in the html client.

    Any other info you can share would be very helpful.  Thanks!!


    • Edited by Hessc Thursday, August 21, 2014 2:22 AM
    Thursday, August 21, 2014 2:20 AM

Answers

  • This is just my $0.02...

    If you accept the argument that information workers are increasingly mobile and need to be productive on mobile devices, you will buy into the argument that having everything on the screen at the same time is not  workable in the future. LightSwitch HTML Client is not designed to have everything on the screen, trying to get it to work that way is not advisable.

    However, I have built large scale data intensive applications using the LightSwitch HTML client (this required to lean hard on WCF RIA Services that is why I advocate them on my website and in my book) where you only show a piece of information at a time, yet still allow the user to get real work done. To handle lookup lists they can use the back button very effectively.

    Try this application:

    LightSwitch Survey: Handling Complex Business Logic Using WCF RIA Services

    Create a survey and then take the survey. You will find the process is just a fast, if not faster than an Silverlight application that had everything on the screen at one time. What is nice is that the application will work just fine on a small phone.  

    But don't take my word for it, look at Office365/SharePoint Online. To get to things you have to "drill-down". It is a different paradigm.  


    Unleash the Power - Get the LightSwitch 2013 HTML Client / SharePoint 2013 book

    http://LightSwitchHelpWebsite.com

    Thursday, August 21, 2014 4:52 PM

All replies

  • I'd be interested in hearing Xpert360 Dave's input on your question, but based on my own experience going from SL-->HTML and reading over your description, I'd discourage you from trying to port your app over to LightSwitch's HTML client.  I seriously doubt you'd get nearly the functionality you now have in the SL client with a satisfactory UX, not to mention all the custom control programming you'd need to do.

    LightSwitch's HTML client is nice if you need to only recreate a subset of the functionality that your SL client is currently providing.  The HTML client is fine for looking at data and making occasional edits and additions, but for wholesale intensive data-entry tasks like the ones you're now doing the SL client, the HTML client would not be performant.  It's too reliant on jQueryMobile, a framework really suited for fat fingers and small form factors, so screen real estate is constrained.  The data-binding API is very weak, really only well suited for scalar values, not collections, which makes complex custom controls (like a grid, for example) more challenging to work with, given the usual need to interface the custom control's data adapter to LS' visual collection.

    Last but not least, you have to consider the questionable future of the independent LS HTML client going forward, especially since most new innovations involving LightSwitch seem to be integrating it more with SharePoint. If I had to do what you're doing now, I'd stick with ASP.NET MVC for now to migrate from SL to HTML; it'd be far more robust than LS HTML Client.  If your timeline is 6 mos or more, you may also be able to use the upcoming ASP.NET vNext technology.  In addition, EF7 is supposed to be compatible with WinRT, which will open up new possibilities for Win8 programming, if your clients are migrating to that OS.

    Thursday, August 21, 2014 4:19 PM
  • This is just my $0.02...

    If you accept the argument that information workers are increasingly mobile and need to be productive on mobile devices, you will buy into the argument that having everything on the screen at the same time is not  workable in the future. LightSwitch HTML Client is not designed to have everything on the screen, trying to get it to work that way is not advisable.

    However, I have built large scale data intensive applications using the LightSwitch HTML client (this required to lean hard on WCF RIA Services that is why I advocate them on my website and in my book) where you only show a piece of information at a time, yet still allow the user to get real work done. To handle lookup lists they can use the back button very effectively.

    Try this application:

    LightSwitch Survey: Handling Complex Business Logic Using WCF RIA Services

    Create a survey and then take the survey. You will find the process is just a fast, if not faster than an Silverlight application that had everything on the screen at one time. What is nice is that the application will work just fine on a small phone.  

    But don't take my word for it, look at Office365/SharePoint Online. To get to things you have to "drill-down". It is a different paradigm.  


    Unleash the Power - Get the LightSwitch 2013 HTML Client / SharePoint 2013 book

    http://LightSwitchHelpWebsite.com

    Thursday, August 21, 2014 4:52 PM
  • Thanks for the great responses.  I too would be interest in hearing from Expert360 and some others. 

    One encouraging factor (sort of) is that the choice between LS SL, LS HTML, and MVC is not mutually exclusive.  I have built some small scale test apps that use a combination of all three and it works pretty well.  I don't like the fact that it is nearly impossible to get a consistent look and feel across the board but the functionality makes that acceptable I suppose.  I use MVC or other custom clients for home pages, displaying custom pages, or making really printer-friendly forms.  I use LS HTML for dealing certain subsets of the data as suggested above, and I still use the SL client for the bigger complex screens.  I was really hoping to get out of the SL client all together at some point tho, for obvious reasons.  I too use RIA services (and Web Api) when I need to change the shape of the data.  Part of me wants to go full out MVC, but that would be a ton of work.

    Thursday, August 21, 2014 7:41 PM
  • Interesting discussion and one that I am very interested in as I would prefer if we could do all our large LOB apps in LS.

    Since Apple introduced the iPhone & iPad every other technology related company in the world has been scrambling to catch up and/or jump on the bandwagon. Microsoft included. Although tablets and mobile phones are a great modern technology phenomena, I think that real big LOB application development has taken a backseat and has been neglected. This is not good since I still believe that the bulk of real data processing get's done on large desktop screens with real keyboards and real electronic pointing devices and that will remain for the foreseeable future.

    From a RAD perspective we have great tools like LS to create those mobile apps to provide extensions to people that perform daily  tasks on the move (e.g. inventory/packing assistant that moves around a large warehouse and completes orders or the waitress at a restaurant taking orders at the table) but when it comes to create the real back office large LOB applications (e.g. ERP, Order Processing, HR, Manufacturing, etc) we are left with ASP.NET MVC. ASP.NET MVC is great, but you cannot compare it to LS from a RAD perspective.

    The LS Silverlight client was on the way to fulfil that LOB RAD void, but then it all came down crashing.

    MS needs to continue advancing the HTML LS to overtake what was possible with the Silverlight client to provide us with a true RAD LOB development tool. I simply cannot understand why they would not want to do that. They created one of the most compelling RAD tools of all time with LS - why stop here with mobile Apps? Why not go to the next level?

    The LOB version of LS needs to shed Jquery Mobile. It needs to perhaps adopt AngularJS (given that the SPA framework war is now truly over and won) as that would make LS compelling for a large core of developers that might be thinking of LS as a "toy" today (I've read some comments along those lines recently).

    The HTML client also needs to allow multiple HTML clients per LS project - this is simply not negotiable in my opinion. This will allow us to break larger applications into multiple modules. There are workarounds and hacks to do that today, but it should be supported out of the box as it is a real world requirement wanted by real developers.

    Back to the OP's question and what we have today... 

    The main tabs in the HTML client screens work very well as they lazy load the data in that tab - this is great for creating larger applications. To fit more more controls and information on a screen you can also use my TabControl with one line of code to group sections into sub-tabs.

    You can also make use of the "Use Compact Margins" option on some of your screens to fit more controls into your available real estate.

    I've done some experiments with creating one large LS app that contains all the screens and then to create multiple other HTML clients sharing the same data source with empty/dummy screens, with an automated script or batch file that will copy the real screens from the main app to the module apps. This could work, provided that all screens are named exactly the same. Once multiple HTML Clients per LS project is supported this hack will not be required anymore.

    All the javascript files created by LS during publishing are not minified. I suspect that a post-publish utility of sorts can perhaps be added to perform that minification to ensure faster load times (even when using IIS compression).

    So I think you can create large LOB apps in LS today and perhaps utilise some of these mentioned tricks to make it workable.

    Lastly, I also wonder how long it will be before someone copies the LS concept to create a real LOB RAD tool? Perhaps leveraging off the server side OData source and just providing a more powerful Client capability utilising say AngularJS? I hope MS does it of course, but there must be some gurus out there that can see some potential in doing this? It should be a huge market if done right.


    Regards, Xander. My Blog

    • Edited by novascape Saturday, August 23, 2014 4:57 AM fixed typos
    Saturday, August 23, 2014 4:51 AM
  • Well said, all.  I can identify with every point of view here, especially Xander's.

    How about all LS gurus get together and:

    1)  make some public ruckus to pressure MSFT for a formal LS roadmap that's been wanting ever since SL announcement. 

    2) If none exists, then let's pressure for the source code & gen templates.

    3) If that doesn't workout then let's modify msls.js for the desktop form factor ourselves.  First step, expose ui.controls and dependent functions so we can use custom control extensions that integrate with the designer like SL.

    Alternatively, we could save time, just skip to #3 and make it happen ourselves.

    Josh


    • Edited by joshbooker Tuesday, September 16, 2014 5:13 PM
    Tuesday, September 16, 2014 5:12 PM
  • I've been watching the development of the HTML client carefully and, while it has definitely improved greatly, I'm still concerned that it doesn't have all the features necessary to allow me to switch from the Silverlight client.

    Moving from C#/VB.NET to JavaScript is a hugely retrograde step, and particularly daunting if you're not already a JavaScript expert. If TypeScript were implemented properly in LightSwitch you'd at least get some help from the type checking and Intellisense.

    The restrictions on calculated fields and the non-firing of Field_Changed events make working with the HTML client even more challenging. Less of the business logic can be put in the data model which then requires you to repeat code in multiple screens, increasing the possibility of mistakes.

    To my mind the HTML client is still not good enough to allow me to build even moderately sized LOB applications but I'm hopeful it might get there eventually.


    Simon Jones
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Wednesday, September 17, 2014 8:02 AM
  • Hi, sorry been very busy. It will be a few weeks yet before I get to spend time around the blog and forums.

    We are in the process of testing the first of several LOB LightSwitch HTML-based applications. We are very happy with the final product overall, it was designed from the ground up to fit with end user workflows and is nothing like traditional fat client screens. It gets work done fast and efficiently though it cannot be called data input intensive.

    Extensive use of roles, permissions, 60+ screens, 4 data connections (300 tables, 10+ views and 10+ stored procs), 1 million rows, OpenXML, 10+ controls with extensive WebApi.

    I have forgotten what the challenges were in getting here, there were a few. We learned how to finally use the HTML client properly. Anyhow, it is the 'template' for more similar apps now for the next year.

    We are now close to old LightSwitch Silverlight productivity, perhaps surpassed when you add in other JavaScript/HTML5 stuff.

    It does rock! I'll share what I can later but I could do with a vacation too :)


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, September 17, 2014 6:50 PM
  • ... it was designed from the ground up to fit with end user workflows and is nothing like traditional fat client screens. It gets work done fast and efficiently though it cannot be called data input intensive.


    That is the key I believe.

    Unleash the Power - Get the LightSwitch 2013 HTML Client / SharePoint 2013 book

    http://LightSwitchHelpWebsite.com

    Wednesday, September 17, 2014 7:12 PM
  • I am very close to finishing the external sql server db for the mid-to-large LOB app that will replace the current SL client app we use now.  There will be around 70 tables, at least a couple of which will have a million or so rows.  The strategy will be to do as much as possible on the server.  Web API will be used heavily.  I am going to attempt to use the LS HTML client but if I can't get it to do what I need at least I can bail to MVC and use the db and Web APIs over there.  The major challenges I foresee are, in no special order:

    - The need for a custom navigation menu.  I can't imagine navigating a large number of tables using the stock drop down menu.  Something like the push menu Michael blogged about would be nice, but that requires modifying every screen, which trades off some of the RAD gains of using LS.

    - Databinding and change listeners.  INotifyPropertyChanged added a lot of "magic" to the Silverlight client that will be difficult to duplicate.

    - Screen real estate.  I am willing to abandon the traditional big screen so long as everything can get done.  This will be interesting.

    - Tabs and multiple dataworkspaces.  Being able to have multiple screens open and bounce back and forth without having to save or lose your place was a great LOB feature in the SL client.

    - Custom controls.  I'm not a javascript expert so this will be fun.  Most importantly, I rely heavily on custom modals and modal window pickers to display multiple fields and search through very large look up tables.  A traditional ACB won't cut it with a table with thousands of rows where the user may need to search on fields that are not the summary field in order to narrow the choices and make a selection.  Has anyone built something like the modal window picker control?  How are you guys handling this scenario?

    Until now, I have been focused on the db and how the server side is going to work.  Soon I will be starting on the client development and will have a better idea if/how it is going to work.  I appreciate all of your responses.

     
    Thursday, September 18, 2014 2:38 AM
  • Hessc raises a very important point in the form of an insurance policy: If it ultimately turns out that the HTML Client is just not up to handling all the complexities of a larger LOB application, you can always view the HTML Client as an initial prototype and replace it with an ASP.NET MVC app that utilizes the already existing backand OData + WebAPI Services - this is indeed one of my stategies at present.

    My current LS wishlist:

    1) Most importantly (biggest bang for buck) is the ability to add multiple HTML Clients per LS project. That will allow us to split out a larger LOB app into multiple modules. This will also help with utilizing the browser tabs to provide the same multi-tab units of work scenario that was possible with the Silverlight client by opening a module app in a separate browser tab.

    2) Related to 1 above is indeed the ability to have multiple simultaneous units of work (like the multiple tabs in the Silverlight client), although this need may be mitigated by the multiple HTML Clients per project (time will tell).

    3) Better support for large form factors (i.e. desktop scenarios) to make better use of screen real estate. Perhaps an alternative built-in theme will help here. It looks like the desktop may well make a "comeback" as a first class citizen in Windows 9 so perhaps this will happen.

    4) Ability to customize the global application header to insert our own menus, login details, etc - the stuff you get in a typical LOB web app.

    5) The ability to create Screens and use them as "custom controls" - i.e. embed a screen into a major Tab on another screen, etc. We have some fairly complex screens with multiple major tabs where it would be cleaner to separate those tabs into separate screens/controls.

    6) More out of the box controls, predominantly bindable dropdown lists (in addition to popup picker), Data Grid (that allows fixed headers), Radio Buttons, Checkbox, File Upload, etc. I know we can use postRender() to do this ourselves, but it would be nice to have these built-in. 

    7) The ability to add bound controls programmatically - we require user-defined fields to be added at runtime (say over a dynamic json object) and it would be nice if we could just append native controls with full binding at run-time for these. I'm yet to solve this one, but will probably have to look at 3rd party controls.

    A lot of the above can be achieved via "hacks" but the point is to get to a stage where this is all possible out of the box without resorting to those hacks.


    Regards, Xander. My Blog

    Thursday, September 18, 2014 3:16 AM
  • Quickly:

    "add multiple HTML Clients per LS project" <-- that is my feedback too. Can manually hack this together but it will be great when if it is official. Only the deployment area looks like it needs some work and even our AIDE product has been working with this for a year or more.

    We are quite good at DOM/HTML5/JavaScript and are using D3JS, little else 3rd party. Our newest app targets desktop and tablets and we have not been really limited by it being 'Mobile Web'.

    We do use a lot of our own screen templates. We use our own menus based around tile lists (similar to Dale's LightSwitchCore). To mimic 'Balmer' it was about consistent UI and navigation, navigation, navigation (I bet you think you know all about this but most people don't :)

    We did not use any WCF RIA services, all WebApi with the LightSwitch context and control other 'heavy-lifting' functions there.

    You will have a custom javascript library, do it on day 1. A lot of those 'hacks' turn into a one line library function call.

    Cheers

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Thursday, September 18, 2014 7:34 AM
  • Oops! "4) Ability to customize the global application header to insert our own menus, login details, "

    We opened up the msls script and changed it to restore the back button and more. Users demanded the back button, that was not a good move removing it! Users feel it is more intuitive to have it there, even though they can also use the browser back button.

    Cheers

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Thursday, September 18, 2014 7:38 AM
  • Hi Dave,

    Just curious: Do you use web-api for "commanding" stuff or do you have also a way to generate screens based on a web-api controller (as it can be done with Ria Services)?


    paul van bladel ==independent enterprise application architect== http://blog.pragmaswitch.com

    Thursday, September 18, 2014 9:29 AM
  • We are quite good at DOM/HTML5/JavaScript and are using D3JS, little else 3rd party.

    Hi Dave,

    Just to confirm, are you referring to the d3js.org JavaScript visualisation library?  If so, do you have any simple examples of using this library alongside LightSwitch that you'd be willing to share?  We're in the process of considering the different options for visualising our LightSwitch data and this library looks as if it could fit that bill and we'd really appreciate any insight you can provide.

    Thanks in advance,

    Chris

    Friday, September 19, 2014 12:46 AM
  • Dave provided an extensive sample here.

    Many thanks and just a quick question - in LightSwitch is it feasible to use just the core lib or is it impractical without the C1 suite?

    Friday, September 19, 2014 7:44 AM
  • We are using the core lib D3JS. There are some extra bits for geographical maps and loads of examples out there.

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Friday, September 19, 2014 8:22 AM
  • I was first attracted to LS by the apparent ease of use and power. However without Silverlight as I research the alternative html5 I am being dragged into learning all about POST, GET, JSON, XML, AJAX, JQUERY, and yet more acronyms and concepts. and the UI in html appears to be very spartan and lacking in power. Ease of use? - I don't see this any more I am looking for a RAD and my initial high hopes for this product are being dashed by the prospect of being forced to learn whole new languages and methods that are far from easy or intuitive to use I purchased Michael Washington's book hoping for enlightenment but the stuff in there is taking me far away from the comfort zone I first experiencerd when attracted to the ease of use and rapid developement environment that promised so much when I first stumbled on this product I think MS must focus on what this product is and not market it in the way they have done so far if they have no plans for a rich client replacement to Silverlight This product under Silverlight looked like it had the potential to become a great RAD tool, but if there are no plans to provide a rich client alternative to html then I for one cannot justify spending time learning new ways of working to spawn an inferior looking UI.
    Friday, September 19, 2014 8:48 PM
  • Unfortunately, in contrast with the accepted answer, I have to report that I found some real issues with large scale LS applications.

    I'm currently working on a large LS HTML application and the development experience is a pain. Ctrl+, to find a class takes forever because of the large amount of generated code, and just scrolling through the screens in the Solution explorer takes 30 seconds.  Building takes forever, and so does launching the application. It seems just at the start, the client fetches all LSML and cs files, instead of loading them JIT =/

    LS is an incredible tool, especially the desktop client and the server. The mobile client seems to be perfect to create a mobile companion app that allows you to perform a limited number of tasks in the field, but if you want an HTML 'management' app, I would suggest to use an existing JS framework and roll your own HTML client.


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Thursday, September 25, 2014 3:07 PM
  • PS: I wrote this entire post and read another one while VS is trying to build and launch the app... :(

    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Thursday, September 25, 2014 3:09 PM
  • Check your email :)

    I have a medium-sized finished app (~60 screens / 70 tables) and a performance test app (550 screens / 140 tables) in LS HTML.

    The latter was proof of the former being possible before starting the project. I'm not saying that there are not problems to be found, but these two apps are performing and working fine.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.


    • Edited by Xpert360 Thursday, September 25, 2014 3:34 PM
    Thursday, September 25, 2014 3:20 PM
  • The mobile client seems to be perfect to create a mobile companion app that allows you to perform a limited number of tasks in the field, but if you want an HTML 'management' app, I would suggest to use an existing JS framework and roll your own HTML client.


    <SarcasmFilter enabled=false>

    Yeah, but Jan don't your clients realize:

    "... the broader notion of an enterprise application is very much changing.  This is not a Microsoft or personal assertion: we're seeing companies who have historically built very large, do-it-all applications look to a sophisticated, centralized service layer that is consumed by many smaller "apps".  It's a model that is much easier to manage from a cost and delivery/deployment perspective, and end-user acceptance of the "app" concept is widespread.  Obviously, not all businesses are there yet and there are some key business functions that will still be served by a more full-featured application, but fewer and fewer of those do-it-all apps are built from the ground up with RAD tools; they are either bought from a SaaS provider and customized with "apps" or--if the organization is large enough--the service is built-in house.  LightSwitch's sweet spot will always be building "apps" that integrate these services to perform new business functions or satisfy unique business requirements...." -Joe Binder

    Source: LOB HTML5

    <SarcasmFilter enabled=true>

    Just kidding.   To Joe's statement above, I ask what tools do these 'large enterprises' use to build the services?  Why not LS? 

    IMHO, LS sweet spot is RAD development of the sophisticated, centralized service layer, AND RAD development of both the do-it-all app for management and the many smaller apps which consume and perform new business functions.

    Josh

    Thursday, September 25, 2014 3:39 PM