Home → Resources and Examples - Robotlegs 1 →

Tracking the Start-up Process of a Flex-RL application

• Edit

Ondina D.F.

01 Aug, 2011 01:28 PM

This is a continuation of this discussion
http://knowledge.robotlegs.org/discussions/problems/353-mediator-ca...

I hope it’s the right place for it.

Good points and suggestions, Tim! Thank you.
Answering your questions:

Do you think it would make sense to somehow differentiate the ContextEvent.STARTUP chevron visually? I'm thinking that the other events are triggered by either Flex Components or by RL Internals, whereas ContextEvent.STARTUP is a rather arbitrary event and could be confused in this diagram for a "system" level event. Would it be slightly less confusing, do you think, to lower the ContextEvent.STARTUP chevron so that it would not be parallel (on the same Lifeline) with the mapInjections in the rightmost swimlane? I don't think they are related, but being parallel in the diagram makes you associate them. I've attached a small mockup of what I mean.

Yes, to all suggestions. I was thinking that maybe we should use another custom Event, and name it differently, for example MappingsEvent.START_MAPPING and MappingsEvent. MAPPING_COMPLETE, but that would confuse new users, I guess. But the color and position of the symbol used in the diagram should be different, as you suggested.

MapView.registerMediator()->MediatorBase.preRegister()->MediatorBase.onRegister() where ApplicationMediator.onRegister()->super() would call the same MediatorBase.onRegister(). It's not yet clear to me how this works since visually the linear continuity is interrupted.

Yes, in MapView.registerMediator() there is mediator.preRegister();, where “mediator” is the already created ApplicationMediator in createMediatorUsing()
So by extending Mediator, ApplicationMediator is the one (overriding) calling MediatorBase.onRegister().Actually ApplicationMediator extends Mediator, which extends MediatorBase, which implements IMediator.

So actually, in my understanding, there should be an arrow from MapView.createMediatorUsing towards IMediator, which is missing from the RobotlegsInternal swimlane, and an arrow from ApplicationMediator towards IMediator.
I also omitted the override and extends labels on the arrows in ContextView Flow diagram.
Also, the arrows I used are not representing the correct classes-relationships.

I wanted to have fewer details, but if that’s confusing maybe we should add IMediator to the RobotlegsInternal swimlane. Or Mediator? I’m not sure which one.

Should we show the SomeModelEvent.DATA_UPDATED chevron for completeness' sake, or do you think it's unnecessary?

Yes, but maybe first we should have incremental diagrams and code, that is, from very simple to more complex, meaning more diagrams, that would reflect the flow of each code example.

I will try to make one much more generic than the actual ContextView flow, then to add “actors” and relationships gradually. So the SomeModel could be introduced later. The complete flow for Robotlegs Internal will be shown in a later stage or a separate diagram?

And I'm wondering whether we are showing a flow that won't work.

Of course the code should reflect the diagram or actually vice versa, the diagrams should be a correct representation of the code. That is a work in progress though. I hadn’t had the time yet to “synchronize” the code with the diagrams, and actually the diagrams I uploaded were just drafts and open for discussion :)

And lastly, do you think SomeModel.setData() belongs in the Flex Components swimlane? It's tough to place the model here.

I thought that maybe we could introduce a function in the view that would set the dataProvider of the list. So onDataUpdated() the Mediator would call view.setData(event.payload).
I’ll do that in the code, and I also will try to have better names for everything in there.

So that’s it for now. I’ll see if I’ll be able to make the changes to the code and diagrams today, at least the first two incremental steps. I’m hoping that after I produce the diagrams, you’ll make them better, nicer and so on.
I also hope that later, when the time for a readme.txt (on github) will come, you’ll help me by correcting awkward formulations and/or add your own explanations. My English is what it is ;)

Later this week I will put our project on github, if I still know how it works. It’s been a while since my last github activity. Anyway, if you had a github account we could exchange images and/or code snippets there instead of this forum, so this thread won’t explode because of our many posts ;)

