Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Run time XML to define new MXML and complied SWF? No way man, I simplify agree with Ely, what´s the real impact of such request for the customers, Remeber that Flex is for Best User Experience. Wanna some dynamic content to be loaded or created into other componentes or application, Use for SURE the repeter or UIComponent set for do that. Or even better, Flex XML classes and XMLList package has a HUGE possibilities to the developers do such thing. Reading xml to define new Interface for SURE isn´t what companies looks like, dynamic creation policy it´s must better then that. Think a little bit and you will see that´s completly unecessery at this time. Maybe in the future but not now. - Best Igor Costa On 5/18/07, John Robinson [EMAIL PROTECTED] wrote: For the archives, compile times can be greatly reduced using fcsh, though I'm not sure how you'd go about using it in a server-side environment. http://labs.adobe.com/wiki/index.php/Flex_Compiler_Shell John On May 17, 2007, at 8:30 PM, Paul J DeCoursey wrote: You can easily integrate a compile on demand system using the Flex SDK and Tomcat. The problem is the compilers are not very fast. I'm guessing that the Apache/IIS module does some caching so that compiles run faster because they don't have to reload large libraries each time. Once the compiler is opened up a little more you should be able to implement this kind of thing. Austin Kottke wrote: Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. – There are a number of features of MXML that simply can't be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate…removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I'm curious…how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, *Daniel Freiman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
On Friday 18 May 2007, Austin Kottke wrote: more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) I think you'd be a lot better off returning a domain-specific description of what the GUI should do and look like, and have the client reconfigure itself (removeChild(), addChild(new Button()) etc. etc. scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. There is already a web-tier compiler. -- Tom Chiverton Helping to competently incentivize low-risk environments on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * 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/
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. -- There are a number of features of MXML that simply can't be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate...removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I'm curious...how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, *Daniel Freiman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime ? So my question, has anyone ever done this and how did they do it? I'm not talking about using the modules package to load in precompiled swfs. But loading in mxml and having it run after being loaded. Best, Austin -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail
RE: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
I'm not to keen on this personally for security reasons. My company just got some security training recently and I saw the effects of XSS (cross side scripting attacks). One plus for Flex is that it is not affected by this, however implementing runtime MXML execution would make it prone to similar type of attacks. So weighing runtime MXML vs security, I would take security. Dimitrios Gianninas Developer Optimal Payments Inc. -Original Message- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Austin Kottke Sent: Thursday, May 17, 2007 7:23 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. – There are a number of features of MXML that simply can’t be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate…removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I’m curious…how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, *Daniel Freiman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Yea, I get it. It sounds really cool though -- I'd love to be able to see dynamically created MXML and not have it to be server side (Apache IIS mod). This would make flex's value a lot higher. I suppose that there is some class in the flex framework which does this however, converts MXML to objects and then it's ready. Has anyone ever used this or is it internal? Best, Austin Daniel Freiman wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime ? So my question, has anyone ever done this and how did they do it? I'm not talking about using the modules package to load in precompiled swfs. But loading in mxml and having it run after being loaded. Best, Austin -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links (Yahoo! ID required) mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
RE: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Would this be what you are looking for? http://labs.adobe.com/wiki/index.php/Flex_Module_for_Apache_and_IIS Giles From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Austin Kottke Sent: 17 May 2007 21:09 To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. - There are a number of features of MXML that simply can't be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate...removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I'm curious...how many people would find runtime MXML to be important to them? Ely. From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCune Sent: Thursday, May 17, 2007 12:47 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, Daniel Freiman [EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, Austin Kottke [EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Not exactly as it only works for Apache and IIS - no support for other servers such as tomcat, resin, etc. It's definitely in the ball park, but needs to be supported on other servers. If that could be worked out then runtime mxml wouldn't be a problem (depending on compile speed). The main thing I was thinking of is adding support similar to JSP/Velocity style flex apps so you can add in layout code without having to have someone know everything about programming (mainly layout code) so designer types can layout their canvas's, hboxes without having to know how to compile with the SDK. Best, Austin Giles Taylor wrote: Would this be what you are looking for? http://labs.adobe.com/wiki/index.php/Flex_Module_for_Apache_and_IIS http://labs.adobe.com/wiki/index.php/Flex_Module_for_Apache_and_IIS Giles *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Austin Kottke *Sent:* 17 May 2007 21:09 *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. – There are a number of features of MXML that simply can’t be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate…removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I’m curious…how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * 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/
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
For the archives, compile times can be greatly reduced using fcsh, though I'm not sure how you'd go about using it in a server-side environment. http://labs.adobe.com/wiki/index.php/Flex_Compiler_Shell John On May 17, 2007, at 8:30 PM, Paul J DeCoursey wrote: You can easily integrate a compile on demand system using the Flex SDK and Tomcat. The problem is the compilers are not very fast. I'm guessing that the Apache/IIS module does some caching so that compiles run faster because they don't have to reload large libraries each time. Once the compiler is opened up a little more you should be able to implement this kind of thing. Austin Kottke wrote: Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. – There are a number of features of MXML that simply can’t be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate…removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I’m curious…how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, *Daniel Freiman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather
[flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let’s consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime ? So my question, has anyone ever done this and how did they do it? I'm not talking about using the modules package to load in precompiled swfs. But loading in mxml and having it run after being loaded. Best, Austin -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * 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/
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, Austin Kottke [EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime ? So my question, has anyone ever done this and how did they do it? I'm not talking about using the modules package to load in precompiled swfs. But loading in mxml and having it run after being loaded. Best, Austin -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, Daniel Freiman [EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, Austin Kottke [EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime ? So my question, has anyone ever done this and how did they do it? I'm not talking about using the modules package to load in precompiled swfs. But loading in mxml and having it run after being loaded. Best, Austin -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
RE: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Austin et. al. - There are a number of features of MXML that simply can't be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate...removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I'm curious...how many people would find runtime MXML to be important to them? Ely. From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Doug McCune Sent: Thursday, May 17, 2007 12:47 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, Daniel Freiman [EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, Austin Kottke [EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime ? So my question, has anyone ever done this and how did they do it? I'm not talking about using the modules package to load in precompiled swfs. But loading in mxml and having it run after being loaded. Best, Austin -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links mailto:[EMAIL PROTECTED] image001.jpgimage002.jpg
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. – There are a number of features of MXML that simply can’t be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate…removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I’m curious…how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, *Daniel Freiman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime ? So my question, has anyone ever done this and how did they do it? I'm not talking about using the modules package to load in precompiled swfs. But loading in mxml and having it run after being loaded. Best, Austin -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
You can easily integrate a compile on demand system using the Flex SDK and Tomcat. The problem is the compilers are not very fast. I'm guessing that the Apache/IIS module does some caching so that compiles run faster because they don't have to reload large libraries each time. Once the compiler is opened up a little more you should be able to implement this kind of thing. Austin Kottke wrote: Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. – There are a number of features of MXML that simply can’t be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate…removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I’m curious…how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, *Daniel Freiman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote that was able to read MXML into a way to read XML. As we know, MXML resembles XML rather closely. Heck, MXML is XML ! Yipee, now I can easily read MXML because it is essentially a form of XML. We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects. But what if we could trick Flex2 into dynamically loading MXML at runtime
Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents
Yea - I'm mainly just thinking it would be great to have some dynamic layout code that you could fire off to an html layout guy and he could use MXML for dynamic layout and positioning. This could create some awesome workflows I feel, because it would open up the editing to non-flex designers who know basic layout, HBOX, VBOX, etc. Best, Austin Paul J DeCoursey wrote: You can easily integrate a compile on demand system using the Flex SDK and Tomcat. The problem is the compilers are not very fast. I'm guessing that the Apache/IIS module does some caching so that compiles run faster because they don't have to reload large libraries each time. Once the compiler is opened up a little more you should be able to implement this kind of thing. Austin Kottke wrote: Ely, I find runtime MXML something that would be invaluable. It is something that if implemented could make developing in flex a lot more scaleable and integration with the server end would be a lot more feasible. (As in doing HTTPRequests where serverside MXML could be generated through Velocity/JSP and then given back to the ui) A lot of developers don't know a thing about flex, but can learn basic MXML for layout or simple scripting and implement basic server side operations. And if these are kept just as mxml it makes updates in the future easier. We can then just tell someone (edit the MXML) and you're done, instead of download the flex sdk, set your ant build, yada ya -- some aren't programmers, but MXML is very easy to learn. It's a lot more confrontable for a designer/layout guy to tackle. Anyway, runtime MXML would be something that would majorly increase scalability and integration with servers - similar to the Apache IIS mod for JSP, etc - the only problem is that it's just for Apache or IIS. Some run tomcat, resin, etc. But having it on the client end would eliminate this problem. Best, austin Ely Greenfield wrote: Austin et. al. – There are a number of features of MXML that simply can’t be replicated at runtime. Things like script blocks. Other features would be prohibitively difficult (arbitrary binding expressions, @Embed, mx:Component, among others). You could reduce MXML to a runtime-parsable subset, and I know various people have taken various approaches to this. The more you reduce it, the easier it would be to replicate…removing repeaters, implicit arrays, default properties, etc. would get you down to something that could be implemented in a reasonable amount of time. I’m curious…how many people would find runtime MXML to be important to them? Ely. *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Doug McCune *Sent:* Thursday, May 17, 2007 12:47 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Flex cookbook article: Flex2 XML Reader Can Create UIComponents Yeah, ummm, my advice would be ignore that article. That's one of the effects of having an article submission process that allows anyone to submit anything. I know the cookbook is supposed to be user generated and reviewed, but anyone from Adobe want to exercise a little editorial control? I wouldn't mind the hand of god going in there and selectively removing a little content... sometimes democracy needs a helping hand. On 5/17/07, *Daniel Freiman* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think they're just stating that the mx.modules package exists. The sentence We also know Flex2 knows how to read MXML at runtime because the compiler knows how to convert MXML into GUI Objects doesn't inspire confidence that they know what they're talking about. Since it's possible that they don't know what a compiler does, it's also possible they're just writing and compiling Modules and don't understand that they're doing it. Then again, that wouldn't explain what they're fighting with another company about earlier in the article. They claim what they're talking about is in the docs so I'd either search them or not worry about it. My guess is you'd be searching a long time for something that isn't there. It would be nice if someone could prove my guess wrong though. Dan Freiman nondocs http://nondocs.blogspot.com On 5/17/07, *Austin Kottke* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, There is an intriguing article in the flex cookbook on the adobe site about reading in MXML at runtime and using the XML object to create components at runtime. While I don't totally get how this works as there are no code samples, but very vague actually, but it states: Let's consider, for a moment, how Adobe might have chosen to leverage reuse within the Flex2 programming model. Assuming the Adobe engineers did not want to have to recreate the wheel in terms of how to make Flex2 able to load normal non-GUI XML I would surmise they chose to simply reuse whatever code they wrote
