Announcement

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

    Application Maintenance

    Hi,

    As my project has grown, I continued to have one giant script in index.html.

    Recently, this has reached a tipping point where editing it manually is quite difficult.

    So I decided to split it up into multiple JavaScript source files.

    I simply put all my data sources in one file, all my find forms in one file, etc.

    This may work for now, but I'd like to group the elements by the window or canvas on which they apprear, so I don't have to load multiple files for changes to the app.

    I've noticed that the location of the elements in the file is important, since JavaScript seems to proceed from top to bottom when instantiating the objects.

    I don't want to start rearranging the elements in the js file and crash my app.

    Does Isomorphic recommend any best practices for splitting applications up into separate source code files for easier maintenance?

    Thanks,
    Mike

    P.S. I'd also love to use some sort of visual editor, but I'm using the server-less version, so I don't think it's possible. Positioning these elements using co-ordinates and my spacial imagination is becoming impossible too!

    #2
    You can read a detailed write up about how we packaged and deployed our application in another forum post. Search for "some thoughts on a major" to read my post.

    Essentially, we use a make.php script we wrote to package, based on a manifest file (that lists all broken-out js files), all the contributing code. Then jslint, jsmin, and save it into a versioned release file.

    [Editor's note - here is pallen's post]
    Last edited by Isomorphic; 14 Aug 2008, 14:43.

    Comment


      #3
      Wow. Excellent writeup. That's everything I want to do.

      I wish my JS skills were at the point where I could do all that (and I had the time).

      Isomorphic, any plans for an "advanced" manual for doing some of the things described in pallen's post? I'd love to see some code samples of that stuff.

      pallen, just curious, how many coders worked on your project?

      Mike

      Comment


        #4
        Our basic application framework (the controller that manages windows within the app) and the make/release toolset was written by myself, and the actually functional windows were written by one other developer.

        Comment


          #5
          Any plans to make your application framework available?

          For a fee, or dare I hope, as open source?

          This seems like something that would be extremely useful to other SmartClient coders.

          Mike

          Comment


            #6
            Hi Mike,

            There's a few different things that pallen's team put together..

            On the Java side, SmartClient has a FileAssembly subsystem that is similar to the build/jslint system pallen put together.

            On custom component best practices, 7.0 includes an "AutoChild" system that standardizes this approach.

            On something like an "Application Controller" - this is a major post-7.0 direction for us - more "application scaffolding" that captures best practices in applications that have many screens or modules.

            As SmartClient stands today though, there's surprisingly little code necessary to put a basic skeleton in place. For example, if you navigate via a TreeGrid that switches between different possible screens, you can include in each node the name of a function that creates and/or switches to a new screen. You can keep extending that pattern so that each tree node contains various pieces of metadata about the different screens involved, for example, whether the current user can access it, whether it should include a common set of menus shared across screens, etc.
            Last edited by Isomorphic; 14 Aug 2008, 17:18.

            Comment


              #7
              I think Isomorphic's roadmap is very well thought out. Their code certainly

              Comment


                #8
                lends itself to building full-blown applications with very little "traditional Javascript". It's amazing when I look through our code base to see how
                much of the heavy lifting is done by SmartClient controls. That ListGrid
                has one monster API. If they come up with a client side Controller that
                has that level of depth, I'll paint SmartClient.com on the back of my BMW!

                Unfortunately, we would not be in the position to make any of our code
                open source.

                Comment


                  #9
                  Agreed. It's amazing how many files are needed, to make all the graphics work. And the cross-browser compatibility is a miracle.

                  I'd wear a SmartClient T-shirt, at the very least.

                  Mike

                  P.S.
                  What do you mean by a client side Controller?

                  Comment


                    #10
                    Hi,

                    Just checking in to see if an "Application Controller" was added in SC8.0 (GPL).

                    See post from 8/14/08 below...


                    On something like an "Application Controller" - this is a major post-7.0 direction for us - more "application scaffolding" that captures best practices in applications that have many screens or modules.


                    Thanks,
                    Mike

                    Comment

                    Working...
                    X