tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/1186-putting-the-model-view-and-controller-folders-besides-appconfigas-and-mainasRobotlegs: Discussion 2013-03-29T09:33:31Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/261152582013-03-28T12:27:21Z2013-03-28T12:27:21ZPutting the Model, View and Controller folders besides appConfig.as and Main.as<div><p>Hey!</p>
<blockquote>
<p>I experimented with a small project, and it seems ok. But not
sure, if this affects or breaks some rule that MVC takes care of .
Like if something can go wrong if they are packaged togather.</p>
</blockquote>
<p>If you had a structure like this one:</p>
<p>-src</p>
<p>-----model</p>
<p>----------SomeModel.as</p>
<p>-----view</p>
<p>-----controller</p>
<p>And then you’d inject your model like this:<br>
[Inject] public var model:SomeModel;</p>
<p>and tried to access it like this:<br>
model.getSomeProperty();</p>
<p>you’d probably get an error like : Call to a possibly
undefined method getSomeProperty()<br>
and a warning that would read like this:</p>
<p><code>Definition name is the same as an imported package
name.<br>
Unqualified references to that name will resolve to the package and
not the definition. If a definition is named the same as a package
that is in scope, then any unqualified references to that name will
resolve to the package instead of the definition. This can result
in unexpected errors when attempting to reference the variable. Any
references to the definition need to be qualified to resolve to the
definition and not the package.</code></p>
<blockquote>
<p>PS: by packaging togather, i mean app.AppConfig , app.Main,
app.model.StatsModel , app.controller.XYZCommand etc.</p>
</blockquote>
<p>This would be ok. It wouldn’t hurt though to put AppConfig
under app.config :)</p>
<p>Following the naming packages conventions<br>
[<a href=
"http://help.adobe.com/en_US/AS2LCR/Flash_10.0/00000483.html#280733">http://help.adobe.com/en_US/AS2LCR/Flash_10.0/00000483.html#280733</a>
],<br>
this would be a better choice:<br>
domain.project.area.model.SomeModel</p>
<p>Did I answer your questions, Vishwas?</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/261152582013-03-28T19:08:08Z2013-03-28T19:08:08ZPutting the Model, View and Controller folders besides appConfig.as and Main.as<div><p>it's like this ( following) , after i transferred all the 3
packages into app. Previously they were in a different folder and
different package outside "src" folder. That folder was included as
source folder.</p>
<p>-src</p>
<p>---app
<<<<<<<<<<<<<<<<<<
i noticed you didnot include this</p>
<p>-----model</p>
<p>----------SomeModel.as</p>
<p>-----view</p>
<p>-----controller</p>
<p>I understand the need of separate folder structuring and
packages... but recently got tired of number of different folders,
which became very confusing to browse through. So was trying to
merge things up, where ever possible.</p>
<p>Thnx though, I think i got the answer !</p>
<p>V.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/261152582013-03-29T09:33:31Z2013-03-29T09:33:31ZPutting the Model, View and Controller folders besides appConfig.as and Main.as<div><blockquote>
<p>I understand the need of separate folder structuring and
packages... but recently got tired of number of different folders,
which became very confusing to browse through. So was trying to
merge things up, where ever possible.</p>
</blockquote>
<p>Yeah, I know what you mean and feel. But, in a big project, a
good folder/packages structure makes a lot of sense and is very
helpful. If it’s confusing to browse through, that might be a
sign that you have to rethink the structuring and naming of the
functional areas and classes ;)</p></div>Ondina D.F.