Spoova php framework for web development.

Loading static files

As of version 2.6+ the Resource class no longer support prefixes on urls to reduce url validation checks. Resource methods such as path() have been removed while methods such as import() and export() have been updated to effect this change. However, the new(), dir() and xurl() methods are not affected by this update. A new class Ress now handles static resource loading by default.

Static files are loaded dynamically into the web page using the Resource class. The primary function of Resource class is to load external static resources like javascript or css files. These files are stored in container groups where they can later be imported into web pages. The following listed processes are handled by the Resource class.

Storing or grouping of urls
Internal url validation
Resolving urls to http protocols
Autoloading of meta tags
Autoloading of live server

Resource class methods

The Resource class provides useful static and non-static helper methods for managing static resources. These helper methods provides assistance in storing local and remote files links into groups, naming file links, merging file links or resource groups and importing stored group as resolved script links into the web page. These methods are listed below:

STATIC METHODS
Res::pull() ^+2.6
Res::name()
Res::callFile()
Res::getFile()
Res::addFile()
Res::new()
Res::path() ^-2.6
Res::bind() ^+2.5
Res::bindTo() ^+2.5
Res::open()
Res::close()
Res::import()
Res::export()

NON-STATIC METHOD
- ->url()
- ->xurl()
- ->urlOpen()
- ->urlClose()

Storing and importing static urls

Static urls are imported from the global resource folder res. Therefore, all local static urls should begin with the res folder name although a different folder name may be accepted. Before a file can be imported, it can be initially stored into the Res storage system. By default, the Resource class stores urls into different containers which are either named or unamed. A named container uses a group name to store static urls. However, if a group name is not defined, then such urls will be stored in an unamed space. There are several methods used for handling resource storage and importation and they are listed below

STATIC METHODS
Res::name()
Res::callFile()
Res::getFile()
Res::addFile()
Res::new()
Res::path()
Res::bind()
Res::bindTo()
Res::open()
Res::close()
Res::import()
Res::export()

NON-STATIC METHOD
- ->url()
- ->xurl()
- ->urlOpen()
- ->urlClose()

#Resource naming

Resource naming or grouping is done by giving static resources their own storage group space which may be declared (named) or undeclared (unnamed). Example is shown below:

  <?php

  Res::name('css');

Naming a resource file is done using the name() method to declare a resource name. The resource name declared is used as a unique storage space name for resource file urls which can later be imported in the web application. In earlier versions, the Res::name() does not support a chainable structure. However, starting from version 2.6.0, the Res::name() returns the object instance of the class, making it possible to chain other methods. The sample below is how to use the name() method as a chain in line 4 in the earlier versions.

  1. Res::name('css');
  2. Res::name('js');
  3. 
  4. Res::new()->name('css')->name('js');

When adding multiple groups, line 1 & 2 will be harder to manage, hence line 4 is mostly recommended because it supports a chainable structure. However, starting from version 2.6.0, the name() method can be easily chained as shown below:

  1. Res::name('css')->name('js');

#Resource Setting

The resource urls can be added through 3 input methods which are Res::callFile() Res::getFile() and Res::addFile(). Although, these methods are mostly used to set urls, they differ in their functions and roles. Examples are displayed below:

Example 1a - callFile

  Res::name('css'); //declare new resource storage group name
  
  Res::callFile('res/css/file1.css'); //add url to css group
  Res::callFile('res/css/file2.css'); //add url to css group
  
  
  Res::name('js');  //declare new resource storage group name
  
  Res::callFile('res/js/file1.js'); //add url to js group
  Res::callFile('res/js/file2.js'); //add url to js group

In example 1 above, two groups were declared. The first group css is where file1.css and file2.css paths will be saved. While the file1.js and file2.js will be saved into js storage group declared just immediately above them. These groups can be imported later using the Res::import() method. Paths stored does not necessarily have to be of the same extension. However, only four files extensions are supported which are html css js and php. The callFile() method does not only add urls but it also returns the generated script of any added url. This is shown below:

