From JFramework Wiki

This is the official jFramework manual. It contains all the documentation and developers guide for jFramework. This is intended to be a one page solution to all jFramework questions.

Contents 1 Overview 2 Installation 2.1 Requirements 2.2 Download 2.3 Deploy 2.3.1 Extraction 2.3.2 Database Setup 2.3.2.1 jFramework without a Database 2.3.2.2 jFramework with a Database 2.3.3 Web Server Setup 2.4 Configuration 2.4.1 application.php 2.4.2 setting.php 3 Development 3.1 What's inside? 3.1.1 _japp/ 3.1.1.1 _japp/config 3.1.1.2 _japp/control 3.1.1.3 _japp/lib 3.1.1.4 _japp/model 3.1.1.5 _ japp/plugin 3.1.1.6 _japp/service 3.1.1.7 _japp/view 3.1.1.8 _japp/controller.php 3.1.2 app/ 3.1.2.1 config/ 3.1.2.2 control/ 3.1.2.3 model/ 3.1.2.4 plugin/ 3.1.2.5 service/ 3.1.2.6 view/ 3.2 How it works? 3.2.1 Request Types 3.2.2 The Flow 3.2.2.1 Application Requests 3.2.2.2 Service Requests 3.2.2.3 Resource Requests 3.2.3 Your Controller 3.3 Understanding Key Features 3.3.1 jPath 3.3.1.1 Module Paths 3.3.1.2 Request Paths 3.3.1.3 Resource Paths 3.3.1.4 FileSystem Paths 3.3.1.5 Classname 3.3.1.6 Custom Paths 3.3.2 MVC 3.3.3 ApplicationController

Overview

To be added later...

Installation

This section aims to provide a complete guide on obtaining, deploying and installing jFramework.

Requirements

jFramework main requirements are as follows:

