• Removed required_ports key from registor_action (vestige from days of old.)
• Deprecated ‘is_valid’ flag in favor of ‘is_set’ flag for pure pipe signature checks.
• Corrected omission of ‘error_message’ spelling check for ports in debug mode.
• Fixed JSON-formatting bug for REST-ful port validation requests containing multiple errors.
• Port ‘error_message’ option now properly overrides the default error messages generated for specific failures.
• Started tradition of adding version number to the ncore root docblock to facilitate identification of the current version of Nephtali you’re using.
• Fixed bug leading to unnecessary calls of curl parallel processing function.

As usual, let me know if you see any issues.

Next, either integrated unit testing (now that the syntactically pure pipe functions are done, unit testing should be quite enjoyable) -OR- using caching capabilities to parse HTML files, create AST’s and store optimized code for databinding pages (should lead to big performance payoff.) What would you like next?

I firmly believe developers should strive to account for as much complexity as possible in the early stages of development.  After establishing a strong, extensible foundation from which to work, we can then examine various use cases of developers to identify the most common needs, and work to provide tools (general functions, API enhancements, hooks, plugins, etc.) that facilitate these high-traffic scenarios.

General pipes

In terms of Nephtali pipes, I first created a general pipe registration function. While using the general pipe can sometimes require significant amounts of code, it is extensible to every situation I’ve encountered while using Nephtali.

Code block

n\pipe\register(
    $name = 'general_pipe',
    $function = function($markup, $args, $signatures)
    {
        // make it happen 
        return n\view\render($view = 'default', $markup);
    }
);

Action pipes

After working with Nephtali for a while, I realized that I could greatly facilitate one particular use case: performing specific actions if/when sets of ports are present on a request. This lead to the development of action pipes.

Code block

n\pipe\register_action(
    $name = 'user',
    $actions = array(
        n\port\signature(n\val('update_user')) => function($markup)
        {
            // typically have port validation code here and db update, but omitted for brevity
            return n\view\render($view = 'update', $markup);
        },
        n\port\signature(n\val('insert_user')) => function($markup)
        {
            // typically have port validation code here and db insert, but omitted for brevity
            return n\view\render($view = 'insert', $markup);
        }
    )
);

General pure pipes

Most recently, Nephtali had added the ability to work with functions that, at least in terms of syntactic appearance, are pure. The benefit to this type of approach is that unit testing a function that appears syntactically pure can be done with relative ease, as you can push in any set of values to a pipe’s function at test time to ensure that the function’s logic is correct.

Code block

n\pipe\register(
    $name = 'user',
    $function = function($markup, $args, $signatures)
    {
        if ($signatures['update']['is_valid']) {
            if ($signatures['update']['errors']) {
                return n\view\render($view = 'feedback', $markup, $signatures['update']['errors']);
            } else {
                if ($args['update']) {
                    return n\view\render($view = 'default', $markup, $rows = array('message' => 'User updated.'));
                } else {
                    return n\view\render($view = 'error', $markup);
                }
            }
        } else
        if ($signatures['insert']['is_valid']) {
            if ($signatures['insert']['errors']) {
                return n\view\render($view = 'feedback', $markup, $signatures['insert']['errors']);
            } else {
                if ($args['insert']) {
                    return n\view\render($view = 'default', $markup, $rows = array('message' => 'User inserted.'));
                } else {
                    return n\view\render($view = 'error', $markup);
                }
            }
        } else {
            return '';
        }
    },
    $opts = array(
        'signatures' => array(
            'update' => array('id','name'),
            'insert' => array('name')
	),
        $args = array(
            'update' => function($signatures) {
                return n\sql\action\update($table_name = 'users', $inputs = $signatures['update']['values']);
            },
            'insert' => function($signatures) {
                return n\sql\action\insert($table_name = 'users', $inputs = $signatures['insert']['values']);
            }
        )
    )
);

I think we can agree that the above example is painfully verbose, especially when one compares this code to equivalent code in other web frameworks. However, the above code is also very capable, and extends to situations where one may wish to manually work with many different sets of ports and sub-pipes, whilst keeping the ability to maintain the purity of the function (again, the purity I’m speaking of is the syntactic purity, which affords easy testing of the functions logic and correctness, as you can pass in any array of values to the $args array at test time.)

Now, having worked with the above code for several weeks, I’ve developed two functions that handle the most typical use cases.

Pure display pipes