Example 1b - callFile

  <?php

  Res::name('css');
  
  $script1 = Res::callFile('res/css/file1.css'); // add valid relative path of css file

  $script2 = Res::callFile('https://www.foobaz.com/some/file1.js'); // add external file link of a javascript file

  var_dump($script1); // <link href="current_domain/res/css/file1.css" rel="stylesheet" />

  var_dump($script2); // <script src="https://www.foobaz.com/some/file1.js"><script/>

The sample above shows that callFile() method will always return the relative script of any supported resource url. This is mostly detected through the file extension. However, it is noteworthy to mention that relative urls as in $script1 above are usually validated before the script is generated or it is being stored. Invalid relative urls of files are never accepted and will return an empty response. This means that for relative urls, the file corresponding to such urls must exist within the specified relative path. Contrary to this, as in the case of $script2, absolute urls starting with http:// or https:// protocols are never validated because they are assumed as external links. The callFile() method is mostly difficult to maintain because it does not support a chainable structure. The equivalent of this method is the url() method which returns the resource class object instance.

Example 1c - callFile: url method

  Res::name('css')

     ->url('res/css/file1.css')  // add resource url to group
     ->url('res/css/file2.css')  // add resource url to group


     ->name('js')

     ->url('res/css/file1.js')   // add resource url to group
     ->url('res/css/file2.js');  // add resource url to group

In the sample above, the url() method supports a chainable structure that makes the code more organized and easier to read.

Example 2 - getFile

  $resolved = Res::getFile('res/css/file2.js')

Just like the callFile() method, the getFile() method also resolves its urls in a similar manner and returns the resolved url. The major difference is that getFile() automatically imports the valid or external url directly to the webpage using the relative script tag.

Example 4 - addFile

  Res::name('group1'); //declare new resource group1
  Res::name('group2'); //declare new resource group2
  
  Res::addFile('group1','res/css/file2.js'); //select group1, add new resource url
  
  Res::addFile('res/css/file3.js'); //still select group1, add new resource url

The addFile() method, is another method that is used to add urls only to an existing resource group. The existing group name to which the url will be added is declared as the first argument while the second argument defines the new url to be added. After the first group declaration, addFile permits the omission of the class name for subsequent chained addFile calls.

#Resource safe storage : opening resources

Resource naming opens a (url) storage space which is expected to be closed. The dangers of not closing resource space is that developers may accidentally save into a different storage space. Also, if there is a previous setting made globally on resources, it may affect subsequent urls which may inherit such settings. Hence, it is a good practice to either close your resources or start naming on a safe mode. The Res::open() is used to open a resource inclusion on safe mode while Res::close() is used to close currently opened resource group or to move back into the unamed storage space.

Example 5a - Resource opening in safe mode

  # Method 1 ----------------------------------------------------
  
  Res::open(); // safe opening

  Res::name('css') // declare new storage space name
  
     ->url('somefile.css'); // add a new resource url to storage space

In the sample above, assuming we have a file that have previously used the Res class to store resource urls before the Res::open() was called, by redeclaring the Res::open() as in the file above, it will ensure that the current file is able to start on a clean slate without affecting the previous resource urls. This ensures a smooth continuity in the new file. The method above is a sample of how a resource file can be started on a safe mode in earlier versions. In version 2.6.0, the Res::open() now returns the object of the resource class. Now we can easily chain other methods as shown below:

Example 5b - Resource opening in safe mode

  # Method 2 ----------------------------------------------------       
  
  Res::open() // safe opening

     ->name('js') // declare new storage space name
      
     ->url('somefile.css'); // add a new resource url to storage space

The sample above is a chainable structure that can be applied only in version 2.6.0. Another relative method is urlOpen() which performs the same function as open() method. The different however, is that urlOpen() is designed to remember the currently selected (or declared) resource storage space name. Hence, it can be applied after Res::name() is called. An example is shown below:

