tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/12546-assets-locationRobotlegs: Discussion 2014-12-17T15:10:22Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/354459222014-12-03T16:03:38Z2014-12-03T16:03:38ZAssets location<div><p>Hi Philip,</p>
<p>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...</p>
<p>I think, both of your approaches are ok.</p>
<p>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;)</p>
<p>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.<br>
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.<br>
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.<br>
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.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/354459222014-12-04T08:14:05Z2014-12-04T08:14:05ZAssets location<div><p>Hi Ondina,</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Thanks again,<br>
Philip</p></div>Philiptag:robotlegs.tenderapp.com,2009-10-18:Comment/354459222014-12-05T11:49:56Z2014-12-05T11:49:56ZAssets location<div><p>Wow, your heroes, how flattering! Thanks Philip.</p>
<p>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.<br>
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.</p>
<p>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.</p>
<p>So, if you feel that your second approach will best fit your
projects requirements, don't hesitate to adopt it!!<br>
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.</p>
<p>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.</p>
<p>I'm starting to diverge from your original question. Stopping
now:)</p></div>Ondina D.F.