One of the most common use cases is wanting to display a feedback view if one or more of the ports that the view requires is/are invalid, display a default view if there is data available, display an empty view if there is no data, or display an error view if there is an error during the processing of the pipe. This can now be accomplished through use of the n\pipe\register_pure_display() function.

The pure display pipe expects a default, empty, error, and feedback view present in the markup for the pipe. And, just as with the other pipe functions, you can also pass in an optional $opts argument to set the databinding (form or placeholder); whitelists; override the default, feedback, or empty functions; etc.

Code block

n\pipe\register_pure_display(
    $name = 'users',
    $rows_func = function($port_vals){
        return n\sql\source\query($query = 'SELECT * FROM users');
    }
);

Pure action pipes

As noted above, wanting to performing specific actions if/when sets of ports are present on a request is a common use case for Nephtali users, and the n\pipe\register_pure_action() function  facilitates this workflow utilizing the new pure capabilities. The first action to have a valid signature (all of the ports are present, but not necessarily valid) will be executed.

The pure action pipe expects the markup to contain a feedback view for displaying error messages if any of the ports are invalid, a status view for displaying the status message (databound to its {message} placeholder within the <!–data–> region), and an error view.

Code block

n\pipe\register_pure_action(
    $name = 'user',
    $actions = array(
        'update' => array(
            'io_func' => function($port_vals){
                return n\sql\action\update($table_name = 'users', $inputs = $port_vals);
            },
            'signature' => array('id', 'name'),
            'message' => 'User updated.'
        )
        'insert' => array(
            'io_func' => function($port_vals){
                return n\sql\action\insert($table_name = 'users', $inputs = $port_vals);
            },
            'signature' => array('name'),
            'message' => 'User inserted.'
        )
    )
);

Conclusion

Although not officially released yet, you can pull the changes from trunk to start utilizing the new pure functions to speed your development now. I won’t be changing the API at this point, although I may add a couple other features before making the next release. Hopefully you’ll find the new functions as useful as I do, and with this work out of the way, the next step will be to integrate unit testing directly within Nephtali.

Again, my apologies.

Update Feb. 23, 2012: To clear up confusion, the bug did not leave sites vulnerable in terms of security. Rather, Nephtali’s default behavior to escape all output overrode any whitelists that were set up to pass through the escaping mechanism. What this means is that sites were not left vulnerable to XSS attacks, but they were likely vulnerable to ugly aesthetics when expected tags were escaped.

There are many new enhancements (including some performance improvements) and some big new features, so hopefully you take the time to read up. That said, the biggest new features are changes to the API that promote the usage of pure functions within pipes, making it easier to write correct code and integrate unit testing.

And, as always, please let me know if you find any issues.

Basic updates

First, let’s get to the basic updates.

1. Pipes can be set to be optionally displayed if the markup for the pipe is present (just set is_optional to true in $opts array for n\pipe\register().)
2. Ports can now be registered in bulk through n\port\register_bulk().
3. Regexes updated for url and US phone.
4. Many micro-optimizations implemented.
5. Many improvements to doc-blocks within the API.

Now, before we move on to discuss the big new features, let me give you some background.

Functional programming languages light my fire

I love functional programming languages. Nephtali’s design principles clearly trace their roots to my experience with functional languages such as LISP, Haskell, Erlang, and others. While PHP is obviously not a functional programming language, through the Nephtali framework I’ve sought to embrace general functional programming principles such as immutability, laziness through use of a registration model, and using arrays for everything under the sun.

One of my favorite aspects of functional languages is the value placed in keeping functions “pure.” You can read what Wikipedia says about pure functions if you’re not familiar with them, but in short, a pure function will produce the same output for a given set of arguments every time the function is called because no other state is brought into or altered by the function. Pure functions are easier to reason about in terms of correctness, easier to test, and probably even increase life expectancy

Some of you who are coming from functional languages are now saying to yourselves, “Yes, these principles of functional programming languages are great, but what could this possibly have to do with the syntactically challenged language PHP?”

I built a framework for PHP because of practical reasons. I develop websites for a living and my clients don’t care what language I’m using, they just want an effective, reasonably priced, maintainable website. PHP is a very practical language choice in light of these considerations. And, through Nephtali, I’ve been able to simulate some of the functional programming features I’ve missed the most. Now, back to the discussion of pure functions in Nephtali.

Nephtali 3.3 will promote pure pipe functions