Example 5c - Resource opening in safe mode

  // Method 3 ----------------------------------------------------       
  Res::name('css') //declare a storage space name
  
      ->urlOpen() //open in safe mode, remember storage space name

      ->url('somefile.css'); // add url to storage space name "css"

It is important to note that the methods open() or urlOpen() are mostly used to reset global custom settings made on urls back to their default state without affecting previously stored urls. This in most cases is used to reset a custom parent path back to the default (empty) path set for certain specified url groups.

#Resource safe storage : closing resources

Although, it is a good practice to open resource storage space in safe mode, it is however also a good practice to close resources after declaration. When a list of resource declaration is properly closed, it is not required to open resources on a safe mode except that it is a good practice to do so. The resource close() method is used to close declared resources or to entirely clear out all previously stored urls. The example below is a good illustration of how the close method helps to close resources.

Example 6 - Resource closing in safe mode

  # Resource-File1.php ----------------------------------------------------
  
  <?php 

  Res::name('css') // declare new storage space name
  
     ->url('somefile1.css') // add a resource url to new storage space
     ->url('somefile2.css') // add a resource url to new storage space

     ->name('js') // declare new storage space name

     ->url('somefile1.js')  // add a resource url to new storage space
     ->url('somefile2.js')  // add a resource url to new storage space

     ->close();  // exit once from named into unamed storage space

In the "Resource-File1.php" sample above, each url is stored into their own relative group space. After all resource urls are declared, the close() method is used to exit from the named space. In resource naming, there are two types of storage spaces which are unamed space and named space. The unamed space is the top level space where urls can be stored without any group name. This space is the default space where urls are saved if they are not assigned to any group name whatsoever. However, any url stored under group storage space is assumed to be stored under the named space regardless of the group name assigned to such resource url. By calling the Res::name() we simply shift into a named storage space and we can only exit back into the default unamed space using the Res::close() or Res::open() method. In the sample above, the close() method is used to exit safely back into the default unamed storage space.

#Resource closing : dangers

The opening of resources on safe mode is much preferable to closing resources due to the extended functionality of the Res::close() method. Aside from, exiting into a named storage space, the Res::close() can also be used to clear previously stored urls. The behaviour of the close() method is that once it is called in an unamed space, it will assume that all previously stored urls are expected to be cleared. Due to this nature, developers may mistakenly clear stored urls which may lead to resources not being imported. This event at most times do occur when the Res::close() method is called twice. An example is shown below:

Resource closing dangers

  <?php 

  Res::name('css') // declare new storage space name
  
     ->url('somefile1.css') // add a resource url to new storage space
     ->url('somefile2.css') // add a resource url to new storage space

     ->name('js') // declare new storage space name

     ->url('somefile1.js')  // add a resource url to new storage space
     ->url('somefile2.js')  // add a resource url to new storage space

     ->close()  // named space exits into unamed storage space

     ->close(); // unamed space clears all previous urls and groups, starting afresh

In the sample above, the first close() method called will exit the previous named space into an unamed space. However, in the second close() method, since we are no longer within a named storage space, the second close() will clear all previous declarations and start afresh on a clean slate. This behaviour is mostly the reason why it is preferable to use the Res::open() instead. In a situation where we need to start afresh from a new file, the Res::open() is capable of achieving the same result when an argument of true is supplied as shown below:

Resource opening, start afresh in safe mode

  <?php

  Res::open(true) // clears all previous urls and groups, starting afresh 

     ->name('js') // declare new storage space name
      
     ->url('somefile.css'); // add a new resource url to storage space

If for any reason, the close() method is needed to clear previous urls, it may be more reasonable to indicate that the close() method was indeed used to clear all urls. Rather than call the close() method twice, we can easily supply a true argument similarly to the Res::open() method.

#Resource url parent directory

