For a component that you intend to distribute, shouldn't all visual assets be included via CSS? I haven't worked like this yet, but I would think it would be quite tidy to put all your assets in a directory under your styles directory, so they are easily accessible from CSS.
Or did I miss something. We have a similar approach for our Flex1.5 applications. Where images are imported in code, we have just one AssetImporter class, which has a static property for each asset, and can be referenced anywhere in the app. The assets can the be located relative to the AssetImporter. I don't see any design problems with this for an application. Components are different though, since you need to be able to override any of these assets. Peter. On 7/16/06, JesterXL <[EMAIL PROTECTED]> wrote: > That's even worse. I use: > > submit_pb at home for Button's, but at work use buttonSubmit. The _mc is > left over from the Flash days, so I use _abbreviatedtype for everything. > > It's taking me 4 months to get my team liking the new way of indentation, > vs. the old way: > > http://pastebin.de/9130 > > vs. > > http://pastebin.de/9131 > > At work, I need to align my variable lists. At home I don't care. > > public var > > So, I code differently at home than I do at work. > > http://pastebin.de/9132 > > vs. > > http://pastebin.de/9135 > > I think the package structures that Chafic & Peter have mentioned are cool, > both with bare minimums. One thing I've never figured out, though, is image > assets. Now that we don't have a library, my projects tend to have a > crapload of images and Flash files that are used and I'm not sure where to > put them. At home, I just shove images & SWF's into the images folder. I > put the FLA's into the flash folder. > > At work, we put an "assets" folder in the package where the class needs it. > I really like this because it is insanely easier with paths and refactoring, > but you tend to end up with duplicated images on bigger projects. > > That's my take. > > ----- Original Message ----- > From: "bjorn.schultheiss" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Sunday, July 16, 2006 6:47 AM > Subject: [flexcomponents] Re: Component Packaging, Delivery, and > Installation > > > I think this thread has gone down the path of using a relaxed attitude. > > Packaging, Delivery, and Installation. > > Delivery and installation for clients has been discussed thoroughly. > I think the more deligence taken towards delivery makes an good > impression on the client. > > Not much has been discussed in terms of management of components > within an internal organisation. > Component development helps provide a much more modular approach to > GUI dev departments. The flex markup language provides an easier way > to make use of flash components. > > In terms of packaging a library of components for internal use, i > think developers can benefit from the same perspective as delivering > components to clients. > > Are there any particular naming conventions, package structure that > would promote common practice. So far i have been picking up most of > my standards, ('naming', 'commenting', 'coding') from the flex 2 > framework. > > > Regards, > Bjorn > > --- In [email protected], "adobeted" <[EMAIL PROTECTED]> wrote: > > > > We have a unique opportunity to define a standard for component > > packaging, delivery, and installation. We need to make sure that end > > users have a reliable, consistant way to get a component installed and > > working. I would like to define this standard here as a group. > > > > Here are some thoughts: > > > > 1. KISS - This needs to be simple and consistant. End users should not > > struggle to get a component installed and working. If we all ship > > components in the same structure/pattern, it will minimize confusion. > > > > 2. Consistant directory structure across components. When a component > > is received it should be easy to find documentation, installation > > instructions, license, and source if included. > > > > Filesystem or ZIP Archive like so: > > > > /ComponentName/ > > /ComponentName/source/ > > /ComponentName/swc/ > > /ComponentName/examples/ > > /ComponentName/docs/ > > /ComponentName/install.html > > /ComponentName/documentation.html > > /ComponentName/license.html > > > > 3. Consistant instructions in install.html, documentation.html, > > license.html and consistant professional generated documentation. > > > > 4. Code standards for component source. Define simple guidelines for > > formatting source code. Indentation and comments to improve > > readability of code within source. > > > > ------------------ > > > > Thoughts, comments, additions? > > > > Ted :) > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > Yahoo! Groups Links > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/nhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcomponents/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
