Loading ...
Sorry, an error occurred while loading the content.
 

Re: Isolate JavaScript to disk-files: follow-up...

Expand Messages
  • Shekar C. Reddy
    By the way, I ve successfully isolated JavaScript to disk-files on another tool I use that generates JavaScript but did not have any support to isolate the
    Message 1 of 11 , Mar 29, 2007
      By the way, I've successfully isolated JavaScript to disk-files on
      another tool I use that generates JavaScript but did not have any
      support to isolate the code to disk-files other than the ability to
      include the code inside the HTML page. While isolating JS to disk-
      files, I used caching, basically - I would check for the existence
      of all the folders in the specified path if they don't exist, I
      create them in a:

      loop
      clearstatcache();
      if ( ! file_exists( $dir ))
      {
      @mkdir( $dir, 0700, true );
      @chmod( $dir, 0700 );
      }
      endloop

      on each created folder inside the loop. Once the folders are in
      place, I generate the JavaScript (custom-generated by me to return
      it as a string):


      clearstatcache();
      if ( ! file_exists( $fileName ) || ( filemtime( $fileName ) +
      $lifeTime ) < time())
      loop
      // Go ahead and write to the disk-file...
      endloop

      However, the code for writing to the disk-file is a bit complicated
      which I borrowed from Zend_Cache_Backend_File. It includes calls to
      fopen/flock/fwrite/flock/fclose/touch with mkdir/chmod for any
      failures. Thought this might save you some time on not reinventing
      the wheel or testing the code.

      Please see my FOLLOW-UP message on "caching" below...





      --- In forms-dev@yahoogroups.com, "Shekar C. Reddy" <zendfw@...>
      wrote:
      >
      > Manuel,
      >
      > Thanks much for considering this exciting feature implementation!
      I
      > hope you would address any derived extensions of the form_class
      > (descendants) by the developer while implementing it.
      >
      > Could we discuss a little bit more on the caching mechanism? I did
      > not mean the developer would end up using outdated JavaScript
      files
      > by using caching. As you are aware, caching is "automatic" and
      > powerful which is used by several major frameworks and classes
      such
      > as Smarty.
      >
      > During development, the developer sets the life-time to a very
      high
      > frequency such as every one hour. Any life-time greater than 0
      would
      > mean to validate file-existence, compare file-time with life-time
      > for stale files and re/generate file if expired/missing. The
      > developer can also blow off the JavaScript files anytime to
      > regenerate them before their expiry or use configuration logic to
      > reset the life-time to refresh the files. Typically, its much
      easier
      > to manipulate configuration/files on dev environment.
      >
      > Whereas on production, life-time is usually set to 0 which means
      > cache files never expire. The class would only validate for the
      > existence of the JavaScript file and would always generate if it
      is
      > missing but would never validate the file-times. When we copy
      > stabilized code from development into production or update the
      forms
      > class, all we need to do is blow off the related JavaScript files
      or
      > run a script to do it so they get generated on next page-load by
      > default. The overhead is too low with this approach. Even if we
      set
      > the life-time to 24 hours (just in case), they get generated only
      > once in a day.
      >
      > class form_class
      > {
      > function form_class( $javaScriptFile, $lifeTime = 0 );
      > }
      >
      > $form = new Form_Class( $javaScriptFile, $lifeTime );
      >
      >
      > Do you think it is ideal to offer caching as an additional
      feature -
      > when you are on it?
      >
      > Further, since this is a major change, you may like to increment
      the
      > major version of the form_class.
      >
      >
      >
      >
      >
      > --- In forms-dev@yahoogroups.com, Manuel Lemos <mlemos@> wrote:
      > >
      > > Hello,
      > >
      > > on 03/22/2007 04:52 PM Shekar C. Reddy said the following:
      > > > Manuel,
      > > >
      > > > It would be great if the forms class can manage the process of
      > > > caching the JavaScript files. You quoted several issues and
      > offered
      > > > self-explanatory solutions to all of those except this one:
      > > >
      > > > "A different problem may occur to people using safe mode. In
      > that
      > > > case it may not be possible to creata the Javascript files due
      > to
      > > > safe mode permission restrictions. In that case should the
      forms
      > > > class Output function fail altogether and do not generate any
      > forms,
      > > > or silently generate the Javascript as part of the forms
      output
      > as
      > > > it is done today?"
      > > >
      > > > Yes, in case of file-write errors, the class may silently
      > generate
      > > > the JavaScript as part of the forms output as it is done
      today.
      > This
      > > > would be a 'generic' course of action to take.
      > >
      > > Yes, it sees the best solution. The class also will issue an
      error
      > that
      > > will be trapped by the debug callback function.
      > >
      > >
      > > > As for the 3rd-party plugins, we may have to offer some hints
      on
      > how
      > > > to resolve/update the information in the documentation or
      cover
      > it
      > > > in the video tutorials.
      > >
      > > I think it is better to fail the form output generation
      altogether
      > with
      > > an explicit error message if any plug-ins do not implement a
      > function
      > > that informs its files dependencies, when Javascript file
      > generation is
      > > requested.
      > >
      > >
      > > > We need to be able to specify the JavaScript file to be used
      on
      > >
      > > I think that can be done using a simple forms class variable.
      > >
      > >
      > > > a "per-page" basis. We also need some sort of caching
      mechanism
      > with
      > > > a 'Life-Time' to regenerate/over-write the specified
      JavaScript
      > file
      > > > on expiration of the specified life-time, over-riding all
      other
      > > > parameters even if they are valid. This way, any changes to
      > content
      > > > such as validation error messages, source updates or settings
      > would
      > > > be taken care of by itself, periodically.
      > >
      > > I do not see the need for cache file regeneration if the
      > application can
      > > inform all the script files that affect the form content.
      > >
      > > Making the generated Javascript file expire periodically only
      makes
      > > things more confusing and innefficient. That way the developer
      may
      > > change the application files and class still use outdated
      > Javascript
      > > file. Expiring the Javascript file periodically, also makes the
      > > Javascript file be regenerated often when it may not be
      necessary.
      > >
      > >
      > > > That said, I guess you are good to go ahead and implement it
      as
      > a
      > > > new feature.
      > > >
      > > > Thank you very much for your interest, time and efforts on
      this
      > > > feature. We appreciae it! It would really be a great addition
      > and a
      > > > useful feature for the class that would not only reduce the
      HTML
      > > > file size and page generation time but also improve the
      > performance of the application as a whole.
      > >
      > > I will put it on my to do list for when I have more time to
      > implement it.
      > >
      > >
      > > --
      > >
      > > Regards,
      > > Manuel Lemos
      > >
      > > Metastorage - Data object relational mapping layer generator
      > > http://www.metastorage.net/
      > >
      > > PHP Classes - Free ready to use OOP components written in PHP
      > > http://www.phpclasses.org/
      > >
      >
    • Manuel Lemos
      Hello, ... I do not see the need for the life time cache check. I may just add an option to generate the Javascript only if it does not exist and it would not
      Message 2 of 11 , Apr 5 1:48 PM
        Hello,

        on 03/26/2007 10:41 PM Shekar C. Reddy said the following:
        > During development, the developer sets the life-time to a very high
        > frequency such as every one hour. Any life-time greater than 0 would
        > mean to validate file-existence, compare file-time with life-time
        > for stale files and re/generate file if expired/missing. The
        > developer can also blow off the JavaScript files anytime to
        > regenerate them before their expiry or use configuration logic to
        > reset the life-time to refresh the files. Typically, its much easier
        > to manipulate configuration/files on dev environment.
        >
        > Whereas on production, life-time is usually set to 0 which means
        > cache files never expire. The class would only validate for the
        > existence of the JavaScript file and would always generate if it is
        > missing but would never validate the file-times. When we copy
        > stabilized code from development into production or update the forms
        > class, all we need to do is blow off the related JavaScript files or
        > run a script to do it so they get generated on next page-load by
        > default. The overhead is too low with this approach. Even if we set
        > the life-time to 24 hours (just in case), they get generated only
        > once in a day.
        >
        > class form_class
        > {
        > function form_class( $javaScriptFile, $lifeTime = 0 );
        > }
        >
        > $form = new Form_Class( $javaScriptFile, $lifeTime );
        >
        >
        > Do you think it is ideal to offer caching as an additional feature -
        > when you are on it?

        I do not see the need for the life time cache check. I may just add an
        option to generate the Javascript only if it does not exist and it would
        not check for dependency files.


        > Further, since this is a major change, you may like to increment the
        > major version of the form_class.

        Since I do not intend to implement backwards incompatible changes, there
        is no point in changing the class major version. Actually the version
        number that you see is automatically generated by CVS.

        --

        Regards,
        Manuel Lemos

        Metastorage - Data object relational mapping layer generator
        http://www.metastorage.net/

        PHP Classes - Free ready to use OOP components written in PHP
        http://www.phpclasses.org/
      • Manuel Lemos
        Hello, ... There is no need for using another generic caching component to implement caching mechanism. I have developed a mature generic caching class a long
        Message 3 of 11 , Apr 5 1:53 PM
          Hello,

          on 03/29/2007 02:12 PM Shekar C. Reddy said the following:
          > By the way, I've successfully isolated JavaScript to disk-files on
          > another tool I use that generates JavaScript but did not have any
          > support to isolate the code to disk-files other than the ability to
          > include the code inside the HTML page. While isolating JS to disk-
          > files, I used caching, basically - I would check for the existence
          > of all the folders in the specified path if they don't exist, I
          > create them in a:
          >
          > loop
          > clearstatcache();
          > if ( ! file_exists( $dir ))
          > {
          > @mkdir( $dir, 0700, true );
          > @chmod( $dir, 0700 );
          > }
          > endloop
          >
          > on each created folder inside the loop. Once the folders are in
          > place, I generate the JavaScript (custom-generated by me to return
          > it as a string):
          >
          >
          > clearstatcache();
          > if ( ! file_exists( $fileName ) || ( filemtime( $fileName ) +
          > $lifeTime ) < time())
          > loop
          > // Go ahead and write to the disk-file...
          > endloop
          >
          > However, the code for writing to the disk-file is a bit complicated
          > which I borrowed from Zend_Cache_Backend_File. It includes calls to
          > fopen/flock/fwrite/flock/fclose/touch with mkdir/chmod for any
          > failures. Thought this might save you some time on not reinventing
          > the wheel or testing the code.
          >
          > Please see my FOLLOW-UP message on "caching" below...

          There is no need for using another generic caching component to
          implement caching mechanism.

          I have developed a mature generic caching class a long time ago:

          http://www.phpclasses.org/filecache

          Anyway, that is just for separate cache stored. In the case of the forms
          class Javascript, it will not be stored separately. The class will
          generate a Javascript file that your scripts will include directly using
          <script src=...> tags.

          --

          Regards,
          Manuel Lemos

          Metastorage - Data object relational mapping layer generator
          http://www.metastorage.net/

          PHP Classes - Free ready to use OOP components written in PHP
          http://www.phpclasses.org/
        Your message has been successfully submitted and would be delivered to recipients shortly.