The Resource class supports that a base or root url parent path can be set for static files. Hence, all subsequent urls will derive their parent url from the base url. Although the new() method is used to return an instance of the Resource class, its major function is to set a parent path that subsequent urls can inherit from. The new() method accepts a default url base as shown in the example below:

  <?php 

  Res::new('res/assets/') //set parent path
  
     ->name('file1')
     ->url('css/file1.css') // use parent path
     ->url('js/file1.js') // use parent path
     
     ->name('file2')
     ->url('res/main/css/file2.css') // use parent path
     ->url('res/main/js/file2.js') // use parent path
     
     ->close();

#Resource url parent directory overide

In certain situations where a parent directory has been previously defined, we may desire to overide the parent path for some certain resources within a specified resource group or resource storage space. The resource class makes it possible to do a soft overiding for certain specified resources without completing updating the parent path. In this case, only the resources whose path are different will be relaxed from the default parent path defined. The xurl() method makes this relaxation possible. An example is shown below:

  <?php 

  Res::new('res/assets/') //set custom parent path
  
     ->name('file1')
     ->url('css/file1.css') // use custom parent path
     ->xurl('res/main/js/file1.js') // ignore custom parent path (overide)
     ->url('css/file2.css') // use custom parent path
     
     ->name('file2')
     ->url('res/main/css/file2.css') // use custom parent path
     ->url('res/main/js/file2.js') // use custom parent path
     
     ->new('res/main') // new custom parent path

     ->name('file3')
     ->url('res/main/css/file3.css') // use new custom parent path

     ->close();

The example above reveals that once a base url is set, the only way to overide it is by using the xurl() method. However, the full file path must be included into the xurl() method. Every other url() declared will derive their base url from their parent new() method just as shown above. If we need to change the parent path completely, we can use the new() method to completely change the custom path.

#Resource directory switch 2.6

The Resource::path() function enables the mapping of a parent directory to all local urls supplied when working with a parent and child directory. If static files (relative) urls are stored within the parent directory, a child directory may have difficulty in importing the file except it uses the parent directory pointer ../ to pull the files. The Resource::path() can be useful to declare in the child file that it needs to go to an upper directory. This must however be declared before importing the files just as below.

  Res::path('../');

  Res::import();

In the example above, when importing, resource will append the directory pointer to only relative paths while the absolute urls will not be affected.

#Resource Extension Tags

There are cases in which certain urls may not reveal their file extensions. This makes it difficult for Resource class to properly resolve such urls to their respective script link. In such cases, the file extension should be supplied manually to help resource class to resolve such urls. An example is shown below:

  <?php 

  Res::name('scripts')
  
     ->url('http://site.com/js-file:::js')
     ->url('http://site.com/css-file:::css')

In example above, the urls supplied has no recognizable extension name. However, if we know the type of file it is, we can tell the resource class to resolve the url with its respective script tag. This is done by adding three colons and file extension after the url supplied. The extension will not be added by the resource class. These extensions only exists to help resource class to identify what tag should be used to resolve such urls. The urls when imported will be resolved into :

  <script src="http://site.com/js-file">

  <link href="http://site.com/css-file">

#Resource Attributes

There are cases in which certain urls may have atrributes attached to them. In order to add attributes to tags, we can employ the use of = & > sign (i.e => ) to point our attributes:

  Res::name('scripts')
  
     ->url('http://site.com/js-file:::js => class:value; id: some_id')

     <script src="http://site.com/js-file" class="value" id="some_id"></script>

In example above, we added attributes to our static urls. As revealed above, attributes can be separated using the ; semicolon character. The script above is an example of the script tag format that will be returned when the resource is imported.

#Resource Binding

The binding of resources is similar to naming of resources because it involves binding of resources together with a unique name. Resources can either be bound as a single entity or by merging two or more separate resources urls or resource groups. Although, the Resource class already supports the declaration of names for resource groups, the binding or resources however provides the most basic form of way to handle resources urls. In order to achieve this, each resource url is given its own unique resource name immediately it is stored. The unqiue resource name assigned will then make it possible to create or merge resources into unique resource groups. In this case, both resource groups and resource urls share the same storage space which means that a unique name can only be assigned once to either a resource url or resource group but not both. The main methods of consideration under this feature are the named(), bind() and bindTo() methods. Before a binding of resources is possible, each resource url should have its own unique name defined by the named() method. An example of this is shown below:

