tag:robotlegs.tenderapp.com,2009-10-18:/discussions/resources/34-tracking-the-start-up-process-of-a-flex-rl-applicationRobotlegs: Discussion 2012-02-29T11:53:58Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-02T05:42:25Z2011-08-02T05:42:25ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Ondina,</p>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>That would be helpful, I think. The arrow from
ApplicationMediator towards IMediator that you mention, on which
Lifeline would that belong?</p>
<p>The override and extends labels on the arrows would not, I
believe, add to the confusion, but rather would reinforce their
purpose.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Good question. One of them definitely belongs in the RL
Internal. Maybe Mediator? But then I guess it would be left of
MediatorBase.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>That's a great idea. The user could drill deeper if the top
level diagrams do not clarify the flow.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>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).</p>
<blockquote>
<blockquote>
<p>And I'm wondering whether we are showing a flow that won't
work.</p>
</blockquote>
<p>Of course the code should reflect the diagram or actually vice
versa, the diagrams should be a correct representation of the
code.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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).</p>
</blockquote>
<p>That makes sense and it coincides with the RL best
practices.</p>
<blockquote>
<p>I’m hoping that after I produce the diagrams, you’ll
make them better, nicer and so on.</p>
</blockquote>
<p>Certainly.</p>
<blockquote>
<p>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 ;)</p>
</blockquote>
<p>Of course. I'm looking forward to it.</p>
<p>You English is excellent, btw.</p>
<p>Thanks for your work, again.</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-02T16:30:22Z2011-08-02T16:30:22ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Tim,</p>
<p>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.<br>
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] :)<br>
So whatever I had to say in response to your post is gone now.
I’ll answer tomorrow.<br>
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.<br>
Thank you:)<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-03T05:03:25Z2011-08-03T05:03:25ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Ondina,</p>
<p>Let me look into the code and get back with some ideas.</p>
<p>Thanks,</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-03T14:10:41Z2011-08-03T14:10:41ZTracking the Start-up Process of a Flex-RL application<div><p>Tim,</p>
<blockquote>Maybe we could put a small legend on top that would
define the working color palette,</blockquote>
<p>Good idea.</p>
<blockquote>That would be helpful, I think. The arrow from
ApplicationMediator towards IMediator that you mention, on which
Lifeline would that belong?</blockquote>
<p>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:<br>
1. to keep all 3, Mediator, MediatorBase and IMediator and to show
the proper relationship between them, or<br>
2. to have just Mediator (with the methods from MediatorBase) and
to mention the inheritance in a Note<br>
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.<br>
I think you’d agree, at least you were saying:</p>
<blockquote>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)</blockquote>
<p>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.<br>
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.<br>
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.</p>
<blockquote>The override and extends labels on the arrows would
not, I believe, add to the confusion, but rather would reinforce
their purpose.</blockquote>
<p>Ok. I’ll change that.</p>
<p>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 ;)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-04T04:36:13Z2011-08-04T04:36:13ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Ondina,</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>I was truly joking about HTML5. It's almost an inside joke among
some Flash devs.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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 ;)</p>
</blockquote>
<p>Would it make sense to put a conditional in the trace statement
so that it would fire only if ContextView is handled?</p>
<p>Attached is the cleaned up WIP diagram.</p>
<p>Here are your trace statements from Take One Project:</p>
<pre>
<code>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</code>
</pre>
<p>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.</p>
<p>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?</p>
<p>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?<br>
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.</p>
<p>Thanks,</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-04T14:55:49Z2011-08-04T14:55:49ZTracking the Start-up Process of a Flex-RL application<div><p>Tim, I know that you were kidding about HTML5 :)</p>
<p>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.</p>
<p>Maybe someone reading this thread can help us find a free and
good diagramming tool?</p>
<p>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.</p>
<p>I put this conditional inside of MediatorMap:</p>
<p>//robotlegs</p>
<p>var config:MappingConfig =
mappingConfigByViewClassName[viewClassName];</p>
<p>//my condition</p>
<p>if( config!=null)<br>
trace("[RL ][MediatorMap]MediatorMap.onViewAdded(e) "+
e.target.constructor");</p>
<p>so only mapped views will appear in the trace.</p>
<p>I created a repository on github:<br>
<a href=
"https://github.com/Ondina/robotlegs-incremental">https://github.com/Ondina/robotlegs-incremental</a><br>
containing the 3 steps projects</p>
<p>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.</p>
<blockquote>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?</blockquote>
<p>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.</p>
<blockquote>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?</blockquote>
<p>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().</p>
<blockquote>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.</blockquote>
<p>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.</p>
<p>So just a draft:<br>
Step 1<br>
ContextView, GettingDataProcess before mappings(on START_MAPPING) -
won’t work</p>
<p>Step 2<br>
ContextView, GettingDataProcess after mappings(on MAPPING_COMPLETE)
- would work</p>
<p>Step 3</p>
<p>ContextView, SomeView, GettingDataProcess after mappings -
won’t work for SomeView</p>
<p>Step 4<br>
ContextView, SomeView, GettingDataProcess after application
complete - would work for both</p>
<p>Step 5<br>
ContextView, GettingDataProcess after mappings,<br>
SomeView after application complete in the Mediator onRegister -
would work for both</p>
<p>and so on.</p>
<p>GettingDataProcess would be a reference to another diagram.<br>
MappingProcess another diagram containing the mapping commands<br>
and [IDontKnowHowToNameIt] for Context, MapMediator, Mediator.
Maybe simply “RobotlegsInternalProcess”?</p>
<p>In my WIP Robotlegs ContextView diagram I accidentally put
MapView instead of MediatorMap under RobotlegsInternal!!<br>
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.<br>
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?</p>
<p>Out of ideas :)<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-04T22:41:54Z2011-08-04T22:41:54ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Ondina,</p>
<p>Some very preliminary replies...</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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 <a href=
"http://www.yworks.com/en/products_yed_download.html">yED</a>.</p>
<blockquote>
<p>I created a repository on github: <a href=
"https://github.com/Ondina/robotlegs-incremental">https://github.com/Ondina/robotlegs-incremental</a><br>
containing the 3 steps projects</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>Is GettingDataProcess, or something like that, describing the
process better?</p>
</blockquote>
<p>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?</p>
<blockquote>
<p>But if it’s confusing, then yes, let’s have
MapViewsCommand.execute() instead of mapView().</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>I would opt for showing the Command-Model-Service flow in
another diagram.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>And probably some arrows go in the wrong direction. Wishy
washy.</p>
</blockquote>
<p>Yes. That is a problem I'm facing as well. Haven't found a
solution yet.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>We could change the event symbol. I agree, they should not be
this directional.</p>
<p>Now I will review your updated code, and post a general RL
question, which I've been meaning to do for a few days ;-)</p>
<p>Thanks,</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-05T09:36:42Z2011-08-05T09:36:42ZTracking the Start-up Process of a Flex-RL application<div><p>Tim, thank you for all your work and input. And for the yED
link!</p>
<p>I use FlashBuilder 4.5.1.<br>
.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.<br>
Warning: I’m not a git expert!! Haha, doesn’t it sound
good?.</p>
<blockquote>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?</blockquote>
<p>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.</p>
<blockquote>...I could make MapViewsCommand in Implementation
swimlane.</blockquote>
<p>Well then I suggest to make a generic
„MappingCommands“ or “MappingProcess” as a
swimlane , meaning all the mappings, wit details elsewhere.<br>
So Robotlegs Implementation would contain: ApplicationContext,
ApplicationMediator, MappingProcess(?), GettingDataProcess(?)</p>
<blockquote>So how many "steps" should there be, not counting
ancillary diagrams..... Maybe we should outline them now, even with
placeholder names</blockquote>
<p>Until now I’ve been working on our project
intermittently.<br>
Give me a week or so to :</p>
<ul>
<li>
<p>think about better names for ancillary diagrams, and their
placeholders</p>
</li>
<li>
<p>think about how many steps we really need</p>
</li>
<li>
<p>write the code for those “steps”</p>
</li>
<li>
<p>write an overview</p>
</li>
<li>
<p>make at least ONE diagram, that would be good enough to be used
as a template</p>
</li>
</ul>
<p>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.</p>
<p>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?<br>
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 ...<br>
I’ll be away this weekend, but I’ll read your comments
anyway.<br>
Cheers<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-05T15:44:05Z2011-08-05T15:44:05ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Ondina,</p>
<blockquote>
<p>.gitignore is telling git which files to ignore.</p>
</blockquote>
<p>I wish Flash Builder allowed the user to import Flex projects
based on the src folder, without those invisible files.</p>
<blockquote>
<p>Only that GettingDataFromServiceProcess is a long name for a
diagram.</p>
</blockquote>
<p>Yes, good name for a function, although not precise enough, but
far too long for a diagram. Agreed.</p>
<blockquote>
<p>So Robotlegs Implementation would contain: ApplicationContext,
ApplicationMediator, MappingProcess(?), GettingDataProcess(?)</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>Until now I’ve been working on our project
intermittently.</p>
</blockquote>
<p>Understandable. We're not on a clock, luckily. I appreciate your
work on this, and I look forward to your ideas.</p>
<p>Thanks,</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-08T18:30:41Z2011-08-08T18:30:41ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Tim,</p>
<blockquote>I wish Flash Builder allowed the user to import Flex
projects based on the src folder, without those invisible
files.</blockquote>
<p>That shouldn’t be a problem. The .gitignore is meant for
github. When you make a <strong>new</strong> 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.</p>
<p>Or I misunderstood the question...</p>
<blockquote>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.</blockquote>
<p>Good suggestion:)</p>
<p>Thanks,<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-09T03:42:29Z2011-08-09T03:42:29ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Ondina,</p>
<p>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.</p>
<p>Thanks,</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/89960072011-08-18T13:48:12Z2011-08-18T13:48:12ZTracking the Start-up Process of a Flex-RL application<div><p>Hi Tim,</p>
<p>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.</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.