While I can’t force particular functions to be pure in PHP, I can try and promote pure functions through the features and conventions in Nephtali, and Nephali 3.3 provides you with some handy features that facilitate keeping a lexically-pure pipe function. Let’s work through an example contrasting the code of an old-style Nephtali action pipe (I must stress Nephtali 3.3 is fully backwards compatible with this style) with the newer, pure-promoting style.

Old-style action pipe

Code block

n\port\register(
    $name = 'id',
    $opts = array(
        'max_length' => 10
    )
);
n\port\register(
    $name = 'company_name',
    $opts = array(
        'max_length' => 50,
        'filter' => n\constant\FILTER_TEXT
    )
);
n\port\register(
    $name = 'description',
    $opts = array(
        'max_length' => 500,
        'filter' => n\constant\FILTER_TEXT_MULTILINE
    )
);
n\port\register(
    $name = 'url',
    $opts = array(
        'max_length' => 200,
        'filter' => n\constant\FILTER_URL
    )
);
n\port\register(
    $name = 'did',
    $opts = array(
        'max_length' => 10,
    )
);
n\val($name = 'update_host', $value = array('id','company_name','description','url'));
n\val($name = 'insert_host', $value = array('company_name','description','url'));
n\val($name = 'delete_host', $value = array('did'));
n\pipe\register_action(
    $name = 'host',
    $actions = array(
        n\port\signature(n\val('update_host')) => function($markup)
        {
            if ($rows = n\port\validate(n\val('update_host')))
            {
                return n\view\render($view = 'feedback', $markup, $rows);
            }
 
            n\sql\action\update($table_name = 'hosts', $inputs = n\port\get(n\val('update_host')));
            return n\view\render($view = 'default', $markup, $rows = array(array('message' => "We've updated the host")));
         },
        n\port\signature(n\val('insert_host')) => function($markup)
        {
            if ($rows = n\port\validate(n\val('insert_host')))
            {
                return n\view\render($view = 'feedback', $markup, $rows);
            }
 
            n\sql\action\insert($table_name = 'hosts', $inputs = n\port\get(n\val('insert_host')));
            return n\view\render($view = 'default', $markup, $rows = array(array('message' => "We've added the host")));
         },
        n\port\signature(n\val('delete_host')) => function($markup)
        {
            if ($rows = n\port\validate(n\val('delete_host')))
            {
                return n\view\render($view = 'feedback', $markup, $rows);
            }
 
            n\sql\action\delete($table_name = 'hosts', $id = n\port\get('did'));
            return n\view\render($view = 'default', $markup, $rows = array(array('message' => "We've deleted the host")));
         }
    )
);

I won’t talk much about this example as most Nephtali users are familiar with this approach. However, let me just point out the amount of work it takes to either mentally work through correctness of the code OR write unit tests for it.

New pure-promoting pipe

Code block

n\port\register_bulk(
	$ports = array(
		'id' => array(
			'max_length' => 10
		),
		'company_name' => array(
			'max_length' => 50,
			'filter' => n\constant\FILTER_TEXT
		),
		'description' => array(
			'max_length' => 500,
			'filter' => n\constant\FILTER_TEXT_MULTILINE
		),
		'url' => array(
			'max_length' => 200,
			'filter' => n\constant\FILTER_URL
		),
		'did' => array(
			'max_length' => 10,
		)
	)
);
n\pipe\register(
    $name = 'host',
    $function = function($markup, $args, $signatures)
	{
		if ($signatures['update']['is_valid']) {
			if ($signatures['update']['errors']) {
				return n\view\render($view = 'feedback', $markup, $signatures['update']['errors']);
			} else {
				if ($args['update']) {
					return n\view\render($view = 'default', $markup, $rows = array('message' => "We've updated the host"));
				} else {
					return n\view\render($view = 'error', $markup);
				}
			}
		} else
		if ($signatures['insert']['is_valid']) {
			if ($signatures['insert']['errors']) {
				return n\view\render($view = 'feedback', $markup, $signatures['insert']['errors']);
			} else {
				if ($args['insert']) {
					return n\view\render($view = 'default', $markup, $rows = array('message' => "We've inserted the host"));
				} else {
					return n\view\render($view = 'error', $markup);
				}
			}
		} else
		if ($signatures['delete']['is_valid']) {
			if ($signatures['delete']['errors']) {
				return n\view\render($view = 'feedback', $markup, $signatures['delete']['errors']);
			} else {
				if ($args['delete']) {
					return n\view\render($view = 'default', $markup, $rows = array('message' => "We've deleted the host"));
				} else {
					return n\view\render($view = 'error', $markup);
				}
			}
		} else {
			return '';
		}
    },
	$opts = array(
		'signatures' => array(
			'update' => array('id','company_name','description','url'),
			'insert' => array('company_name','description','url'),
			'delete' => array('did')
		)
	),
	$args = array(
		'update' => function($signatures) {
			try {
				return n\sql\action\update($table_name = 'hosts', $inputs = $signatures['update']['values']);
			} catch (Exception $e) {
				return false;
			}
		},
		'insert' => function($signatures) {
			try {
				return n\sql\action\insert($table_name = 'hosts', $inputs = $signatures['insert']['values']);
			} catch (Exception $e) {
				return false;
			}
		},
		'delete' => function($signatures) {
			try {
				return n\sql\action\delete($table_name = 'hosts', $id = $signatures['delete']['values']['did']);
			} catch (Exception $e) {
				return false;
			}
		}
	)
);