Resource Binding (single entity)

  <?php 

  Res::open()
     
     ->url('file1.css')->named('link1')
     ->url('file2.css')->named('link2');

The sample above is the most basic way of binding resource url as a single entity to their unique names. Once the names have been properly assigned, we can easily import them by calling the Res::recall() method. As shown below

  <?php 

  ... continued ...

  var_dump(Res::recall('link1'));

  var_dump(Res::recall('link2'));

The sample above will resolve as shown below:

  <link href="file1.css" rel="stylesheet" type="text/css">

  <link href="file2.css" rel="stylesheet" type="text/css">

From the code above, we can see that it becomes easy to call each file by simply calling their unique names. In template files, we can either use the @recall() or the @load() directive to import resources through their unique names. In the case where we need to store urls as groups, we can easily bind urls together either with bind() or bindTo() method. The bind() method is used to bind two or more existing unique names together into a new unique name (or group). This is shown below:

  <?php 

  Res::open()
     
     ->url('file1.css')->named('link1')
     ->url('file2.css')->named('link2')

     ->bind('links', ['link1', 'link2']); // merge both "link1" and "link2" into a new "link3"

  var_dump(Res::recall('links'));

In the sample above, two resource urls were merged together into a new group "links" through their unique names. This method makes it easier to group separate entity resources. This bind activity can only be performed once for a unique non-existing name. This means that the as in the case above, after the unique name "links" has been defined, we cannot re-apply the bind() method on that unique name. However, another method of great importance is the bindTo() method. This method either merges existing unique groups together into a new group or it binds previously named resources into new named group and flushes the binded values. A basic sample of how to use the bindTo() method is shown below:

  <?php 

  Res::open()
     
     ->url('file1.css')->named('link1')
     ->url('file2.css')->named('link2')

     ->bindTo('links'); // bind previous url lists to a new group and reset list

  var_dump(Res::recall('links'));

In the sample above, the bindTo() method is used immediately after the two url declarations. This automatically tells the Resource class to bind the previous resource urls together under a new unique name "links". This is an improvement over the previous bind() method. Now, when we call the Res::recall(), both of the urls will be imported to the webpage in the format below:

  <link href="file1.css" rel="stylesheet" type="text/css">

  <link href="file2.css" rel="stylesheet" type="text/css">

This method also has an extended feature that makes it possible to add more resource urls to existing binds. An example of this is shown below:

  <?php 

  Res::open()
   
   ->url('file1.css')->named('file1')
   ->url('file2.css')->named('file2')

   ->bindTo('links1'); // bind "file1" and "file2" into "link1", reset list
   
   ->url('file3.css')->named('file3')
   ->url('file4.css')->named('file4')

   ->bindTo('links2'); // bind "file3" and "file4" into "link2", reset list
   
   ->url('file5.css')->named('file5')
   ->url('file6.css')->named('file6')

   ->bindTo('links1'); // add "file5" and "file6" into existing "link1", reset list

As seen above, the declaration of bindTo() method marks the end of previously named resource files. This prevent resources files from accidentally falling into a wrong group. The last line shows that we can easily bind new list of resource files into an existing group. However, in certain cases, the bindTo() method may not reset previously named resource files. This situation occurs when it is used to perform a different function which is the merging of two or more existing groups together. An example is shown below:

  <?php 

  Res::open()
   
   ->url('file1.css')->named('file1')
   ->url('file2.css')->named('file2')

   ->bindTo('links1'); // bind "file1" and "file2" and reset named list.
   
   ->url('file3.css')->named('file3')
   ->url('file4.css')->named('file4')

   ->bindTo('links2'); // bind "file3" and "file4" and reset named list
   
   ->url('file5.css')->named('file5')
   ->url('file6.css')->named('file6')

   ->bindTo('links3', ['links1','links2']) // merge "links1" and "links2" into "links3"

   ->bindTo('links4'); // bind "file5" and "file6" and reset named list