Thanks for the suggestions and ideas.

Ondina

1. 1 Posted by Timur on 02 Aug, 2011 05:42 AM

   

   Hi Ondina,

   MappingsEvent.START_MAPPING and MappingsEvent would work. Maybe we could put a small legend on top that would define the working color palette, where Flex Component/App Events would be, say, (pale) purple as you have already, RL Events could be another color, and user created, custom Events could be yet another color.

   So actually, in my understanding, there should be an arrow from MapView.createMediatorUsing towards IMediator, which is missing from the RobotlegsInternal swimlane, and an arrow from ApplicationMediator towards IMediator.

   That would be helpful, I think. The arrow from ApplicationMediator towards IMediator that you mention, on which Lifeline would that belong?

   The override and extends labels on the arrows would not, I believe, add to the confusion, but rather would reinforce their purpose.

   I wanted to have fewer details, but if that’s confusing maybe we should add IMediator to the RobotlegsInternal swimlane. Or Mediator? I’m not sure which one.

   Good question. One of them definitely belongs in the RL Internal. Maybe Mediator? But then I guess it would be left of MediatorBase.

   Yes, but maybe first we should have incremental diagrams and code, that is, from very simple to more complex, meaning more diagrams, that would reflect the flow of each code example.

   That's a great idea. The user could drill deeper if the top level diagrams do not clarify the flow.

   I will try to make one much more generic than the actual ContextView flow, then to add “actors” and relationships gradually. So the SomeModel could be introduced later. The complete flow for Robotlegs Internal will be shown in a later stage or a separate diagram?

   I agree. There's just too much to take in at once. Revealing detail gradually is good. Maybe we could eventually turn it into an interactive diagram that would reveal contextually detail on need to know basis. We could build it in HTML5! (...I kid).

   And I'm wondering whether we are showing a flow that won't work.

   Of course the code should reflect the diagram or actually vice versa, the diagrams should be a correct representation of the code.

   Of course, understood. I just got confused when I followed the diagram mentally and then realized that the flow it was illustrating was the one that did not work due to race conditions, the very thing that started this thread to begin with. It made me scratch my head a bit.

   I thought that maybe we could introduce a function in the view that would set the dataProvider of the list. So onDataUpdated() the Mediator would call view.setData(event.payload).

   That makes sense and it coincides with the RL best practices.

   I’m hoping that after I produce the diagrams, you’ll make them better, nicer and so on.

   Certainly.

   I also hope that later, when the time for a readme.txt (on github) will come, you’ll help me by correcting awkward formulations and/or add your own explanations. My English is what it is ;)

   Of course. I'm looking forward to it.

   You English is excellent, btw.

   Thanks for your work, again.

   Tim

   • Edit

2. Support Staff 2 Posted by Ondina D.F. on 02 Aug, 2011 04:30 PM

   

   Hi Tim,

   The attached file contains 3 projects, actually the same one in 3 steps. First, only the ContextView, second SomeView + ContextView + service call on mappings complete, which won’t work for SomeView, and third SomeView + ContextView + service call on application complete. I intend to make them even more granular, but for now the 3 steps should illustrate what I meant.
   I made some changes to the trace statements as well, and have no idea if it’s any better than before, but I’m sure about being absolutely dizzy and [ please fill in any other synonyms with a stronger meaning than dizzy] :)
   So whatever I had to say in response to your post is gone now. I’ll answer tomorrow.
   Please look at the code and trace statements and tell me your opinion. If you think they are ok, I’ll upload them on github in the next days.
   Thank you:)
   Ondina

   • robotlegs-incremental-takeone.zip 166 KB
   • Edit

3. 3 Posted by Timur on 03 Aug, 2011 05:03 AM

   

   Hi Ondina,

   Let me look into the code and get back with some ideas.

   Thanks,

   Tim

   • Edit

4. Support Staff 4 Posted by Ondina D.F. on 03 Aug, 2011 02:10 PM

   

   Tim,

   Maybe we could put a small legend on top that would define the working color palette,

   Good idea.

   That would be helpful, I think. The arrow from ApplicationMediator towards IMediator that you mention, on which Lifeline would that belong?

   I added Mediator to the Robotlegs Internal swimlane, instead of IMediator, just because the concrete Mediators (ApplicationMediator and SomeMediator) extend Mediator. The arrow would go from createMediatorUsing() to Mediator’s constructor and from Mediator to MediatorBase (extends) and from here to IMediator. So there are 2 possibilities:
   1. to keep all 3, Mediator, MediatorBase and IMediator and to show the proper relationship between them, or
   2. to have just Mediator (with the methods from MediatorBase) and to mention the inheritance in a Note
   1. would add complexity, so I would opt for 2. And if it wouldn’t be clear enough, then it should link to another detailed diagram.
   I think you’d agree, at least you were saying:

   I agree. There's just too much to take in at once. Revealing detail gradually is good. Maybe we could eventually turn it into an interactive diagram that would reveal contextually detail on need to know basis. We could build it in HTML5! (...I kid)

   Haha. HTML5 ? ok, why not?;) But I’m a complete html5 newbie, so you do it! It’s a shame, but I haven’t had the time to play around with it yet. And without Robotlegs for HTML5 I refuse to even look at it! Me kidding too.
   But the idea of an interactive app is interesting! We could make a Flex app, doing just that: showing a diagram and a textual description/explanation, and on button click opening the corresponding application in another browser’s tab. That would take a while, though.
   See, our actual project is extremely simple, and putting trace statements in different places is an absolutely trivial task, but it’s time consuming. The same goes for making diagrams in EA, as you know from your own experience.

   The override and extends labels on the arrows would not, I believe, add to the confusion, but rather would reinforce their purpose.

   Ok. I’ll change that.

   Ha! I just added a trace() in MediatorMap. onViewAdded(). Every shape, group, button etc in the application dispatches an addedtostage event and the handler reacts to all of them! I shouldn’t have looked at this handler ;)

   Ondina

   • Edit

5. 5 Posted by Timur on 04 Aug, 2011 04:36 AM

   

   Hi Ondina,

   Haha. HTML5 ? ok, why not?;) But I’m a complete html5 newbie, so you do it! It’s a shame, but I haven’t had the time to play around with it yet. And without Robotlegs for HTML5 I refuse to even look at it! Me kidding too.

   I was truly joking about HTML5. It's almost an inside joke among some Flash devs.

   See, our actual project is extremely simple, and putting trace statements in different places is an absolutely trivial task, but it’s time consuming. The same goes for making diagrams in EA, as you know from your own experience.

   Agreed. I have moved on to Illustrator. If I had the time, I would probably write some jsfl for Illustrator to automate the creation of diagram elements/actors, etc.

   Ha! I just added a trace() in MediatorMap. onViewAdded(). Every shape, group, button etc in the application dispatches an addedtostage event and the handler reacts to all of them! I shouldn’t have looked at this handler ;)

   Would it make sense to put a conditional in the trace statement so that it would fire only if ContextView is handled?

   Attached is the cleaned up WIP diagram.

   Here are your trace statements from Take One Project:

   1 [Flex] ContextView/Application on FlexEvent.PREINITIALIZE
   2 [Impl] [Context] Constructor ApplicationContext(contextView, autoStartup)
   3 [RL] [Context] Constructor Context(contextView, autoStartup)
   4 [RL] [Context] mapInjections()
   5 [RL] [MediatorMap] Constructor MediatorMap(contextView, injector, reflector)
   6 [RL] [Context] checkAutoStartup() contextView.stage ? startup() : contextView.addEventListener(Event.ADDED_TO_STAGE, onAddedToStage)
   7 [Flex] ContextView/Application on FlexEvent.INITIALIZE
   8 [Flex] ContextView.mainList on FlexEvent.CREATION_COMPLETE
   9 [Flex] ContextView/Application on FlexEvent.CREATION_COMPLETE
   10 [Flex] ContextView/Application on Event.ADDED_TO_STAGE
   11 [RL] [Context] onAddedToStage(Event.ADDED_TO_STAGE)
   **********************************************************************************
   12 [Impl] [Context]***************** ApplicationContext.mapMappingsCommands() dispatchEvent(new MappingsEvent(MappingsEvent.START_MAPPING));
   **********************************************************************************
   13 [Impl] [Command] MapControllersCommand.execute()
   14 [Impl] [Command] MapModelsCommand.execute()
   15 [Impl] [Command] MapServicesCommand.execute()
   16 [Impl] [Command]  MapViewsCommand.execute()
   17 [RL] [MediatorMap] addListeners() if (contextView)  contextView.addEventListener(Event.ADDED_TO_STAGE)
   18 [RL] [MediatorMap] mapView() if (autoCreate && contextView)  mapView() Step1 [class ApplicationMediator]
   19 [Impl] [Mediator] Constructor ApplicationMediator()
   20 [RL] [MediatorBase] Constructor MediatorBase.MediatorBase() 
   21 [RL] [Mediator] Constructor Mediator()
   22 [RL] [MediatorMap] createMediatorUsing() Step1 [object ApplicationMediator]
   23 [RL] [MediatorMap] registerMediator()  [object ApplicationMediator] for Step1
   24 [RL] [MediatorBase] preRegister() Step1 initialized
   25 [Impl] [Mediator] ApplicationMediator.onRegister() <<<<<<<<<<<<<<<<<
   **********************************************************************************
   26 [Impl] [Context] ******************ApplicationContext.onMappingComplete(MappingsEvent.MAPPING_COMPLETE) ******************
   **********************************************************************************
   27 [Impl] [Command] SomeServiceRequestCommand.execute()
   28 [Impl] [Service] SomeService.onServerResult(someServiceResult:Array)
   29 [Impl] [Command] SomeServiceResultCommand.execute()
   30 [Impl] [Model] SomeModel.set someData(value)
   31 [Impl] [Mediator] ApplicationMediator.onDataUpdated(event:SomeModelEvent) <<<<<<<<<<<<<<<<<
   32 [Flex] ContextView.setListDataProvider(dataProvider)<<<<<<<<<<<<<<<<<
   33 [RL] [Context] Context.startup()
   **********************************************************************************
   34 [Impl] [Context] ****************** ApplicationContext.onStartUpComplete(event) ******************
   **********************************************************************************
   35 [Flex] ContextView.mainList on Event.ADDED_TO_STAGE
   **********************************************************************************
   36 [Impl] [Context]***************** ApplicationContext on FlexEvent.APPLICATION_COMPLETE ******************
   **********************************************************************************
   37 [Flex] ContextView/Application on FlexEvent.UPDATE_COMPLETE
   

   I cleaned up the diagram and got through step 12. What's blocking my progress are some decisions that have to be made. If any of these questions are answered by your previous posts or the other two projects, then forgive me as I had not any time to delve thoroughly into those yet.

   Steps 13-16 would require us to show four commands. If we do, they would precede SomeCommand, I'd think. Do we want to show them here, or should we stave that off for more granular diagrams/animations?

   16 [Impl] [Command] MapViewsCommand.execute(). We might need to show this in the diagram in order to show the resulting sequence of 17-25. What do you think?
   28 Would require SomeService to be shown, that could go into RL Implementation, or we could skip the service sequence. Although, it could be useful to show SomeService as it illustrates a very common need in today's apps, where as soon as the app has finished bootstrapping, it calls the initial service to get the typical dataset/XML.

   Thanks,

   Tim

   • Robotlegs_ContextView_Flow_TakeOne.pdf 875 KB
   • Edit

6. Support Staff 6 Posted by Ondina D.F. on 04 Aug, 2011 02:55 PM

   

   Tim, I know that you were kidding about HTML5 :)

   First thought about Illustrator was that it is indeed better than EA, for colors, custom shapes and alike, but not the best tool for diagramming though. I know that there are other tools out there, that are easier to use, but I don’t remember their names and I don’t have any time for research.

   Maybe someone reading this thread can help us find a free and good diagramming tool?

   If we can’t find something better, then Illustrator should suffice, at least it is capable of exporting to .pdf and loading .pdf, and that’s a good thing in the case of a collaboratively work on a file. I will continue to use EA (next to Illustrator), for establishing the relationships between classes, even if the shapes or arrows won’t be nice or uml-correct.

   I put this conditional inside of MediatorMap:

   //robotlegs

   var config:MappingConfig = mappingConfigByViewClassName[viewClassName];

   //my condition

   if( config!=null)
   trace("[RL ][MediatorMap]MediatorMap.onViewAdded(e) "+ e.target.constructor");

   so only mapped views will appear in the trace.

   I created a repository on github:
   https://github.com/Ondina/robotlegs-incremental
   containing the 3 steps projects

   Just in case you’re new to GitHub, there is also a Downloads button on the page, where you can dl robotlegs-incremental-taketwo.zip with the changes that I made today.

   Steps 13-16 would require us to show four commands. If we do, they would precede SomeCommand, I'd think. Do we want to show them here, or should we stave that off for more granular diagrams/animations?

   SomeCommand was a bad name and it doesn’t exist in the code as such. The intention was to have SomeServiceRequestCommand, SomeServiceResultCommand, SomeModel and SomeService under one hut. I can’t think of a better name right now, but having them grouped together in a diagram, and then showing more details in another, isn’t a bad idea, is it? Is GettingDataProcess, or something like that, describing the process better? So the short answer should have been: more granular.

   16 [Impl] [Command] MapViewsCommand.execute(). We might need to show this in the diagram in order to show the resulting sequence of 17-25. What do you think?

   In my Robotlegs ContextView Flow I put all the mapping commands in a Note attached to the action “mapping” and then an arrow from it to mapView, with the idea in mind of showing the details elsewhere. But if it’s confusing, then yes, let’s have MapViewsCommand.execute() instead of mapView().

   28 Would require SomeService to be shown, that could go into RL Implementation, or we could skip the service sequence. Although, it could be useful to show SomeService as it illustrates a very common need in today's apps, where as soon as the app has finished bootstrapping, it calls the initial service to get the typical dataset/XML.

   As said above, I would opt for showing the Command-Model-Service flow in another diagram. It is indeed a very common use case to get the data after bootstrapping! So it deserves special attention :) I thought that in other “steps” we would show different places/ points in time in the application where a service call makes sense and where it works or not, and why not.

   So just a draft:
   Step 1
   ContextView, GettingDataProcess before mappings(on START_MAPPING) - won’t work

   Step 2
   ContextView, GettingDataProcess after mappings(on MAPPING_COMPLETE) - would work

   Step 3

   ContextView, SomeView, GettingDataProcess after mappings - won’t work for SomeView

   Step 4
   ContextView, SomeView, GettingDataProcess after application complete - would work for both

   Step 5
   ContextView, GettingDataProcess after mappings,
   SomeView after application complete in the Mediator onRegister - would work for both

   and so on.

   GettingDataProcess would be a reference to another diagram.
   MappingProcess another diagram containing the mapping commands
   and [IDontKnowHowToNameIt] for Context, MapMediator, Mediator. Maybe simply “RobotlegsInternalProcess”?

   In my WIP Robotlegs ContextView diagram I accidentally put MapView instead of MediatorMap under RobotlegsInternal!!
   I changed it and other details there, after you commented on it, but it’s still not ok. It isn’t granular enough for the parts we discussed above, and it’s also not simple enough to be used as is. And probably some arrows go in the wrong direction. Wishy washy. I haven’t had the time for making better diagrams. Anyway, I’ll upload it (github), just to keep you updated:) I’m working now with a trial version of the last EA, so the background is.. you’ll see.
   In another post, you said something about the events chevron’s position being confusing. I think their shape is also confusing, because they show towards other swimlanes, as if they trigger some actions there. Maybe we should use another symbol?

   Out of ideas :)
   Ondina

   • Edit

