Assets location

Philip's Avatar

Philip

03 Dec, 2014 09:47 AM

Hey,

where would you put an asset folder in a multiple context setup?

like so:

  • assets
    • AssetA
    • AssetB
  • src
    • modulea
      • ContextA
    • moduleb
      • ContextB

or

  • src
    • modulea
      • assets
        • AssetA
      • ContextA
    • moduleb
      • assets
        • AssetB
      • ContextB

where AssetA and AssetB are used by ContextA and ContextB respectively and not shared.

I guess a side question would be whether the aim of a context is to be its own application domain. Does that make sense?

thanks,
Philip

  1. Support Staff 1 Posted by Ondina D.F. on 03 Dec, 2014 04:03 PM

    Ondina D.F.'s Avatar

    Hi Philip,

    Good question, even if it's not a robotlegs question per se. The answer is: it depends on the nature of the project, on project's requirements, on your own or your team's preferences...

    I think, both of your approaches are ok.

    If the modules were to be compiled with the main application, the most used structure is your first one. Inside of 'assets' you can create subfolders for each type of assets (text, images, fonts, sounds...). And if you want to make a distinction between module's A and B assets in some way, you can have assets/moduleA/images, assets/moduleA/sounds, assets/moduleB/images ..- just for the sake of a perfect structure;)

    Now the question is, do you need one or all of those assets to be used among other applications as well? If the answer is yes, I'd create an swc library. Or more libraries, if need be.
    Say, a logo image for your company, an image of yourself and some text files that you'd use in all your projects, would be good candidates for a shared library.
    Sometimes when you start a project you don't know if you'll ever need to reuse a certain asset or certain classes from your current application.
    But, I think it is always good to design new applications with reusability in mind. For example, a good reason to package your assets in a separate library right from the start is if you suspect that you'll want to have a mobile and/or a desktop version of your current application that you're developing for browsers. Another reason could be if you wanted to test your modules separately. I use this approach very often, especially in larger projects (separate projects for each module and shared libraries projects). And yet another reason for a shared library is if, for example, another team would be responsible for designing your graphical assets or some custom skins.

    Ondina

  2. 2 Posted by Philip on 04 Dec, 2014 08:14 AM

    Philip's Avatar

    Hi Ondina,

    I know it's not robotlegs question per se, but as the RL support staff are my heroes and a very reliable source, in particular in architectural topics, and since I only really started structuring my code in a more modular fashion after the introduction of multiple contexts in RL, I thought I'd post the question right here. So thank you for taking the time to answer my question anyways.

    The first approach, the one with an external folder and subfolders that somewhat mirrors the package structure or feature set, is what we've always used for monolithic applications, but as my codebase grows more modular in nature and as I would like to develop and test these modules in isolation, the thought popped up that perhaps I need to change how I structure the assets and move them somewhat closer to the relevant modules for better flexibility. For this reason the question arose.

    The only type of modules that produce a bit of friction are the ones that are project nonspecific (from a code point of view) and that use assets which vary depending on the project. Most other modules either don't use assets or have mostly fixed assets. When I think about it, where I put the assets is completely irrelevant.

    Well, I also don't want to be anal about it. I'm sure a little assets puffing and fitting, shared or not, would do the trick in most cases and on a project to project basis.

    Thanks again,
    Philip

  3. Support Staff 3 Posted by Ondina D.F. on 05 Dec, 2014 11:49 AM

    Ondina D.F.'s Avatar

    Wow, your heroes, how flattering! Thanks Philip.

    The forum is full of questions that are not directly related to the framework, so don't you worry about your question. What I actually meant to say was that robotlegs doesn't impose a certain way of structuring your projects. Of course, there is the proposed "MVC structure", but even that is a more general pattern, not only typical for rl.
    If we look at other programming platforms as well, we can see that finding the optimal package structure is a perpetual and widespread dilemma, and that there are almost as many 'best practices for structuring your project' as there are programming languages.

    In my experience, any project, maybe with the exception of very small ones, undergoes structural changes over time. What seemed to be a good structure in the beginning, might reveal itself to be too "rigid", or on the contrary, too "flexible" as the project grows.

    So, if you feel that your second approach will best fit your projects requirements, don't hesitate to adopt it!!
    My motto is, use design patterns as much and as often as possible, but don't let them use you. I see them as tools/instruments, as a means to accomplishing a task. I think it is much more difficult to recognize or identify the tasks than it is to find the right tool for a certain task. So, first recognize the task, then look for the appropriate tool. We often do the exact opposite, we try to forcefully use a nice tool (MVCS pattern) to solve all of our problems (different projects), like trying to fit square pegs into round holes.

    I also think that an application is like a living organism, it has to adapt to its environment in order to survive and to optimally function, maintaining its stability over time -homeostasis. But, homeostasis means a dynamic equilibrium, not a static, unchangeable one. So, in our programming world, refactoring and restructuring are necessary adjustments mechanisms.

    I'm starting to diverge from your original question. Stopping now:)

  4. Ondina D.F. closed this discussion on 17 Dec, 2014 03:10 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac