What about sharing components. For instance, we have a project just completed with several as components. We want to use some of those same AS components, but don't want to copy them to our new projects directory since when changes are made in the AS components for the old project we need them to show up in our new project. So we want to point to the same library or folder for both applications.
--- In flexcoders@yahoogroups.com, "Ryan Graham" <[EMAIL PROTECTED]> wrote: > > > If you are using Subclipse in Flex Builder, it does a pretty good job of > automatically leaving out said files. Here are some for example in a > standard Flex Project folder: > > * > .settings folder > * > .actionScriptProperties > * > .flexProperties > * > .project > > HTH, > Ryan > > ________________________________ > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of flexaustin > Sent: Tuesday, September 16, 2008 8:25 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Re: Flex Project Struture > > > > Thanks Ryan. You mentioned Flex Builders specific files...what would > those be? > > --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > , "Ryan Graham" <Ryan.Graham@> wrote: > > > > > > If you're using a framework like Cairngorm or Cairngorm with > Extensions, > > there are already recommended project structures. If you aren't using > an > > existing framework, then everyone will have to be on the same page > with > > the dev methodologies and conventions that you all have agreed upon as > a > > team. There should be no issues using a flex project with your given > > setup, but it may be worth noting that you may want to stay away from > > including any flex builder specific files in the SVN, as everyone has > > their own dev environment setup the way they like it as far as > > workspaces and such are concerned, and that leaves the project open to > > developers who may be using the sdk and command line to compile by > > reducing flex builder dependencies. > > > > Aside from that, I'd say it's good to keep all your view components > and > > sealed classes for your model together (minimally), and any external > or > > embedded assets in a separate folder defined as an additional source > > folder so they will still get copied to the bin when building. All > this > > could of course be accomplished through ANT though if you want to go > > that route. Brief example: > > > > etc > > --assets > > --config > > src > > --components > > --view > > --model > > ... > > > > The possibilities are really endless, but as long as everyone agrees > on > > the project structure, you shouldn't have any problems. This is where > > existing frameworks can help take the headache out of things -- by > > providing a known structure up front. > > > > HTH, > > Ryan > > > > ________________________________ > > > > From: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > ] On > > Behalf Of flexaustin > > Sent: Tuesday, September 16, 2008 4:11 PM > > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > > Subject: [flexcoders] Flex Project Struture > > > > > > > > Can anyone recommend a project structure? Maybe a tut or blog post on > > the topic? We have several components (as and mxml) that we want to > > use throughout several projects and by several team members, but not > > sure the best way to structure the files and package them up. How do > > we all share the files? Is a Flex Project the best way? We are using > > subversion + Flex 3 + Ant. > > > > Would like to build an Ant task that fetches all the files and builds > > the structure once we establish what that structure should be. > > > > Thanks in advance. > > > > > > > > > > > > > > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > > > > > > > > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. >