7. 7 Posted by Timur on 04 Aug, 2011 10:41 PM

   

   Hi Ondina,

   Some very preliminary replies...

   I know that there are other tools out there, that are easier to use, but I don’t remember their names and I don’t have any time for research.

   You are right that Illustrator is not the ideal tool for it, but I prefer it to EA. One other free diagramming tool you might want to try is yED.

   I created a repository on github: https://github.com/Ondina/robotlegs-incremental
   containing the 3 steps projects

   What do you use to compile these projects? I didn't notice any FB or IDEA config files. Are you using a command prompt with a text editor? Just curious, because if I clone these projects and set them up with FB or IDEA, then will git overwrite my config settings in these folders? Haven't tried this yet.

   Is GettingDataProcess, or something like that, describing the process better?

   So steps 13-16 will be represented by GettingDataProcess (or maybe GettingDataFromServiceProcess? ) placeholder, that later on could be fleshed out into a detailed diagram, yes?

   But if it’s confusing, then yes, let’s have MapViewsCommand.execute() instead of mapView().

   I think, as I much as I would like to skip this command in the diagram, it will be necessary to show because it seems integral to this particular flow. I could make MapViewsCommand in Implementation swimlane. Also, we're losing the MapView Actor, which was a mistake. Thanks for pointing that out.

   I would opt for showing the Command-Model-Service flow in another diagram.

   Yes. I will take out SomeCommand out of this diagram, then. Later, in GettingDataFrom[Service]Process diagram, that command would be replaced by SomeServiceRequestCommand and SomeServiceResultCommand.

   I thought that in other “steps” we would show different places/ points in time in the application where a service call makes sense and where it works or not, and why not.

   That's the plan. So how many "steps" should there be, not counting ancillary diagrams like GettingDataFrom[Service]Process, MappingProcess, etc.? And how many ancillary diagrams? Maybe we should outline them now, even with placeholder names.

   And probably some arrows go in the wrong direction. Wishy washy.

   Yes. That is a problem I'm facing as well. Haven't found a solution yet.

   In another post, you said something about the events chevron’s position being confusing. I think their shape is also confusing, because they show towards other swimlanes, as if they trigger some actions there. Maybe we should use another symbol?

   We could change the event symbol. I agree, they should not be this directional.

   Now I will review your updated code, and post a general RL question, which I've been meaning to do for a few days ;-)

   Thanks,

   Tim

   • Edit