In the sample above, the last declared bindTo() was not used to bind previous resource urls. Instead, it was rather used to merge two existing resource groups together. In this situation, the unique name "links4" will still be able to bind the previous "file5" and "file6" together because these resource urls are still available and have not been reset. Although, the structure above may be valid, it is a much better practice to employ a more readable structure to make it easier to read. The format above can be restructured as shown below:

  <?php 

  Res::open()
   
   ->url('file1.css')->named('file1')
   ->url('file2.css')->named('file2')

   ->bindTo('links1'); // bind "file1" and "file2" and reset named list.
   
   ->url('file3.css')->named('file3')
   ->url('file4.css')->named('file4')

   ->bindTo('links2'); // bind "file3" and "file4" and reset named list
   
   ->url('file5.css')->named('file5')
   ->url('file6.css')->named('file6')

   ->bindTo('links4'); // bind "file5" and "file6" and reset named list 
   
   ->bindTo('links3', ['links1','links2']) // merge "links1" and "links2" into "links3"

In the sample above, the merging of files was done at the last line after all the declarations have beem made. It is much better to perform all merging of resources after all declarations have been made. This makes it easier to read and manage resource urls or groups. Not only can we bind groups, we can also bind unique names to groups as in the case below:

  <?php 

  Res::open()
     
     ->url('file1.css')->name('f1')
     ->url('file2.css')->name('f2')

     ->bindTo('a-links'); // bind f1 & f2 as group
     
     ->url('file3.css')->name('f3')
     ->url('file4.css')->name('f4')

     ->bindTo('b-links'); // bind f3 & f4 as group

     ->url('file5.css')->name('f5')
     ->url('file6.css')->name('f6')

     ->bindTo('c-links.css')

     ->bind('d-links',['f5','a-links']); // merge "f5" and "a-links" (f5, f1 and f2).

It is important to mention that the order in which resources are listed, binded or merged is the order in which they will be imported. Hence, the order of resources matters a lot. A var_dump() of the code above will resemple the format below"

  var_dump(Res::recall('d-links')); //all items in "f5" and "a-links" (i.e file5.css, file1.css, file2.css)                                          
  
  <link href="http(s)://your_domain/file5.css" text="text/css" relativity="stylesheet">
  <link href="http(s)://your_domain/file1.css" text="text/css" relativity="stylesheet">
  <link href="http(s)://your_domain/file2.css" text="text/css" relativity="stylesheet">

#Resource importation

Resources can be imported using different methods. There are basically two importation types that can be done which are categorized based on the naming pattern used for storing the resource files.

Resource Name Importation
Resource Merged Importation

Resource Name Importation

The resource name importation is done in the situation where the Res::name() is used to name a resource file. In this situation, the Res::import() method or the @import() directive are the relative helpers that can be used to import the stored resource files. Consider a resource file with code structure below:

Resource file sample

  <php?

  Res::new('res/assets/')
  
     -> name('anime')
     -> url('css/anime.css')
     -> url('js/anime.js')
     
     -> name('design')
     -> url('css/design.css')
     -> url('js/design.js');

Assuming we have a code structure as shown above in a resource file and the resource file is included in our web application, We can easily import the resources in a rex template file as shown below

  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>some template file</title>
    @res(':anime')  <-- import resources in anime group -->
  </head>

In the sample above, the "anime.css" and "anime.js" resources where imported using their storage group name preceded by a colon. Similarly, we can import the design using the same method.

  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>some template file</title>
    @res(':design')  <-- import resources in design group -->
  </head>

Resource Merged Importation

