I suggest you ...

The ability to develope and "plug-in" a common module/widget to an existing applicatoin

The ability to developed LS applications in modules. Most LOB applications start off simple and evolve over time into large systems. The ability to develop smaller modules and link them together would be a great advantage in LS.

241 votes
Vote
Sign in
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Frank Claassen shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Frank,

Thank you for your suggestion. We are declining the suggestion because we are currently focused on Office 365 and HTML support. We will support the Silverlight client for as long as Silverlight is supported but no new innovation will be happening for the Silverlight client. See http://social.msdn.microsoft.com/Forums/vstudio/en-US/7b92697d-ff35-4c04-8ac5-8949870c6c58/lob-html5 for more details on product direction. Creating a custom control for the HTML client can be done by setting the control type to Custom Control and using the appropriate JavaScript or JavaScript based control.

Thanks,
Elizabeth Maher, LightSwitch Team

19 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Simon Jones commented  ·   ·  Flag as inappropriate

    Elizabeth,
    I'm sorry you have completely misunderstood the purpose of this suggestion. It is not about the Silverlight client alone. It is about combining several small LightSwitch applications together into one application.
    If the development was done in Windows Forms or XAML, we could easily combine several small applications, copying code and form designs from both to form a new application. For example a small CRM system and an Invoicing module, developed separately, could be combined, with a small new menu system, into a larger Line Of Business system.

    I urge you to reconsider.

  • Johnny Larue commented  ·   ·  Flag as inappropriate

    One approach that Microsoft should consider would be to provide a class library approach that would allow separate teams to create separate LightSwitch client assemblies and separate data assemblies (you know , standard best practices .Net development kind of stuff) and then provide an API to allow us to compose these assemblies at runtime using MEF into a single LS application. This approach would allow the developer to reduce the module XAP loading time as we'd only need to transfer the LSML extension and supporting entity classes, it may also provide a slick way to resolve multiple Language support needs.
    This would make LightSwitch a true LOB tool and put it into a class all on its own.

    The lack of module composition IMHO the biggest drawback of LightSwitch otherwise this is one amazing product!

  • Frank Claassen commented  ·   ·  Flag as inappropriate

    Yes, I most definitely agree with you (mitkodi). LS has the potential to be a fantastic platform for developing / delivering major LOB applications. What is there now is already awesome, the requested enhancements will just make it soo much better!

    PS: Any feedback from MS as to when they will decide which enhancements to implement and more or less when?

  • mitkodi commented  ·   ·  Flag as inappropriate

    I realy liked the idea to be able to merge several separate LightSwitch applications into one composite application. A composite shell with a tabbed ribbon bar that merges ribbons of applications (tab per application) and navigation commands related to the currently selected ribbon tab (module) and different active screens. The composite ribbon bar should display only tabs for applications (modules) for which the current user has rights and each application (module) should be dinamically loaded on first selection of the corresponding tab. Sure it will require not only mergeing client applications and definitions (dataworkspaces, screens, navigation commands) but merging the services on the server side. But this will break the limits for using the LightSwitch for developing real enterprise LOB applications.

  • Frank Claassen commented  ·   ·  Flag as inappropriate

    Yes, it's not about developing a "common" module but developing an application in modules. If you look at any ERP system, you have multiple modules such as AR / AP / Inventory / Finance (GL) / CRM / etc. Currently, with LS, you will have to develop all of this as a single application.

    What would be ideal (and meant by my original suggestion) and this would be beneficial to team development as well, is to develop each of these modules individualy (they should all share a common entity model). You should also have the ability to turn on / off which modules should be loaded at runtime - this can work on the basis that if a module is deployed it is loaded but then you will have to have the option to deploy all modules or only selected modules. Consider how the extensions are turned on in the solution properties and something like that for turning on / off LS modules would be awesome.

    Take this example: I am busy developing a LS application and have developed a generic auditing method. Now, every application that I develop that needs auditing, I have to add the required entities and copy / paste the code. If I could develop this as a module, I could simply load the module into each LS application and not have to worry about recoding / designing it each time.

    Another example: If I want to combine two or more of the LS starter kits into one application, I have to do alot of work at present whereas if they were modules, I could simply add a reference in one LS application to load another LS application.

    Make sense?

  • Simon Jones commented  ·   ·  Flag as inappropriate

    I don't think this is about "common" modules. It is about combining two or more separately developed LightSwitch applications into one.

  • Andy Kung commented  ·   ·  Flag as inappropriate

    I also updated the title to better reflect your idea. Hope you don't mind Frank :)

  • Andy Kung commented  ·   ·  Flag as inappropriate

    Thank you for the input guys! It sounds to me there are 2 seperate ideas in this thread:
    1) The ability to "plug-in" a common model/widget to an existing applicatoin
    2) Split the model into smaller modules for better team development experience

    Since Frank created this thread (and I think he meant #1), I took the liberty of submitting #2 as a seperate idea for people to vote on.
    http://visualstudio.uservoice.com/forums/127959-visual-studio-lightswitch/suggestions/2367447-split-the-model-into-smaller-modules-for-better-te

    Thanks!

    -LightSwitch Team

  • John commented  ·   ·  Flag as inappropriate

    Hi Andy

    As an example in our very large (150K plus employee) organization, we have the need to create many new LOB applications that would be used by as many as 20-30 thousand users situated throughout the globe many of whom are in our Call Centers and Back Office Teams supporting 100’s of clients.

    As per your question regarding a common scenario... is that we would have a number of LOB modules that would need to be globally shared across many departments that form the core of work activities while there would be other business modules that would only utilized for a specific team.

    Other examples would be if I were a Manager I might have additional core business modules than a non-manager, or another example, I am an Auditor part-time, and when I am auditing I am also doing other non-Auditing tasks.
    It would be unrealistic to have 100’s of applications that users would need to manage URL’s around, it would be more realistic to blend the business functionality for a given user at the time the tool loads through MEF catalogs.
    I have recently implemented a custom LightSwitch Shell which injects the PRISM MEF bootstrap onto the LightSwitch shell and all subsequent views that the LightSwitch application sends through to this custom shell are routing into PRISM named regions instead of directly inserting these into fixed view containers.
    This is cool because I can now import any number of other PRISM based modules and have them seamlessly situate themselves within the same UI single Application.
    This custom PRISM Root LightSwitch Shell (as I call it) serves to provide the PRISM Bootstraper within LS as well this custom Shell redirects Screen Navigation and Commands over to the PRISM Region Manager.
    What I have also been attempting to do, but with no success is to create a second type of PRISM LS Shell that serves as a PRISM Module Shell.
    The idea being that I would be able of applying this PRISM Module Shells to as many composite LightSwitch applications but instead of the UI Views/Commands surfacing directly they are simply relayed over to the PRISM Region Manager and targeted to a specific named region.
    So as an example, I would always have one and only one PRISM Root Shell assigned to my base LS application which inserts the Bootstraper logic, has the custom region Adaptors and is responsible to discover other PRISM Modules and to load them up.
    Those LightSwitch applications that I wanted to become discoverable and thus an option to inject would use the custom PRISM Module Shell, they in turn support the PRISM IModule and supporting Initialization method required by PRISM Modules.
    These Module Shells would obtain a handle to the PRISM Region Manager through standard MEF Import and simply push the Views/Commands to a desired Region.
    I have all this built but I am struggling to start up the Module LightSwitch applications. I am able to load them through the Catalog but I can't find the supporting documentation anywhere to spin up the LightSwitch Module's Application instance, I see how its defined, but I need to understand how to pass the ApplicationDefinition derived from the LSM file and spin up an application Instance. My hope was that once I spun it up, that it would interact with my custom PRISM Module and wouldn't be the wiser to the fact its UI views/commands were actually surfacing within a completely different LightSwitch Shell application.
    The approach is cool (if it could be made to work) as you can have multiple teams independently building their own individual LightSwitch Applications, fully testing and building out the functionality as a normal LightSwitch application and then by a simple change of the Shell to be a PRISM Module Shell these XAP files are discoverable and able to inject into a composite based solution.
    It would also be very easy to dynamically tie these LightSwitch modules to a user through the roles. Thus as the application spins up a query of modules would be limited to the roles that a user is associated to.
    I know that there are some inherent limitations with the current LightSwitch product such as, when I tell the LS Client to not include a referenced assembly that under the covers that is ignored by the Generated Client and even when you attempt to change that there it still deploys those assemblies to the target XAP. I also know that there is a single namespace "LightSwithApplication" which may present a challenge when combining Application instances as well there may be issues with the Services side of this, but man would it ever be

  • Yossu commented  ·   ·  Flag as inappropriate

    I think this is a good idea because the way Lightswitch is organised right now, it's very difficult for more than one developer to work on an application, as pretty much everything you do affects the .lsml file, so you end up with conflicts when you try to submit your changes.

    Sure, you can merge changes, but this is a real pain, and is a very unstable way to develop. It's all too easy to make a mistake with such a large and complex XML file. Splitting it down into modules would make this MUCh easier and far more stable.

    It would also have the great side benefit of allowing us to see what changes were made in each revision. Right now, you have to wade through a huge .lsml file, which is very hard.

  • Frank Claassen commented  ·   ·  Flag as inappropriate

    The main idea behind it is more in line with developing an application in seperate bits that can "plug" together. For example, say we develop a basic CRM application and deploy it, then someone wants to add functionality to manage the manufacturing of widgets. We could develop the widget-manufacture module and deploy it as a new module in the existing CRM application. The widget-manufacture module would be activated in the CRM application and it's menu structure would merge with the CRM application's menu structure.

    This would also allow development of modules by partners that could be distributed and used by other partners / clients.

    Hope this makes a bit more sense.

  • Simon Jones commented  ·   ·  Flag as inappropriate

    I think this is more to do with multiple LightSwitch applications being designed over time, possibly by dfferent people in a company, and the need, at some point in the future to bring them together into one coherent whole rather than keeping them as separate small applications.

  • Andy Kung commented  ·   ·  Flag as inappropriate

    Thank you for the ideas and comments! I'd like to understand the scenario and narrow down the pain point here a bit more. Is this specifically for the collaborative development scenario? It would be very helpful if you could give us some real-life scenarios of the issues you run into.

    Also, there seems to be a couple of different ideas from the comments (and they're all great ideas!). Perhaps we should spin them off and create seperate ideas here so people can vote on them seperately?

    -LightSwitch Team

  • John commented  ·   ·  Flag as inappropriate

    Ideally we would build class libraries that decouple the data (Models) as Interfaces and same for the screens (Views/ViewModels) then use a view first approach to inject views into regions (PRISM) so that functionality is injected into a composite applicaiton at runtime.

  • JanVanderHaegen commented  ·   ·  Flag as inappropriate

    This one has my vote. Having a team of more then one FUNCTIONAL developer is a pain, because you have to merge the ApplicationData.lsml with every checkin. This defenitely solve that problem, and make LightSwitch available for larger, professional development teams!

  • John commented  ·   ·  Flag as inappropriate

    Follow the PRISM approach for module development and tie security roles to only load modules for user who are members of supporting role

  • Petr Tichý commented  ·   ·  Flag as inappropriate

    Also possibility to separate Model (Data) to different project would help very much - in situations, when you'd like to have same database for multiple apps (like client module, admin module, collections manager module etc.)

  • Anonymous commented  ·   ·  Flag as inappropriate

    I proposed a solution in "Create home menu layer to access different LightSwitch apps from the same environment"

Feedback and Knowledge Base