tag:robotlegs.tenderapp.com,2009-10-18:/discussions/suggestions/42-directory-structure-for-flex-projectRobotlegs: Discussion 2018-10-18T16:35:21Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/48121892011-01-19T09:54:20Z2011-01-19T09:54:20Zdirectory structure for flex project<div><p>It looks perfect for me. I'm also using such kind of
structure.</p></div>krasimirtag:robotlegs.tenderapp.com,2009-10-18:Comment/48121892011-01-19T11:04:40Z2011-01-19T11:04:40Zdirectory structure for flex project<div><p>I prefer</p>
<p>feature -> api -> events<br></p>
<pre>
<code> -> core (this contains interfaces only)
-> vos
-> restricted -> controller -> commands
-> controller -> events
-> model
-> services
-> view (which contains views and mediators)</code>
</pre>
<p>I find it better to put views and mediators in the same
package.</p>
<p>1) This allows the use of 'internal' to give package level
access to functions, so that the mediator can run an init() for
example</p>
<p>2) If you have SomeView and SomeViewMediator then you can
instantly see whether each view has its own mediator as they sit
next to each other in the directory.</p>
<p>Commands and Events are a form of control. 'Controller'
designates the purpose of the package, not the pattern or approach
being applied.</p>
<p>Higher up, I split my classes by feature and then use the
FlexPMD compatible api / restricted package split to.</p>
<p>Obviously if there are a lot of classes in any package then I
further split it, but this is the overall structure.</p>
<p>But I suspect this is a case of each-to-his-own.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/48121892011-01-19T11:19:54Z2011-01-19T11:19:55Zdirectory structure for flex project<div><p>"Commands and Events are a form of control."</p>
<p>i would disagree little bit here, as i view events more like
'messages' and commands more like 'functions'... function is
triggered by message, but message itself doesnt execute anything...
so i wouldn't mix those 2 here. what you think?</p></div>peter.ducaitag:robotlegs.tenderapp.com,2009-10-18:Comment/48121892011-01-19T11:30:59Z2011-01-19T11:30:59Zdirectory structure for flex project<div><p>Think higher level. What do Commands and Events achieve for your
application? What would happen if you deleted them?</p>
<p>Your application would likely just sit there in its starting
state.</p>
<p>My application has no conventional 'controller' classes, yet
somehow it is possible to move from state 1 to state 2... so who
does the control?</p>
<p>Ah, that would be the Commands and Events (chained together by
the commandMap).</p>
<p>So - forget messages / functions / details - that's about
implementation. At the level of 'Purpose' - 'Why is this class in
my application?' - Commands and Events are there to provide the
control.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/48121892011-01-19T12:00:21Z2011-01-19T12:00:22Zdirectory structure for flex project<div><p>nice explanation :) i just dont think orthodox programmers gonna
like it... which fortunately is not my case ;)</p></div>peter.ducai