Binded or merged resources are imported in a different way because they are stored in a different storage space. When resources are binded as a single entity or as a group, the Res::recall() method or @load() directive can be used to import such binded resources. Consider the following binded resources

Resource file sample

  <php?

  Res::new('res/assets/')
  
     -> url('css/anime.css')->named('animeCss')
     -> url('js/anime.js')->named('animeJs')

     -> bindTo('animeFiles');

The resource file above can be imported by calling the unique name in a template file as shown below:

    <head>
      <title>sample template file</title>
      @load('animeCss') <--import animeCss file -->
      @load('animeJs')  <--import animeJs file -->
    </head>

We can also import both file at once in a single line as shown below

    <head>
      <title>sample template file</title>
      @load('animeCss:animeJS') <--import animeCss and animeJs files -->
    </head>

While the approach above seems easier, there is a much better approach we can use to import both files. Since we have a unique group name to which both resource urls are binded, we can easily load the resource files using their group name as shown below:

    <head>
      <title>sample template file</title>
      @load('animeFiles') <--import animeCss and animeJs files -->
    </head>

The sample above shows that resource merging is a much better improvement made on naming resource files unlike the Res::name() method. It is much preferable to merge (or bind) resource files to storage names rather than ordinary naming (or grouping) of files as this will make it much easier to control the flow of resources. There are other means by which resource files can be imported. The code structure above is a resource file sample format that will be used to provide more explanation on resource files importation.

Resource file sample

  Res::new('res/assets/')
  
     -> name('anime')
     -> url('css/anime.css')
     -> url('js/anime.js')
     
     -> name('design')
     -> url('css/design.css')
     -> url('js/design.js');

Importing Groups

To import a group, a colon must be declared before the group name. The methods below reveal methods by which stored resource groups can be imported into web page using the Res::import() method.

  1. Res::import(':anime');  // import anime group
  2. Res::import(':design'); // import design group
  
  3. Res::import([':anime', ':design']); // import anime and design group
  
  4. Res::import('res/',[':anime', ':design']); // import anime and design group, use parent path "res/"

In example above, line 1 & 2 are methods of importing stored groups separately. The use of array in line 3 is a concise way of importing multiple groups, without having to call the import() directive every time. Files are resolved and imported in the way they are stored. In line 4, urls are imported with parent url of res/ . However, this was used for testing purposes hence not recommended for use. In template files, the @res() directive is mostly used for importing stored resources from the res/res.php resource file.

Exporting Groups

To export a stored a group, the Res::export() can be used. This can be also be achieved by using Res::import(). Example below reveals how to export stored urls into variables

  $urls = ":lists";
  
  Res::import('', [':anime'], $urls);
  
  var_dump($url);

In example above, the variable $url was set with a value of :lists, then supplied into the Res::import() method. The directives tells the Resource class to update the value of $url with the stored urls. Hence, $url was printed out to the page. Another way to export stored urls is shown below:

  $exports1 = Res::export([':anime']);
  $exports2 = Res::export('../',[':anime']);

In example above, the first variable will contain the stored urls while line 2 adds a suffix of ../ to imported local urls. The application of parent urls comes as a modification to existing urls that may become invalid in static scripts. These helps to properly map the loaded urls to their specific folders.

Exporting Binded Groups

To export a merged or binded resource a group, the Res::recall() can be used. This method takes two arguments. When the second argument is set as true, the script files will be returned in an array format, making it easier to see the files that are stored in a unique group. Assuming we added a resource file below

Resource file sample

  Res::new('res/assets/')

     -> url('css/anime.css')->named('animeCss')
     -> url('js/anime.js')->named('animeJs')

     ->bind('animeCss');

  $resources = Res::recall('animeCss', true);
  
  var_dump($resource);

In example above, the $resource will return an array of relative scripts stored. It is important to note that relative paths to file are usually validated. Hence, the file must exist locally within the application and also in the path provided before it can be successfully added to storage. This helps to remove uneccesary resource links from the web application.

Docs Resource Static-files