You can't. Some are not skins, but icons or assets. I don't mean the icon property, I mean designed to have like an icon. It's easy to just use an image tag. That is MXML/ActionScript, not CSS.
However, you should make an effort to make 90% of your assets in CSS, yes. You're AssetImporter sounds great, and we wanted something like this in our current app, but she's far to big to refactor to something like this. Meaning, I'd love to do it, but the client won't pay for the time it'll take. ----- Original Message ----- From: "Peter Hall" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, July 16, 2006 11:47 AM Subject: Re: [flexcomponents] Re: Component Packaging, Delivery, and Installation 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 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/
