Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    AMD support?

    It's been about 3 to 4 years since I last used SmartClient (JS, not GWT) and I'm on an new assignment that could really use something like SmartClient.

    Truth is, that in the last 3 years I've been doing quite some work with the Dojo Toolkit (there was work for it, not particularly because I like it better).

    In Dojo - and other toolkits/frameworks - I've seen this AMD mechanism and I was wondering if SmartClient has something similar?

    I really like the idea that each component can be in a separate file and be able to lead its own dependencies.

    Is something like this possible in SmartClient?

    #2
    We provide the ability in the FileLoader to pre-cache the core framework files while the user is interacting with a page that doesn't use the full framework (typically a login page or other greeting page).

    Outside of that, asynchronous loading of dependencies generally doesn't make sense for the types of applications that SmartClient targets. Any given page, if it involves a grid or form, directly or indirectly incorporates the bulk of the framework, and loading either the framework itself or other applications piece-wise generally slows things down rather than speeds them up.

    Comment


      #3
      Originally posted by Isomorphic View Post
      We provide the ability in the FileLoader to pre-cache the core framework files while the user is interacting with a page that doesn't use the full framework (typically a login page or other greeting page).

      Outside of that, asynchronous loading of dependencies generally doesn't make sense for the types of applications that SmartClient targets. Any given page, if it involves a grid or form, directly or indirectly incorporates the bulk of the framework, and loading either the framework itself or other applications piece-wise generally slows things down rather than speeds them up.

      I understand that for distributing this kind of applications it has no sense, but considering colaborative development or in order to reuse classes and widgets in different sites & projects, I find very usefull having AMD support or "something similar" in order to separate the source of classes and widgets in different js files. For developing, versioning & debugging purposses it will be great having the abilitiy to manage component dependencies in the same way that other programming languages manage their dependencies that later can be build together in the same application js file for distributing.

      Do you have any recommendation in order to face these situations or a best practise orientation?

      Thanks...

      Comment


        #4
        If you want to separate files for organizational purposes, there's built in features for assembling separate files into a single .js at runtime - see the FileAssembler docs.

        Comment


          #5
          I used SmartGwt for 3+ years and I've been using LGPL SmartClient for ~2 years now.

          I dove into this exact same question a couple of years ago when I started with SmartClient and it just kind of didn't make sense by the time I got towards the end of whatever project I was working on.

          In both places, I ended up writing "wrapper" components around SmartClient components - I've built API's that wrap SmartClient components in order to kind of streamline all the different ways of doing things, enforce a more consistent look and feel and design guide for my companies and their projects, etc. The idea was that we could give requirements to offshore / junior devs and have them build stuff consistently using OUR API, not using direct SmartClient stuff.

          What I ended up discovering was that for any app that was a good candidate for SmartClient also ended up using ALMOST every library for SmartClient. At a minimum, we would use core, foundations, containers, and databinding along with grids and forms.

          From there, it really boiled down to calendar (maybe) and then optional modules that were usually paid for add-ons.

          Once you realize you almost need all of those things, it kind of became pointless.

          NOW - what I can tell you... is we've integrated require.js (via Grunt) and this works beautifully for our common components / code.

          However.... I'm almost certain if I checked, almost every app using our stuff is probably loading all of our files :)

          At the end of the day - you use this framework for RIA (Rich Internet Applications). They are heavy.

          If you need quick 1-2 pagers for data entry (a form here, a form there, etc)... then something like Angular is probably better.

          Comment

          Working...
          X