directory structure for flex project

peter.ducai's Avatar


19 Jan, 2011 09:49 AM

hi, due to creating software ( to make robotlegs job easier, i'm curious if there's any default directory structure i should use for projects... usually we create structure like this:

src (main app and it's context)
- view - model - mediator - service - event - controller (or command, depending on taste of programmer)

is it OK or should i use some other structure?

  1. 1 Posted by krasimir on 19 Jan, 2011 09:54 AM

    krasimir's Avatar

    It looks perfect for me. I'm also using such kind of structure.

  2. 2 Posted by Stray on 19 Jan, 2011 11:04 AM

    Stray's Avatar

    I prefer

    feature -> api -> events
    -> core (this contains interfaces only)
    -> vos
    -> restricted -> controller -> commands
    -> controller -> events
    -> model
    -> services
    -> view (which contains views and mediators)

    I find it better to put views and mediators in the same package.

    1) This allows the use of 'internal' to give package level access to functions, so that the mediator can run an init() for example

    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.

    Commands and Events are a form of control. 'Controller' designates the purpose of the package, not the pattern or approach being applied.

    Higher up, I split my classes by feature and then use the FlexPMD compatible api / restricted package split to.

    Obviously if there are a lot of classes in any package then I further split it, but this is the overall structure.

    But I suspect this is a case of each-to-his-own.

  3. 3 Posted by peter.ducai on 19 Jan, 2011 11:19 AM

    peter.ducai's Avatar

    "Commands and Events are a form of control."

    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?

  4. 4 Posted by Stray on 19 Jan, 2011 11:30 AM

    Stray's Avatar

    Think higher level. What do Commands and Events achieve for your application? What would happen if you deleted them?

    Your application would likely just sit there in its starting state.

    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?

    Ah, that would be the Commands and Events (chained together by the commandMap).

    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.

  5. 5 Posted by peter.ducai on 19 Jan, 2011 12:00 PM

    peter.ducai's Avatar

    nice explanation :) i just dont think orthodox programmers gonna like it... which fortunately is not my case ;)

  6. Stray closed this discussion on 13 Feb, 2011 04:47 PM.

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

Keyboard shortcuts


? 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