In the new style, the pipe function is structured so that you can quite easily reason about the flow AND write unit tests for it. No contrived mock objects, no IO gotchas, just pass in the arguments representing the states you want to test and voila, you’ve got a test (mind you, if you haven’t carefully reasoned the correctness of your code, your test will suck, but I know you like seeing pretty green lights, so…)

The “how” behind the above code owes much to the magic of the $args argument. While it looks like an array, it’s actually an object that implements the appropriate interfaces so it can be accessed like an array, keeping consistent with Nephtali’s M.O. in that regard. It stores the functions and only processes a function once you try to access the value. However, any further access to the variable makes use of a cached value result, so you don’t have to worry about calling an insert function more than once by accessing the value later on in your code, for example.

The beauty in the $args argument is that it encourages you to keep as much logic as possible in the easily tested pipe function. Only pull out the basic state-accessing/changing operations into the $args functions, and you’ll have code that’s easier to reason about and to test.

Coming soon, to a server near you…

P.S. – You can obviously refactor the new pure-promoting style so it is much shorter, as I’ve done below (and, indeed, it could even be shorter, but this gives you just a quick idea), but I didn’t include this in the body of the article out of fear that it’s harder to conceptually work through what’s going on in terms of the new features.

Code block

$function = function($markup, $args, $signatures)
	{
		$valid_sig_processor = function($signature, $arg, $message) {
			if ($signature['errors']) {
				return n\view\render($view = 'feedback', $markup, $signature['errors']);
			} else {
				if ($arg) {
					return n\view\render($view = 'default', $markup, $rows = array('message' => $message));
				} else {
					return n\view\render($view = 'error', $markup);
				}
			}
		};
 
		if ($signatures['update']['is_valid']) {
			return $valid_sig_processor($signatures['update'], $args['update'], "We've updated the host.");
		} else
		if ($signatures['insert']['is_valid']) {
			return $valid_sig_processor($signatures['insert'], $args['insert'], "We've inserted the host.");
		} else
		if ($signatures['delete']['is_valid']) {
			return $valid_sig_processor($signatures['delete'], $args['delete'], "We've deleted the host.");
		} else {
			return '';
		}
    }

With the formal apology now issued, let’s move on to the update: I’ve now documented Nephtali’s debugging features in the examples section of the website.

The primary debugging feature is the debug display, a special page that can be triggered by adding the Get variable “nmode=debug” to any url when Nephtali has been set to “dev” mode in ncore.php. The debug display shows the Get, Post, Cookie, and Session variables; the ports and their corresponding values and validity; and watched variables, variables that have been manually added to the debug display.

Again, the debugging features are very simple, but don’t let the simplicity lull you into avoiding them. Nephtali is not a large, complex framework. Many times the bugs you’ve run up against are easily spotted in the debugging display.

Page-by-page config mode

You can now easily change the configuration mode used for a page without having to change the whole site. For instance, if you’d like to put one page in ‘dev’ mode and keep the rest of the site in ‘prod’ mode, you’d just add the following snippet of PHP to the top of your markup file:

Code block

<?php $nephtali_config_mode = 'dev'; ?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

To avoid potential security issues, you must specifically  enable this feature by opening nconfig.php and adding a fifth argument to n\config\save():

Code block

n\config\save(
$mode = 'dev',
$dev = array(
// settings
),
$test = array(
// settings
),
$prod = array(
// settings
),
$allow_page_overrides = TRUE
);