8. Support Staff 8 Posted by Ondina D.F. on 05 Aug, 2011 09:36 AM

   

   Tim, thank you for all your work and input. And for the yED link!

   I use FlashBuilder 4.5.1.
   .gitignore is telling git which files to ignore. So if you look at my .gitignore you’ll see that the flex settings files, bin and bin-debug are listed there, consequently they will be excluded from tracking.
   Warning: I’m not a git expert!! Haha, doesn’t it sound good?.

   So steps 13-16 will be represented by GettingDataProcess (or maybe GettingDataFromServiceProcess? ) placeholder, that later on could be fleshed out into a detailed diagram, yes?

   Yep. Only that GettingDataFromServiceProcess is a long name for a diagram. It would take to much space. No idea how we should call it yet.

   ...I could make MapViewsCommand in Implementation swimlane.

   Well then I suggest to make a generic „MappingCommands“ or “MappingProcess” as a swimlane , meaning all the mappings, wit details elsewhere.
   So Robotlegs Implementation would contain: ApplicationContext, ApplicationMediator, MappingProcess(?), GettingDataProcess(?)

   So how many "steps" should there be, not counting ancillary diagrams..... Maybe we should outline them now, even with placeholder names

   Until now I’ve been working on our project intermittently.
   Give me a week or so to :

   • think about better names for ancillary diagrams, and their placeholders

   • think about how many steps we really need

   • write the code for those “steps”

   • write an overview

   • make at least ONE diagram, that would be good enough to be used as a template

   I’ll start next week, when, hopefully, I’ll be able to dedicate more time to the RL-Flex-flow and stay focused on it.

   So after I get the above mentioned done it won’t take much longer until we’ll have the final version. I think, until then you shouldn’t waste your time working on diagrams, that aren’t clearly defined. Outlining the steps and knowing exactly what we need or don’t need has priority. What do you think?
   After you review the code and tell me your other suggestions here, we could continue dissecting the code and diagrams on github, adding comments to code or using gist to share code snippets, changing the code ...
   I’ll be away this weekend, but I’ll read your comments anyway.
   Cheers
   Ondina

   • Edit

9. 9 Posted by Timur on 05 Aug, 2011 03:44 PM

   

   Hi Ondina,

   .gitignore is telling git which files to ignore.

   I wish Flash Builder allowed the user to import Flex projects based on the src folder, without those invisible files.

   Only that GettingDataFromServiceProcess is a long name for a diagram.

   Yes, good name for a function, although not precise enough, but far too long for a diagram. Agreed.

   So Robotlegs Implementation would contain: ApplicationContext, ApplicationMediator, MappingProcess(?), GettingDataProcess(?)

   If we'd do that, then the MappingProcess(?) and GettingDataProcess(?) swimlanes should look collapsed or different enough from the other swimlanes to indicate that they are placeholders or containers of other diagrams, so as not to be confused with the principal actors.

   Until now I’ve been working on our project intermittently.

   Understandable. We're not on a clock, luckily. I appreciate your work on this, and I look forward to your ideas.

   Thanks,

   Tim

   • Edit

10. Support Staff 10 Posted by Ondina D.F. on 08 Aug, 2011 06:30 PM

    

    Hi Tim,

    I wish Flash Builder allowed the user to import Flex projects based on the src folder, without those invisible files.

    That shouldn’t be a problem. The .gitignore is meant for github. When you make a new Project by using only the src, FlashBuilder creates all the settings files for you. You’d work with your settings, I’d work with mines. Your changes would be committed to your fork. But you don’t seem to have a github account for that matter.

    Or I misunderstood the question...

    If we'd do that, then the MappingProcess(?) and GettingDataProcess(?) swimlanes should look collapsed or different enough from the other swimlanes to indicate that they are placeholders or containers of other diagrams, so as not to be confused with the principal actors.

    Good suggestion:)

    Thanks,
    Ondina

    • Edit

11. 11 Posted by Timur on 09 Aug, 2011 03:42 AM

    

    Hi Ondina,

    You're right. For some reason I was thinking that Flash Builder would overwrite your src folder. I do have a github account, that's been mostly used as private VC backup. I will fork this project and put up a link, and I will create a diagrams folder to store diagrams.

    Thanks,

    Tim

    • Edit

12. Support Staff 12 Posted by Ondina D.F. on 18 Aug, 2011 01:48 PM

    

    Hi Tim,

    In my github repository there are new diagrams, code and a TrackingtheStartupProcess.txt file with some explanations. If you’re still interested please check them out and tell me what you think.

    Cheers,
    Ondina

    • Edit

13. Ondina D.F. closed this discussion on 01 Nov, 2011 07:13 PM.