I dont use code-behind so someone else is probably best suited to reply to you. But from what I know, you have to re-declare all your components in the write-behind class so I consider that overhead and I dont think there is a way around it. Dimitrios Gianninas RIA Developer Optimal Payments Inc.
________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Private Romeo Sent: Thursday, February 08, 2007 4:22 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Resources to Flex Application Architecture articles? Dimitrios, Thanks for your response. I'm coming from a C# and Java background, primarily larger apps. So naturally I would split *everything* into classes and util objects. However I wonder if in terms of scope I can do anything I could do as opposed to doing it inline? I don't want to end up having to code lots of overhead events etc. just because I encapsulated stuff into classes. Basic question: If I have some AS code inline (in the main MXML application file) and want to "migrate" it into a code-behind .as file, how do I best do that without having to add overhead stuff? Best regards Ralf -----Original Message----- From: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ] On Behalf Of Dimitrios Gianninas Sent: Donnerstag, 8. Februar 2007 01:25 To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> Subject: RE: [flexcoders] Resources to Flex Application Architecture articles? I dont know of any links of hand and I am about to split, so I'll provide some quick feedback: - AS inline or write-behind? Depends really on what you like, either way will work. I use inline mostly but I have started to logically put AS code into helper classes and use things that way. Allows me to FlexUnit test them which is important. - how big should primary MXML be? I always make it contain only the higher level components of the app itself. Everything in my apps is broken down into small manageable components. Thus fixing any bugs or making any changes is easy to do. That doesn't come right away, it took me a while but man is it useful and easy. Dimitrios Gianninas Optimal Payments Inc. -----Original Message----- From: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> on behalf of Private Romeo Sent: Wed 2/7/2007 9:38 AM To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> Subject: [flexcoders] Resources to Flex Application Architecture articles? Hi everybody, we are looking for (online) resources related to how to best structure (larger) Flex applications. Most of the great training and tutorial material available tends to focus on how to construct more complex controls, how to implement special effects or how to solve DataGrid/Binding related issues, however, what we are seeking is material as to potential best practices about how to structure an Flex app best. Should AS code be used inline primarily? Or is a code-behind pattern a better choice? Should we ultimately keep the primary MXML application file small and work with complex custom controls, or should we keep custom controls usage low? Are there any good technical articles out there? Any links? Any hints? Thanks for your support. -- WARNING ------- This electronic message and its attachments may contain confidential, proprietary or legally privileged information, which is solely for the use of the intended recipient. No privilege or other rights are waived by any unintended transmission or unauthorized retransmission of this message. If you are not the intended recipient of this message, or if you have received it in error, you should immediately stop reading this message and delete it and all attachments from your system. The reading, distribution, copying or other use of this message or its attachments by unintended recipients is unauthorized and may be unlawful. If you have received this e-mail in error, please notify the sender. AVIS IMPORTANT -------------- Ce message électronique et ses pièces jointes peuvent contenir des renseignements confidentiels, exclusifs ou légalement privilégiés destinés au seul usage du destinataire visé. L'expéditeur original ne renonce à aucun privilège ou à aucun autre droit si le présent message a été transmis involontairement ou s'il est retransmis sans son autorisation. Si vous n'êtes pas le destinataire visé du présent message ou si vous l'avez reçu par erreur, veuillez cesser immédiatement de le lire et le supprimer, ainsi que toutes ses pièces jointes, de votre système. La lecture, la distribution, la copie ou tout autre usage du présent message ou de ses pièces jointes par des personnes autres que le destinataire visé ne sont pas autorisés et pourraient être illégaux. Si vous avez reçu ce courrier électronique par erreur, veuillez en aviser l'expéditeur.
