ALS

Welcome to ALS documentation

And thank you for considering using this library!

Don't know what ALS is? Check out its GitHub page, demos and this project to see what it can do.

Docs overview

To start off, read this important entries:

  1. L.ALS - What ALS is and how it works.
  2. L.ALS.System - A basic workflow.
  3. L.ALS.Layer - How to create a layer.
  4. L.ALS.Widgets - How to work with widgets.
  5. L.ALS.Wizard - What a wizard is and how to create one.
  6. L.ALS.Settings - How to create settings for your layer.
  7. L.ALS.Serializable - How to serialize your layer, so users will be able to save and load projects.
  8. L.ALS.Locales - How to localize your application.

You may also find these entries useful:

  1. L.ALS.Widgetable - General information about Widgetable classes such as layers, wizards and settings.
  2. L.ALS.Helpers - Useful helper methods and properties.
  3. L.ALS.LeafletLayers - Some cool Leaflet layers.
  4. L.ALS.ControlZoom - Zoom control which matches ALS aesthetics.
  5. L.ALS.WidgetableWindow - A widgetable window.

Important notes

ALS uses Leaflet class system. Please, read about it at Leaflet docs.

ALS includes RemixIcon icon pack which you can use. Some ALS parts even directly support setting RemixIcon classes.

ALS includes following polyfills:

  1. Babel polyfills and runtime
  2. CoreJS
  3. classList.js
  4. keyboardevent-key-polyfill

ALS applies following patches to the Leaflet classes:

  1. Adds L.Layer#setInteractive, L.Layer#getInteractive and L.Layer#isInteractive methods. Originally made by Piero "Jadaw1n" Steinger.
  2. Patches L.FeatureGroup#addLayer to recursively assign L.FeatureGroup#options.pane to added layers and groups.
  3. Changes markers' Z index in custom panes, so markers will be placed on top of the layers.

Please, test your application before adding any other polyfills (even CoreJS and Babel Runtime!) because it might work just fine as it is.

Do NOT mangle object properties unless it uses hashing! It'll break everything that depends on serialization: projects, settings and undo/redo.

Project file format

Projects are made by serializing everything to JSON: layers, menus, widgets, etc. It's done this way so people will be able to make their applications as dynamic as they want.

Both bless and curse of this is that changes in application introduces changes in project format. Yes, you won't need to change anything related to the file format, system will do everything for you. But you need to either provide a way to convert old projects to a new format or test everything carefully before the release.

Coding guidelines

These guidelines are used in ALS, required for ALS modules (if you want to create one) and recommended for applications using ALS:

  • Use one file per class. Such files should be named exactly the same as classes.
  • Other files' names (such as build scripts) should use camelCaseWithSmallFirstLetter.
  • Namespaces, classes and static fields should use CamelCase.
  • Instance fields, methods, variables and functions should use camelCaseWithSmallFirstLetter.
  • Private and package-only members should start with an underscore (_).
  • Use of JSDoc is highly encouraged. Look at ALS source code to find out how to use it correctly.
  • As for code formatting, you may use any style and linter you want.

In which namespace your modules should be:

  • ALS layers, wizards, settings, widgetables and other meta stuff goes directly to L.ALS.
  • Widgets goes to L.ALS.Widgets.
  • Leaflet layers that uses ALS goes to both L and L.ALS.LeafletLayers. Other Leaflet layers still goes to L.
  • Locales goes to L.ALS.Locales.

Where to report issues with the docs?

To the ALS repo.