Re: [flexcoders] Re: Architecting a large, modular Flex application

[Anatole Tartakovsky]

Paul, 
>>
Certainly. The caching issue I'm referring to is when a new RSL SWF is published and pushed to a server the end user may not immediately see the new SWF. Or, more accurately the users browser may load the old 
version of the SWF from the browser cache and not the more recent from the server.<<
   I think browser cache should recognise new RSL. You can use any HTTP tracer to verify that every application startup causes appropriate HTTP request and get 304 and 200 codes. I am not aware of any problems so far.
>>
Certainly. The caching issue I'm referring to is when a new RSL SWF is published and pushed to a server the end user may not immediately see the new SWF. Or, more accurately the users browser may load the old 
version of the SWF from the browser cache and not the more recent from the server.<<
I would like to confirm that there is a problem first. Also, please refer to initialize method for Preloader object - by subclassing it you can mangle URLs  any way you like.
 
Sincerely,
Anatole
 
On 9/27/06, Paul Spitzer <[EMAIL PROTECTED]> wrote:





Anatole Tartakovsky wrote:> Paul,> Could you please clarify your question - it seems that there are > number of issues that are mixed up here. First, there is no issue of > RSL caching in the browser unless you specifically enable some 
> expiration scheme.Certainly. The caching issue I'm referring to is when a new RSL SWF is published and pushed to a server the end user may not immediately see the new SWF. Or, more accurately the users browser may load the old 
version of the SWF from the browser cache and not the more recent from the server.Does that make sense?> > I have seen people loading multiple applications side by side - using 
> the same RSLs - that is essentially the question if you want to > isolate your runtime libraries in case of versioning in the future - > that would essentially hurt performance> > Finally, there is an issue of loading RSLs in the root appDomain - 
> essentially you do not have a chance to do reloading of the classes > till the application startup. Also, there is obvious problem with > versioning.> > Seems we are done with the client - now the question is how to build 
> RSLs so it is the smallest, most recent, and up to date one.> > That's were it breaks in the beginning. Essentially, if you are using > dynamic instantiation of any class in the RSL, the main application 
> would not know whic objects to initialize/which dependent classes to > include. One solution we are using is to build self initializing > modules and use them instead of RSLs that would of been extracted out 
> of SWCs by the build process.I was just discussing a similar option with a coworker here. The idea is that instead of using RSLs we'd simply build libs of code (packaged in a SWF) and write our own loading scheme. Going this route, while more 
work, would also allow us to control caching by appending a version to the URL when loading.... corelib.swf?v=1.Thanks for taking the time to reply.> > HTH,> Anatole Tartakovsky
> > >>> > On 9/26/06, *Paul Spitzer* <[EMAIL PROTECTED] <mailto:
[EMAIL PROTECTED]>> 
> wrote:>> >some concerns about potential RSL caching and how to overcome that> >(I think it can be easily overcome with a proper rollout strategy)
>> I'm curious to hear what your plan is to deal with the caching of> RSL(s). Or how others deal with it. Any suggestions?>> derrickgrigg wrote:> > I actually was concerned about the HOW and the WHY. I wanted to find
> > out why doing it that way was a good solution or why someone else's> > solution would be better or more viable. And if the proposed> > solution was good, was how I intended to implement that solution the
> > right way.> >> > I completely agree that having Abstract and Interface classes just> > to accomplish modularity is basically creating a code management> > problem. The only reason it was seriously being considered was to
> > allow the development of seperate module swfs, that need to use the> > same base classes (ie models, command and value objects), without> > having to worry about code duplication and errors/conflicts when
> > module swf are being loaded in the main shell application.> >> > I've had problems in the past with Flash and RSLs plus I still have> > some concerns about potential RSL caching and how to overcome that
> > (I think it can be easily overcome with a proper rollout strategy),> > so I was a little hestitant to pursue that idea. However, from your> > post and Erik's (plus my own nagging suspicion), I think having the
> > base code in an external SWC and using that as an RSL is the right> > was to go.> >> > Derrick> >> >> >> >> >>>
> 
 

__._,_.___





--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com








   



    


  
  
    SPONSORED LINKS
  
          
                  
            
        Software development tool
      
                      
        Software development
      
                      
        Software development services
      
              
                        
            
        Home design software
      
                      
        Software development company
      
                    
           
  






      
      Your email settings: Individual Email|Traditional 
      Change settings via the Web (Yahoo! ID required) 
      Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured 
           
        Visit Your Group 
       |
      
        Yahoo! Groups Terms of Use
       |
      
       Unsubscribe 
       
 
    
  




__,_._,___