Added support in n\sql\action\* functions for PostgresSQL lastInsertId

PostgreSQL’s use of sequences requires the name of the sequence object in the name parameter of PDO->lastInsertId() calls. To accommodate this in Nephtali, an optional last_insert_id_name parameter has been added to the following functions within the n\sql\action namespace:

• query($query, array $inputs, $dbh = null, $last_insert_id_name = null)
• insert($table_name, array $inputs, $dbh = null, $last_insert_id_name = null)
• save($table_name, array $inputs, $dbh = null, $last_insert_id_name = null)

Viewing debug output vs. automatic error handling

You can no longer control on a pipe-by-pipe basis whether an uncaught exception within a pipe function is automatically handled or not (you used to have to add ‘auto_error_handling’ => false to the $opts array for a pipe.) Going forward, the mode for the current request determines whether uncaught exceptions are automatically handled (i.e., the required ‘error’ view is shown) or the debug output is displayed. These changes are meant to simplify the development process and help Nephtali’s default configuration come inline with developers’ expectations.

The settings for the modes are as follow:

• dev – Show debug output.
• test – Automatically catch exceptions and display error view.
• prod – Automatically catch exceptions and display error view.

Improved feedback

Nephtali now checks for typos in $opts array keys supplied to n\port\register() calls. This change avoids issues where a misspelled key silently has no impact on the port validation, a significant source of confusion for the developer who thought they had properly set up the port. The checks for typos only occur in ‘dev’ mode (this helps keep ‘prod’ mode fast as can be), and Nephtali will even recommend the associative key you meant to keep going by the closest valid spelling match.

Additionally, when one accidentally tries to change the value of an immutable n\val(), the error feedback has been improved.

Bug fixes and improved documentation

The n\arr\format() function has now been fixed so-as to properly return array values that don’t have any formatting functions applied to them. A big thanks goes out to Davin Granroth for reporting the issue.

Additionally, the documentation for several of Nephtali’s functions has improved significantly. Let me know if you see any issues.

Let’s briefly contrast the CakePHP, Yii, Kohana, Symfony, and Zend PHP Frameworks with Nephtali.

Design Principles: Don’t hide complexity, strive for simplicity

Just enough is more

Nephtali’s core API fits within one file and the current download is 35 KB (smaller than many jpegs.) The downloads for the frameworks we’re contrasting Nephtali with range from around one to 6.6 MB.  Now, to a degree, this difference in size does speak to the difference in power out-of-the-box for developers. However, Nephtali has very different goals and design principles than the other frameworks.

Throughout the development of Nephtali, the core components of the vast majority of web applications were carefully debated and prioritized. Only features deemed essential and/or especially error prone were included in the framework.

Nephtali is a framework you can learn to use in a weekend, and it will provide you with a simple, solid foundation for any web application.  In contrast, the other frameworks are very powerful PHP ecosystems that can cater to your every whim, and although you can gain competency for basic tasks over a weekend, you’ll likely need much more time to truly learn them.

Now, please don’t assume that I’m saying I don’t like the frameworks I’m contrasting Nephtali with because they’re too big. On the contrary, I rather like and frequently use several of them.  I tend to use Nephtali for my core needs, and then if I need some OAuth or SMTP capabilities, I’ll just leverage Zend Framework’s powerful API’s for my particular need (yes, Nephtali plays nicely with your other framework friends.)

Functionally inspired

The frameworks contrasted with Nephtali in this article are all built using object-oriented programming principles. In contrast, Nephtali takes its cues from functional programming.

Now, some of you may be thinking, “Hey, PHP isn’t a functional programming langauge.”  You’re right. However, some of the new capabilities included in PHP 5.3 (anonymous functions, closures, namespaces) provide just enough power for Nephtali’s novel approach. Specifically, Nephtali doesn’t contain any classes, tries to avoid mutable variables, and makes heavy use of anonymous functions.

Why the functional emphasis? In my experience, functional programming has proven to be easy to test, easy to debug, and it affords great parsimony (one of the main reasons Nephtali can do so much with so little code.)

Security is not an add-on

Security plays a significant role in every step of Nephtali’s design process. Specifically, the SANS Top 25 list of the most dangerous software errors served as a guide for general security issues that should be addressed in every web application, including:

• Failure to preserve web-page structure (e.g., XSS)
  Nephtali provides automatic, powerful output escaping, and this is paired with powerful, simple input validation.