• Apache + mod_rewrite (a single .htaccess file in jFramework root uses mod_rewrite)
• PHP 5.2.6+ (jFramework has been developed and tested on this version of the PHP, It might work with older versions, And definitely works on newer versions - tested)
• MySQL + MySQLi PHP Extension (to use any other database server or any other driver for MySQL, simply code the wrapper DBAL Adapter)
• Zend Engine (optional, but greately improves jFramework's performance)

jFramework has been developed mainly on Mac OS X Leopard 10.5.6 and partially on Microsoft Windows Vista and tested on both, And it should work on every operating system that supports PHP.

Note: Different jFramework Plug-ins might have their own requirements.

Download

Visit http://jframework.info to get your desired release, And to directly get the latest trunk release of jFramework, use this link http://jframework.info/app.get .

Deploy

Deployment of jFramework consists of a few tasks, namely as follows:

Extraction

Extract the comopressed archive you just downloaded into a folder you intend to be the root of your jFramework Application. Keep in mind that jFramework package consists of several folders and a few files on the root, so make sure to extract it inside a folder. Now make sure the following 4 items are inside your extracted packaged:

• _japp/
• app/
• index.php
• .htaccess

You might not see the last item, since its a dot file and hence is by default hidden on Linux and Mac OS X platforms.

Database Setup

You can have a jFramework deployment without any database setup. This way, jFramework functionalities that rely on database would simply be ignored, And you can yet use powerful features such as jPath and etc.

jFramework without a Database

Seek out app/config/application.php file, Open it with a text editor and comment or remove the following three lines:

define("jf_DB_Name", "jf");

define("jf_DB_Username", "root"); //simply set this to empty string "" to bypass any DB connection

define("jf_DB_Password", "");

Remember to save the file with UTF-8 encoding.

jFramework with a Database

Create a database with your own desired name (we name it here as jfdb from now on), Create a database user (we name it here jfdbuser), And assign it to jfdb with full privileges.

Seek out the file install/_db/db*.sql were * is the biggest number (these are different versions of jFramework Database SQLs), And import it to the database you just created.

The following 8 tables should be populated if you do this correctly:

• jf_logs
• jf_options
• jf_rbac_permissions
• jf_rbac_rolepermissions
• jf_rabc_roles
• jf_rbac_userroles
• jf_sessions
• jf_users

Seek out the app/config/application.php file, Open it with a text editor and modify the following three lines:

define("jf_DB_Name", "jf");

replace "jf" with your database name, e.g "jfdb"

define("jf_DB_Username", "root"); //simply set this to empty string "" to bypass any DB connection

replace "root" with your database user, e.g "jfdbuser"

define("jf_DB_Password", "");

replace "" with the password you've set for your database user

Web Server Setup

Head to your jFramework folder via your browser. If your local web root is /etc/htdocs, and you've extracted jFramework to /etc/htdocs/myjf, You should point your browser to http://localhost/myjf/.

If you could see the jFramework homepage there, Then you're all set. If you encountered an error, like

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Then most probably your Apache's mod_rewrite is not enabled or you don't have rights to use it. Try this URL as well http://localhost/myjf/app.main, This should point to the same page. In case you get the same error, Its surely a problem with mod_rewrite.

You might get an error like this

Unknown Error 2 : mysqli::mysqli() [mysqli.mysqli]: (42000/1049): Unknown database 'jfdb'

This indicates that the database name you provided in application.php is not valid and in fact does not exist. If you get this

Unknown Error 2 : mysqli::mysqli() [mysqli.mysqli]: (42000/1044): Access denied for user @'localhost' to database 'jfdb' 

It indicates that either the database user does not exist or it has no access to that database (or password invalid). Fix these steps and you're ready to continue.

Configuration

All configurations regarding your jFramework application reside in app/config/, And the two more important files are application.php and setting.php. All the configurations regarding the jFramework core (the actual framework), like database table names, field names and system-wide constants are stored in seperate files inside _japp/config/. We'll consider them later on this manual.

application.php

This file is known as the Application Settings file. Everything that is very likely to be changed for every specific jFramework application is packed here with comments describing it. These configurations are as follows:

• SiteRoot : This is automatically set by the framework, And indicates your site root, e.g "http://jFramework.info" without a trailing slash. If you experienced problems with file and folder absolute paths, Set this manually.
• APPLICATION_VERSION : This global constant holds your application version (not jFrameworks), So feel free to change it as you change your code. It is automatically used in logs, pages and etc.
• APPLICATION_NAME : This should be a name for your application. It would be much better if you use a short name consisting of only alphanumerics.
• APPLICATION_TITLE : This is like a description to your application. This is automatically set as page title for pages that has no title and etc.
• jF_PresentErrors : Set this to false to prevent jFramework from displaying errors AT ALL. This is good when you want to release your application. jFramework would automatically log errors either ways.
• jF_FILE_DOWNLOAD_LIMIT : This is the download limit you provide to each visitor of your site. If you set it for example to 10*1024, Downloads from your site are done with a speed of 10KB/s. Use this when you're under bandwidth limits, Or simply remove or comment it to disable this functionality. This rule applies to all files, including web pages, images, styles and etc.
• jF_DOWNLOAD_LIMIT_ON_BIGGERS_THAN : If the above options is set, Files which are smaller than this size would discard that. This is handy for web pages, i.e styles, scripts and images on a web page won't be loaded slower than the client's internet speed.

There are two other files:

$this->LoadModule("config.my");
This enables you to put your application specific options (not regarding jFramework) in a file named my.php in the same folder.
$this->LoadModule("config.static");
This loads the static configurations, 
i.e settings that use some logic to determine something such as the 
user agent (mobile/browser) or the path to a file.

Also keep in mind that these configurations are considered after the jFramework's initialization, So if there's an error in the initialization process of jFramework, jF_PresentErrors would not affect it. After loading of these configurations, the jFramework libraries are loaded and user request is served. That's all with the application.php.

setting.php

This file is the jFramework's core settings. It is loaded before creation of ApplicationController object which starts the jFramework, So anything in this will eventually run before anything else, And that's the exact reason why this file exists. The following configurations are inside:

• define("BR", "
  "); isn't it better to code echo "Hello there!".BR; ?
• set_magic_quotes_runtime(false); since jFramework does not get along with magic_quotes, this is turned off on the beginning.
• define("jf_ErrorHandler",true); enables jFrameworks built-in error handler. This error handler has more features than the standard PHP error handler.
• define("jf_Controller_AutoController",true); AutoController would automatically present Views that has no corresponding controller.
• define("jf_Controller_AutoPresent",false); for extra lazy programmers, This would rid the need to Present inside your controller!
• define("jf_LazyLoad",true); Lazy Loading currently applies to jFramework Libraries. Since it has a wrapper, It would make them perform a little slower than usual, But would greatly improve performance if you don't use jFramework Libraries frequently.

That's all there is to setting.php, Also keep in mind that you can move configurations such as jF_PresentErrors from application.php if you want it to apply before anything.

Development

This section of the manual -which is quite long- is dedicated to getting to know jFramework and developing your own applications with jFramework. It is assumed that the reader has minimum understanding of the PHP language (including PHP 5.0 OO features and Object Oriented Programming), And any rigorous PHP used anywhere is explained in details throughout this manual.

What's inside?

The first mandatory step is to discuss the jFramework file/folder structure and describe what role every file or folder plays in jFramework:

1. _japp/ The jFramework's core system
2. app/ Your web application modules
3. files/ Your web application files (downloadable files)
4. images/ Your web application images
5. install/ Temporary deployment folder (you can remove it after deployment)
6. script/ Your web application scripts
7. style/ Your web application style sheets
8. index.php Would only run if mod_rewrite is not working!
9. .htaccess Apache config file, Enables mod_rewrite and sends all requests to _japp/controller.php

_japp/

The _japp/ folder is the jFramework folder. All the files regarding jFramework's self are inside this, And an application developer should not peek inside unless there's a need for a tweak that's not already forseen. The _japp/ folder, Which would be refered to as jFramework System Folder or simply System Folder has the following structure:

1. config/ this serves as the repository for internal jFramework configurations, and will be discussed thoroughly later.
2. control/ jFramework's core uses a MVC design, this is the controllers folder for that. sys.main resides here.
3. docs/ jFramework development docs, such as bugs, todo and etc.
4. lib/ jFramework Libraries, A lot of time and effort has been put here to prepare mighty and flexible libraries.
5. model/ the model folder for jFramework's core MVC
6. plugin/ plug-ins that are used by jFramework itself are here. You web application plugins should go somewhere else.
7. service/ jFramework's core services. These are not developed yet, but would allow a third party to fully interact with a jFramework deployment.
8. view/ the view folder for jFramework's core MVC
9. controller.php this is the entry point to jFramework. the ApplicationController class which handles the whole jFramework powered application is defined here.

A mandatory description of these folders are followed:

_japp/config

1. lib/ jFramework libraries internal configurations are held here
   1. log.php contains table/field constants for LogManager library including logging severity constants (e.g jf_LOG_INFO)
   2. options.php contains table/field constants for ApplicationOptions library, including options timeouts and options sweep ratio constants
      • TIMESTAMP_MINUTE,TIMESTAMP_HOUR,TIMESTAMP_DAY,TIMESTAMP_WEAK,TIMESTAMP_MONTH,TIMESTAMP_YEAR,TIMESTAMP_FOREVER constants containing the appropriate time in seconds
      • jF_Options_DefaultTimeout the default timeout for options, which is set to TIMESTAMP_FOREVER
      • jF_Options_SweepRatio demonstrated out of how many options operations, there should happen a sweep (of expired options). Defaults to .005 (0.5%)
   3. rbac.php contains table/field constants for all 4 RBAC tables
   4. session.php contains table/fields for session and user and the following constants:
      • jF_SessionTimeout_NoAccess which defines session timeout for no activity, defaults to 1800 seconds (30 minutes)
      • jF_SessionTimeout_General which defines the absolute session timeout, defaults to 604800 seconds (a weak)
      • jF_PasswordHash_Constant_Concat_String which is a constant string concatenated to passwords before they are hashed, defaults to jFramework
2. strings/ reserved for multilingual jFramework core, empty.
3. .htaccess just to prevent direct access to this folder
4. main.php main jFramework core options, including jFramework version and the starting point to load other configurations (e.g app/config/application.php)
5. services.php jFramework services configs

_japp/control

Contains the controller files regarding jFramework's administration interface (sys.main) such as login.php(sys.login), main.php(sys.main) and logout.php(sys.logout)

_japp/lib

jFramework libraries, almost every library is coded in a single file, except DBAL which has a folder of interfaces and adapters:

1. dbal/ containing Database Access Layer library modules
   1. adapter/ contains DBAL adapters
      • mysqli.php The MySQLi adapter for MySQL (including DBAL, PreparedStatement and Transaction wrappers)
   2. nestedset/ implementations of nested set for managing hierarchical data and RBAC
      • base.php BaseNestedSet class
      • full.php FullNestedSet class, used widely in RBAC library and derived from BaseNestedSet
   3. interface.php holds jFramework interfaces for different DBAL functionality, these are used to develop adapters
2. dbal.php the loader for DBAL library. Load's default adapter, interfaces and etc.
3. log.php the logger library
4. options.php the options library, provides stateful programming between sessions, applications and users
5. phpxml.php the XML 2 Associative array & vice-versa convertor
6. rbac.php the massive Role Based Access Controller (level 2 NIST standard)
7. security.php the security library
8. session.php the session and user management library
9. tracker.php the web tracker, profiler and statistics

_japp/model

most of the jFramework's core model is here (aside from libraries), This is because jFramework tries to follow its order itself.

1. base/ Base classes that you might need to inherit in order to develop, are placed here
   1. app.php BaseApplicationClass
   2. control.php BaseControllerClass
   3. plugin.php BasePluginClass
   4. service.php BaseService
   5. view.php BaseViewClass
2. core/ core jFramework models (code required for a framework!) is here
   1. error/ these are in fact some special views to handle some special error dialogs (HTTP Status Codes)
   2. errorhandling.php jFramework's Error handler, This module has the responsibility of providing the user with more sophisticated errors (in development)
   3. fileman.php jFileManager or the download manager of jFramework. jFramework serves all its files itself, And does not rely on Web Server for file serving.
   4. jpath.php the famous jPath module. In fact, This is the first loaded file in jFramework, and helps locate other modules.
   5. jurl.php the jURL module, handles the Server and URL configurations and parameters.
   6. lazy.php the jLazyLoad module, used when lazy loading enabled.
3. services/ contains jFramework modules to handle web services
   1. help/ reserved
   2. input/ the service input unwrappers, They allow jFramework to support these service encodings for input data:
      • array.php PHP Associative-Array
      • base.php the base input unwrapper
      • json.php JSON data
      • serialized.php serialized PHP data
      • soap.php the usual SOAP messages
      • xml.php pure XML in the form of jFramework

Keep in mind that you can write your own service wrappers and unwrappers and its a very easy task.

1. 1. output/ the service output wrappers, They allow jFramework to support these service encodings for service output:
      • array.php PHP Associative-Array
      • base.php the base input unwrapper
      • json.php JSON data
      • jsonp.php JSONP or JSON with padding
      • serialized.php serialized PHP data
      • soap.php the usual SOAP messages
      • xml.php pure XML in the form of jFramework

1. 1. reader/ reserved for service call wrappers
   2. core.php the core service handler object

1. system/ is the jFramework Administration Interface's model. A few files to handle jFramework's Administration Interface and they evolve frequently. Can be served as an example if you're willing to implement your own interaction interfaces for jFramework.
2. j.php the 'j helper class (to simplify jFramework common tasks)

_ japp/plugin

The plugins used by jFramework core are just a few. jFramework does not intend to re-invent the wheel, So we used a few well known open source projects, And this demonstrates how easy it is to add an open source project as a jFramework plugin into your application:

1. nusoap/ the famous nuSOAP library for PHP, simplifies the SOAP messaging, and is used for the same purpose in jFramework
2. pki/ reserved for the jPKI library, developd by jFramework team
3. useragent/ plugin determines the type of user agent (i.e mobile/pc/etc.)
4. calendar.php Gregorian to Jalali and vice-versia calendar for use in Jalali websites
5. htmlawed.php the htmLawed library for HTML, CSS and Javascript validation. used by AntiXSS

That's all!

_japp/service

This whole section is reserved until we provide a service-based approach to all jFramework's core functionality.

_japp/view

contains the view files for jFramework Administration Interface (sys.main)

_japp/controller.php

app/

All of your application's PHP code and modules goes here. This is your web application folder, and thats why the other folder is name _japp/, Because in most cases, You don't even need to know whats there! The app/ folder almost follows the same structure as the _japp/ folder, with a few less and more stuff:

1. config/ holds your application specific configurations
2. control/ contains the controllers for your MVC or non-MVC design
3. model/ contains the models for your application
4. plugin/ can hold the plugins of your web application
5. service/ can hold your applications web services
6. view/ holds your application views

config/

You've seen a little of config/ in the deployment section, Here it gets described thoroughly:

1. pages/ the special pages which jFramework uses to present (for example on errors), you should customize these
2. patch/ can handle patches for you
3. static/ contains the following determination logic:
   • custompaths.php handles the custom jPath rules
   • distributed.php is used to handle a distributed jFramework deployment
   • viewdetector.php determines the kind of user agent, e.g mobile or pc
4. application.php contains your application specific configurations regarding jFramework
5. my.php contains your application specific configurations regarding your own application, just put there if you ever wanted to use any
6. setting.php contains jFramework specific configurations
7. static.php has the role of loading static/ config files according to your settings

You can add your desired files and folder to this folder, as long as you don't ruin the explained structure.

control/

You put your controllers, which are the doors to your web application here. The default controller is main.php which is there for app.main or the default web site view (that is e.g http://jframework.info/). This controllers should then handle the rest of the application.

model/

You put your model here. Models are your application's business logic. You are not forced to follow any conventions here, Just put your desired files and folders here, and load them in an appropriate controller whenever they are needed.

plugin/

There are by default a few plugins inside jFramework. Plugins make it easy for you to adopt another open source (or commercial) PHP code or write your own independent code to use in many applications. jChat which is a web-based AJAX chat system, jHTMLChart which draws bar charts using only HTML and CSS (and no image generation) and a few Javascript plugins are already included in the default package (due to their common use). You can simply remove them from your plugins, without affecting the rest of jFramework and your web application (thats why they are placed under app/plugin/ instead of _japp/plugin/)

service/

Services are sweet! You can put your web service interfaces here, i.e whichever web service your put an interface to it here, Is added to your jFramework automatically and can be accessed via the world.

view/

The view section is almost different from all other parts, Since it contains a lot of HTML (and probably CSS and Javascript) and a few PHP code. jFramework views support a few features that greatly simplify the task of view creation and handling for you. There are possibly two folders inside the view/:

• default : by default depending on your view detector static logic, This is the view that is used.
• mobile : if you put this folder here, mobile browser requests use this view instead of default view, so remove it if you don't want a different view for mobiles (and disable the view detector logic to improve performance)

How it works?

This section is intended to provide you with an understanding of how jFramework does the things it does, After this you should be able to know the flow of data and control inside the framework, So that you can intercept whenever and wherever required.

Request Types

There are three types of requests applicable to jFramework:

• Application : These are equal to web page requests in the world wide web
• Service : These are the web service requests
• Resource : Whether a client needs an script or image file to load the page successfully, or it needs to download a huge file, These are all handled as Resource requests.

The Flow

• Web Server (typically Apache with mod_rewrite) transfers the request to jFramework ApplicationController (_japp/controller.php)
  • The Request URI is converted into a HTTP GET parameter named 'r' to be consumed by the ApplicationController
  • Other GET/POST/etc. parameters are redirected to the ApplicationController
• ApplicationController loads 'jPath' module and app/config/setting.php core configurations
• a new ApplicationController object is instantiated (namely $App in controller.php line 300)
  • the ApplicationController constructor only loads the jLazyLoad module to be able to lazy load other modules
• $App->Start() which is the start point for the jFramework Application is called
  • Start() generates a unique ID for the request
  • Start() calls $App->LoadApplication() which loads application modules
• LoadApplication() registers SPL Class Autoloader as $App->Autoload() and loads the following modules:
  • ErrorHandling module (model.core.errorhandling)
  • jURL module (model.core.jurl)
  • BaseApplicationClass (model.base.app)
  • BaseViewClass (model.base.view)
  • BasePluginClass (model.base.plugin)
  • BaseControllerClass (model.base.control)
  • Main Configurations (config.main) which loads Application Configuration and other configurations (all config files are loaded here)
• Start() determines the type of request using the $_GET["r"] and unsets that.
  • If request is of the form "app" or "sys", it's an Application Request
  • If request is of the form "service" it's a Service Request
  • Otherwise its a Resource Request

Application Requests

Requests of form app.main or sys.login are application requests. They are usually requested by a user visiting your web application and through a browser, Which would request a lot of resources to complete that page and a few services if its a dynamic AJAX based page. Application requests are subgrouped into System Interface Requests and Application Interface Requests.

Flow continues as:

• SYSTEM_MODE constant is defined as 'false' for Application Interface Requests and 'true' for System Interface Requests
• $App->LoadLibraries() loads all the jFramework Libraries and the 'j' helper class and service core
• The requested controller is determined using jPath's jpRequest2Module
• $App->StartController() is called to handle the requested controller
  • If the controller exists, and is MVC based, the controller object is created and started
  • If the controller exists, and is non-MVC based, the control is transferred to it.
  • If the controller does not exist, but the appropriate view exists and AutoController is enabled, the view is presented using the AutoController.
  • Otherwise false is returned and an error generated.

From this moment on, The Application flow is totally under the started Controller, i.e your web application.

Service Requests

Requests of the form service.* are considered service requests.

Flow continues as:

• $App->LoadLibraries() loads all the jFramework Libraries and the 'j' helper class and service core
• The requested service is determined using jPath's jpRequest2Module
• HTTP GET/POST parameters are merged into $Params to be handed over to the called service
• The control is handed to Service Core and it's resulted headers and data are expressed

Resource Requests

All the files that need to be downloaded by the client (e.g web page images, scripts, stylesheets, or downloadable contents such as a zip file) are considered resource requests. They are of many forms:

1. script.*
2. style.*
3. file.*
4. img.*

The flow continues as:

• jFileManager module is loaded (model.core.fileman)
• The requested resource is converted to the file system path using jPath's jpResource2FileSystem
• a jFileManager object is instantiated , and its Feed() method is invoked using the requested file as the parameter
• The jFileManager feeds the file according to type of request and jFramework options to the client

Your Controller

As most of what you develop is accessible via Application Requests and your controllers, It is required to know best practices here.

You can actually do anything you want in your controller, for example you can do a full PHP application your way. So what's jFramework for? You can use its features and more importantly its libraries in your controller, via $this for procedural programmers and $this->App for Object Oriented Programmers.

If you're following the MVC design approach, You should LoadModule your model (in procedural programming) or instantiate your model (in OOP), Handle the request, do your logic, then LoadModule or Present your view. If not an MVC lover, Simply do whatever you want in your controller, The only thing you are forced to do is to put your starting controllers in app/control/.

Understanding Key Features

The following key concepts in jFramework development need to be understood before any developer can start using jFramework:

• jPath is a module that handles path/name conversions
• MVC is the design patterns recommended by jFramework
• ApplicationController is developer's gateway to jFramework

These concepts are explained thoroughly below.

jPath

Every application handles a lot of resources. These different resources are indicated by paths, These paths have different names, file system paths, URLs, memory addresses and etc. There are four major paths in jFramework:

• File System paths indicate a file or folder on the file system on the server
• Module paths indicate a jFramework module inside jFramework folders
• Resource paths indicate jFramework resource to be used by the client
• Request paths indicate different kinds of requests to jFramework

A developer would not deal with File System paths in jFramework directly, Since any of the three other paths are converted to File System paths via jPath module. Also all the paths are consisting of sections joined by delimiters, e.g /home/account consists of two sections, namely home & account and two '/' delimiters.

All the default delimiters referred to in the following sections, Are defined in jPath.php file in _japp/model , since jPath is the first module loaded in jFramework, We could not put its options inside setting.php or etc. You can change them if you want, but make sure to read the section Custom Paths before you do that.

Module Paths

A module is simply a php file containing code or html. A module path is used whenever you want to load a module (or jFramework does). The three module loader methods, namely

1. LoadApplicationModule which loads an application module
2. LoadSystemModule which loads a system module
3. LoadModule which loads and application or a system module depending on 'SYSTEM_MODE'

These functions receive a Module Path as the first input parameter. By default, module paths are delimited by 'dots' '.', so if you want to load the module residing in app/config/setting.php, you simply call

LoadApplicationModule("config.setting");

Since if you use MVC design, most of the modules contain only a PHP class, So if your class has a well formatted jFramework name, you don't even need to load its module! You can just start using it.

The following two jPath objects are vastly used when dealing with modules:

• jpModule2FileSystem ($ModulePath, $System=false)

Example 1: echo new jpModule2FileSystem("config.setting");
outputs /path/to/your/jframework/deployment/app/config/setting.php

Example 2: $fp=fopen(new jpModule2FileSystem("config.main",true));
opens the file /path/to/your/jframework/deployment/_japp/config/main.php

Note: Keep in mind that new jpModule2FileSystem returns an object, not a string. This object is automatically converted to a string (__toString() method) whenever required, but might cause warning sometimes. to manually cast it to a string, try the following:

$file=new jpModule2FileSystem("control.main");
$file.="";

• jpRequest2Module ($RequestPath)

We'll explain this in Request Paths

Request Paths

We've already considered different jFramework requests at Request Types. A request paths is an external path used to submit a request to jFramework. It starts with app,sys or service. Keep in mind that for example request that start with file are not considered a Request Path, but are considered a Resource Path.

The default delimiter for request paths are as well dots. If you change it to for example '/', your requests change from

http://jframework.info/app.jpki.ui

to

http://jframework.info/app/jpki/ui

Of course you can change the delimeter to anything you want, for example '--' :

http://jframework.info/app--jpki--ui

Note: Changing the delimiter would not change the URLs used in your views, and might also break the links to your application from other websites. We recommend that you choose your desired delimiter at the beginning of your development and leave it be, Or use custom paths.

There's only one jPath class for Request Paths, it converts a request to the module that should be loaded to run the request, And it's used inside the ApplicationController, so basically a developer does not need to know it well, But might come in handy:

• jpRequest2Module($RequestPath)

Example 1: $App->StartController(new jpRequest2Module("app.main"));
Example 2: $App->LoadModule(new jpRequest2Module("service.dispatcher"));

Resource Paths

Resource paths are external paths as well, i.e they are used to indicate a jFramework resource in the whole world (and not inside the world of jFramework). A resource path starts with File,script,style,img or etc.. These paths should be converted to FileSystem paths so that jFramework file manager can provide them to the request source.

Default delimiter for resource paths are dots, and you can change them to whatever you want.

• jpResource2FileSystem($ResourcePath)

Example : echo new jpResource2FileSystem("img.document.file1.png");
Outputs /path/to/your/jframework/deployment/images/document/file1.png

Note: Since resource paths are frequently used in views (to indicate images, scripts, etc.) its highly recommended to use a specific delimiter for resource paths at the beginning of development and leave it be.

Caution: If you use dots as delimiters for resource paths, The last dot is not considered a delimiter, but is considered the extension dot for the file. So be cautious not to use files without extension or files that contain dots in their names in your jFramework structure, or change the delimiter.

FileSystem Paths

Classname

Custom Paths

MVC

ApplicationController