jack12816 / greppy Goto Github PK

The MongoDB adapter should use the mongodb node driver for the plain connection.
The ORM should be mongoose.

The backend adapter needs to be build like MySQL backend adapter.
An documentation with examples needs to be written.

Missing commands are:

• start
• stop
• status

The binary should be able to find the starting scripts
and to find the process names by these scripts.

We have to take a closer look at Ruby on Rails to find
a good concept of doing such stuff.

Best way seems to write the master pid to a file under
var/ to be able to stop and status the current application.

The greppy binary should be able to do some asset management tasks.
One task would be to install (link up) all assets of all modules into /public.

As a further implementation a task could execute all necessary steps to compile
all assets (minify, compression, etc).

Currently the new project command is creating the application
structure and some initial files like package.json, README.md
and CHANGELOG.md.

All big frameworks, like Rails, generate some sample applications
for the user. These showing some details, link to docs and will
proof the application can be started and works fine.

The same would be nice for Greppy.

The first dependency for this feature is the ability to
build a default CLI for the worker and master implementation.
This should be done with node-getopt, like in the greppy binary.

A good starting point would be a worker switch which names
the concrete worker implementation for both worker and master
scripts.

Concrete worker implementations name the modules to load
and further details for the worker context.

This enhancement is a dependency for file-based logging
out of the box and for proper cluster-slave statistics.

Currently the greppy binary dont write a PID file for a single context
started with --debug. This should be implemented.

An concept for the authentification eco-system should be designed.
An initial idea is to split the system into two parts:

• Auth Adapters (like Basic HTTP Auth, Form Auth, SSO)
• Auth Sources/Handlers (LDAP, Array, HTAccess, OAuth)

So you can put an adapter config into the worker context
and use it later on an per-controller basis. So you can have multiple
sources and adapters configured.

An common interface needs to be designed for both, sources and
adapters.

At this point we should think of an project specific .greppyrc file.
The client needs an point to configure settings for the Greppy scaffolding
solution. So he can define:

• Location of his templates (like views)
• Definition of his header sections (doc-blocks)

The concept needs an idea where to put such client-side files,
what to generate and how detailed this can be.

An basic idea for better scaffolding could be:

Generation of models+migrations+fixtures
Ask the user for:

• Name
• Backend/Connection
• Properties [Name and Type] <-- as a loop which can be ended by the user
• Indexes [Name, Properties, Type] <-- same as above

So the generator can generate a full-featured implementation.
With ready to use requisites. The fixtures can fill in data which matches
to the defined types of the properties and so on.

Generation of CRUD controllers
Ask the user for:

• Name
• Module
• Model (Backend+Connection based)
• Soft-Deletion

The generator could build an implementation which matches perfectly
on the choosen model. So all forms can be filled with the properties
even by datatype (input for string, textarea for text) and the controller
could even handle them by default generation.

Just add ideas and some conceptual stuff.

The DB store should take a configuration with all backends and their
connections. A configure(select, callback) method provides a way
to establish all connections with the option to select only a backend
or a connection of the backend.

This is usefull for the worker context configuration. With the help of
this feature we can have contexts which does not use any kind of
backend, or only one of more configured backends.

A Connection class should be the interface for our supported backend
adapters. The following methods should be implemented:

• contructor(name, backend, config)
• configure(callback)
• close(callback)
• getORM(callback)

The DB store should have these methods:

• configure(callback)
• close(callback)
• get(namepath)

Any kind of backend adapters should implement these methods:

• constructor(name, config)
• configure(callback)
• close(callback)

To build a good framework we need
to publish a great API documentation for our software.
All components of the framework will be inline-documented
with JSDocs so we can automatically build the docs.

The maintenance binary currently supports generation of the
framework documentation out of markdown files with
the --generate-docs switch.

To generate the API docs a --generate-api-docs switch
would be nice.

For evaluation which is the best JSDoc parser and doc-writer
we have to search and try some. Then we can build this command
upon the choosen parser/doc-writer and everything will be easier.

Translate the documentation which is written in markdown
to english as a good starting point for further documentation.

These sections needs updates:

• Helper System (new store-based implementation)
• Binaries (not yet implemented, greppy binary mostly)
• Structure (needs cleanups)

Undocumented components:

• Single- and Multithreading (IPC, ICC, Worker, Master) by examples
• Config-Store, Config
• Generic Stores
• Extensions, Data-Types

The following code examples needs updates:

• MVC - Controller, Actions, Options
• dbReg (aka new db-Store, which is not yet implemented)
• Helpers (aka new helper-Store)

If you start an context the following way:

greppy --start admin --debug

The worker/master is spawned in front of the current process and inherits
the stdin from its parent. But most of time you could not shut down the process
with ctrl+c. Sometimes it works, but its not clear why it wont work.

We have to find this bug and a solution for it.

The --db switch should extend the functionality of the greppy binary.
The switch should behave this way:

Without any operation)
Show information about the db setup on the cwd-project:

• List configured backend adapters (connections: name, host, db)

Atomar Operations

Requirement: All adapters needs additional methods to do
the requested operation steps.

create [adapter.connection]
Create all|the given connection backend based on the specified adapter.

drop [adapter.connection]
Drop all|the given connection(s) backend based on the specified adapter.

migrate [adapter.connection]
Run migrations for all|the given connection(s).

fill [adapter.connection]
Fill all|the given connection(s) with its fixture data.

Combined Operations

build [adapter.connection]
Run these operation for all|the given connection(s):

• create
• migrate
• fill

rebuild [adapter.connection]
Run these operation for all|the given connection(s):

• drop
• create
• migrate
• fill

The MVC loader should be extended with the help of the Path helper to support
the loading of controller hierarchies of a module.

A controller user.js which is placed at controllers/admin/ which got an action new should be routed as: /admin/users/new.

So the hierarchy path should be the prefix of the route. If the controller defines
a path within the controller options than these options are higher rated and will be used.

A simple example for the Path helper:

var pathHelper = new (require('../../helper/path'))();
var controllersPath = path.normalize(...);

pathHelper.list(controllersPath).forEach(function(controllerPath) {

    if (!controllerPath.match(/\.js$/i)) {
        return;
    }

    ...
});

Creating a new application in greppy 0.4.0 by using
greppy --new App_Name
doesn't create the folders "var/run" and "var/log" in the application-folder. They have to be created manually or greppy won't start correctly.
Folder "app/config" and the file ""app/config/application.js" are stil not created.

The db namespace should be able to drop all tables of a given connection.
With the current toolset we are able to:

drop [adapter.connection ...]
    Drop all|the given connection(s) backend based on the specified adapter.

clear [adapter.connection ...]
    Clear data from all|the given connection(s).

A purge operation which removes all tables for a connection should be implemented for all backend adapters.

This is a good chance to clean up this stuff and to outsource some functionality
into separate helpers. Many of this could be used for scaffolding and all other
framework parts which handles Greppy application paths.

With this refactoring we can implement a recursive Greppy project search
helper so we can start the application even from a module while we edit it.
Another opportunity is the .greppyrc file.

Just rewrite the existing uniq method to better fit our needs:

• User can pass an self-defined function as an strategy
• Default implementation should work by stringifying all entries and sort them unique

The API should look like this:

Array.prototype.uniq = function([uniqFunction]){}

As an optional feature we can provide some basic variants of the
unique implementation under a namespace in Array.

Array.uniq.numbers = function(){}
Array.uniq.objects = function(){}