• Failure to preserve SQL structure (e.g., SQL injection)
  Nephtali makes prepared statements easy and more fun than an amusement park.
• Information exposure through error messages
  Nephtali makes appropriate error displays for production pages a requirement.
• Unrestricted upload of file with dangerous type
  Nephtali’s input validation includes checks for file names and size.
• Missing encryption of sensitive data
  Nephtali includes simple encryption functions.

Now, is it fair to say that this emphasis on security stands in stark contrast to the other frameworks in this post? No. However, as Bruce Schneier has noted, “…complexity is the worst enemy of security” and it is fair to say that Nephtali has embraced simplicity to a degree that surpasses the other frameworks.

Architecture: Not a typical PHP MVC

Dynamic region controllers (pipes)

All of the other frameworks listed here are standard MVC-architectured applications. In terms of the controller, you either find a front controller (controls which view is displayed application-wide) or a page controller (controls which view is displayed for a particular page.)

Nephtali ushers in a new level of granularity with it’s controllers. Instead of a front or page controller, Nephtali provides controllers that manage views within dynamic content regions of pages (pipes.)  Essentially, a pipe is a controller that determines which view of the dynamic region to display and then handles any required databinding. A page can contain multiple pipes that all act independently on the page.

No ORM

The other PHP frameworks offer powerful Object Relational Mappers (ORMs) that abstract away much of the work of persisting objects in databases. However, as already noted, Nephtali borrows significantly from functional programming, so you’ll see no ORM (although you could use a third party library.)

PHP offers a fantastic data-access abstraction layer, PDO, and Nephtali merely provides some convenient wrapper functions for PDO’s API. The result is simple, fast, clean code that can easily be refactored as your project grows. Need to work with multiple databases? No problem. Need to optimize your complex queries? No problem.

PHP-free markup

The convention in the cother PHP frameworks is to embed PHP directly within the markup of the pages to display the dynamic output. In contrast, Nephtali cleanly separates PHP from your HTML.  If you have a page that contains a dynamic region (e.g., a list of recent blog titles), you merely embed xml comments within your markup to let Nephtali know where the region is.  All of your PHP is contained within a code-behind file.

Nephtali’s approach provides several benefits. Designers, front-end developers, and UX professionals can easily manage the markup and directory structure, and prototypes can easily flow into working websites. Output escaping is automatically handled, and for speed, the context of the escaping can be explicitly declared (e.g., html, attribute, uri.) Nephtali can be installed on existing sites without breaking legacy PHP code.

Closing thoughts

Nephtali is not for everyone. If you’re an object oriented programmer at heart, then you won’t be satisfied working with Nephtali. If you’re looking for an extensive web framework with an API that covers a veritable treasure trove of powerful PHP code that can do everything from creating PDF’s to generating figlets, then Nephtali will come up short. If you’re looking for a well-backed, popular web framework, then Nephtali will appear to be the odd-one-out.

However, if you’re looking for a simple, powerful tool that helps you get the core features of your web applications right, then maybe Nephtali is just the web framework for you.

The parser is currently being used to generate Nephtali’s API documentation, and so far it appears acceptable.  Now, upfront, let me assert the following:

1. I’m not a great (or even average) parser writer.  Some might even label my skills poor or non-existant.
2. Nephtali’s core API only makes use of namespaced contants and functions, so I didn’t have to add handling for classes (although I did carve out some space for their future implementation.)  For instance, it’s so specialized now that the only namespaces it recognizes are block namespaces (as is used in ncore.php.)
3. I did this in a few days after being fed up, not after careful deliberation throughout a well conceived design process.

You just hand the nlib\doc_generator\start_parsing() some string code and a nlib\doc_generator\DocNode object, and the object will be filled up with the available namespaces. Each namespace will contain its corresponding constant and function objects.  Each function will posess a nlib\doc_generator\Doc object, which contains all of the appropriate doc block properties.  Again, very, very primitive.

Currently, the parser and dev tools are included with the Nephtali download in the nlib/doc_generator directory, although I’ll eventually pull this out into its own project.

So, if any of you have feedback, let me know.

There are other edits, including a couple bugs and the change from constants to strings for triggering the appropriate mode for databinding (“placeholder” or “form”.)

Additionally, you’ll see that theres a doc_generator directory in nlib that includes the parser used to generate the object model for the Nephtali API documentation.  This will likely be split off into a separate project in the future, but for now, we’ll just keep it with core Nephtali.

Please post any issues you find.