It is mandatory to develop these actions for further usage.

It should include the possibility of creating an account and also properly connect and disconnect from the website.

Do we restrained login to only an email ?
It's more and more often that login is an email, because it's easier to deal with.

But i would like to know your point of view.

I'm working on a simple and light system which allow to manipulate forms easily. By "easily", I mean without get POST and GET data and analyze them by ourselves. I think most of the analysis on data can be automatic.

Then I thought about different systems but I'm not able to make a choice.

First

The first method consists to create an Map<key : String, rules : Array<String>> with the name of the field as key and their requirements as rules. This Map is then injected into an object which get the data in POST and/or GET variable and process them (before finally returning them).

Example:

var form_data = new Map<String, Array<String>>();
form_data.set("user_name", [Required, MinLength(4), MaxLength(32)]);
form_data.set("user_mail", [Required, MinLength(7), MaxLength(225)]);

var checker =  new WebDataChecker();
checker.setMethod(POST);
checker.setForm(form_data);
if (checker.isValid() == false)
{
  checker.getError();
}
else
{
  checker.getData();
}

This technique is quite static and doesn't need evaluation during runtime. So it make it probably efficient at runtime.

Second

The second technique consists to create an object which reflect the form data. All the member variables are tagged with their requirements. This object is pass as type parameter to an object which get the member variable and their associated tags. This object get the POST and GET variables, fills the form object and process the analysis according to the tags (before finally returning the form object).

Example:

class MyForm
{
  @Required
  @MinLength(4)
  @MaxLength(32)
  public var user_name : String;

  @Required
  @MinLength(7)
  @MaxLength(255)
  public var user_mail : String;
}

//...

var checker =  new WebDataChecker<MyForm>();
checker.setMethod(POST);
if (checker.isValid() == false)
{
  checker.getError();
}
else
{
  checker.getData();
}

This technique implies using the haxe.rtti.Meta API and so evaluation at runtime and then probably less efficient than the first method. However, modeling the form into an object could be clearer and sexier than the first method.

There probably are several other methods but here are the one I thought about.

Any statement, idea, advice ?

Include mcover to munit.

https://github.com/massiveinteractive/MassiveCover

When you try to apply:

haxelib convertxml beluga.xml

It yells:

No `haxelib.xml` file was found in the current directory.

So, it seems that we no loanger cannot specify a custom filename.

Moreover, when you rename beluga.xml to haxelib.xml. It returns:

bad nodeType

Then, it's impossible to install Beluga .

https://github.com/HaxeBeluga/Beluga/blob/master/beluga/core/WebDispatcher.hx

The WebDispatcher is more like a TriggerEmmiter.

So it must be renamed, and we should move the redirect function in something like "WebUtils" class.

Like said in the title, the user model for the database in account module isn't finished.

If you try to edit the config.xml file after compilation (the one used by haxe.Resource).

The following will be ignored

• Include (That means that you will not be able to edit triggers for instance)
• Modules (You can't add or remove modules this way)

I sadly think that there is no issues concerning modules since it is all macro related.

However, we should add every config files included inside resources so it would be possible to edit both included files and which files should be included or not after compilation.

Do not confuse the actual Beluga Webdispatcher and the haxe standard library WebDispatcher
Here i'm talking abount haxe standard library WebDispatcher.

Beluga must provide APIs.

A main Beluga API, and on for each module.
API will handle all the web part of beluga, and make call to the application par of beluga using trigger.

Then We will don't need the "run" function anymore.
https://github.com/HaxeBeluga/Beluga/blob/master/beluga/core/Beluga.hx#L82-L85
It will be replaced by something like:
haxeWebDispatcher.run(Web.getURI(), Web.getParams(), Beluga.getApi());
in BelugaDemo

each final function of an API will proceed this way:
-Some verification / convertion of web parameter
-Emmit trigger
-Depending on the trigger result (Login fail/ login success) the api redirect on the appropriate page.

Create the language system using this exemple:
http://haxe.org/api/haxe/xml/proxy/examples/localisation

Actually, you have to instantiate a Beluga object to deal with the library.

This means that you can have multiple Beluga instance in your project and also that you have to keep track of each of your instances.

I would prefer to set Beluga object as a Singleton since it is not necessary to instantiate multiple beluga object and it is more convenient to use since you will no longer have to keep track of your instances.

What do you think ?

Installation isn't correct.

If could write something like:
TriggerDispatcher.dispatch("montrigger", {
param1:"value1",
param2:"value2"
});

It would be great !

It could be great to avoid duplication of the functions inside the module. It has been done to not make static all the framework, however it's really bothersome.

Beluga API must be auto generated via macro according to the builded modules

It is important, in order to develop deeper the project, to discuss about the use of templo, and how will widgets work.

Templo ?

First of all, should we still use templo ? I don't think so.

The main problem is that if user of Beluga wants to use templo on its own, he will be forced to respect our templo usage. I mean that he will have to put all his template inside the same directory as us and so on. Furthermore, it means that we can't have templates in multiple folders.

The main reason for this is that Templo actually need some initialization variable to work and once it is set up, the behavior when you edit them is not specified.

I think we should render our template using Haxe native template system for a compatibility purpose.

Widgets

The other question is about Widget conception. In order to avoid long explanation, here is a piece of code that would show how does it works.

var acc = beluga.getModuleInstance(Account, ""); //Retrieve Account module
var loginBox : Widget = acc.getWidget("login"); //Generic method for all modules
loginBox.context.username = "Toto"; // For instance, it would fill the username field with Toto
var html : String = loginBox.render();

The main configuration file is included in resources so it remains editable and accessible after compilation.

However, few changes would be taken into account such as triggers. But not modules inlude for example.

The main reason for that is that some part of the config file is parsed inside macro and some other outside. Should we let this file accessible through resources ?

Please note that it is impossible to remove the macro part because some features would not be replaceables.

Also, includes files are not kept, they can easily be added to resources however

We must fix the version of:
apache
php
mysql
maybe postgres ?

I think that the trigger system should be enough abstract from beluga to be in an external library.

for this beluga.xml must be splitted in 2 parts: database.xml trigger.xml

TriggerDispatcher.redirect function must be moved out of the class.

and certainly many other things i didn't noticed yet.

I think this will help to solve the issue #55

Every modules should give a default api to be ready to use.

It should let the user using a default page when dispatching

Example of usage:

class CustomDispatcherApi
{
    function doForum(d:Dispatch) {
        d.run(Beluga.getInstance("forum").getDispatcherApi());
    }
}

In this case, the user of Beluga can have a ready to use forum to work with, he will be able to override the default forum by its own simply by removing this line.

We need to list every validation rules to implement so here we go with some

Bold ones are implemented
Italic ones are under development
Normal ones are none of above
Strikeout ones are abandonned

• Required: The field value must not be empty
• Min(x): The field value must be above or equal to x
• Max(x): The field value must be below or equal to x
• Match(pattern): The field value must match the given pattern
• Equal(field): The field must be equal to another field
• Database(table, field): The field must match at least one value in database considered given table and field
• EqualTo(value): The field must be equal to the given value
• Date(format): The field must correspond to the given format
  • Must decide how to describe the format
  • May be obsolete with Match(pattern)
• Number: The field must be a number
• Alpha: The field must be composed by alpha characters only
• AlphaNumber: The field must be composed by alpha and numbers only
• Range(x, y): Shortcut for Min(x) and Max(y)
• Alter(function): The field will be altered by given function
  • The original value will be lost !
  • This rule always return true
• Email: The field must correspond to the standard mail format
  • May be obsolete with Match(pattern)
• MinLength(x): The field must be at least x characters length
• MaxLength(x): The field must be at most x characters length
• EqualLength(x): The field must be exactly x characters length

I will keep edit this issue until we are done implementing those

Handle exceptions where it is needed

Make an html page with:

• 1 Javascript file
• 1 CSS file
• several widget

All of this to see what a complete html page looks like in term of class architecture, folder archiecture etc...

It may be the subscribe page to then create the subscribe action as an example.

Inside resources, template extension is not kept

it would be good to add and use template resources as beluga_FILENAME.mtt to better recognize resources.

http://haxe.org/manual/documentation

Make an exemple of generated doc

Because we are always talking about widget I don't understand why in config.xml the tag is "template".

Here is a tool we should implement for unit testing

Use metadata to configure trigger with something like:

@bindTrigger("triggerName")
function static triggered() {
}

Hi guys!

Is Beluga runnable with neko target?
(I can see that beluga.core.Beluga.hx depends on php.Web)

/ Jonas

It's too messy. We need to clarify a lot more how the repository is architectured.

Every configuration files should be stored using haxe.Resource.

It would let the developer to edit them after compilation process.

Also, it's important to let the folder "res" inside "bin" clean. (i.e: Try to create some folders)

When i compile BelugaApi there is no function generated in the associated .php file
I suppose it's because the BelugaApiBuilder is executed before the configs are loaded.

Managing different languages into a framework is a worthwhile functionality. Then, we thought creating a module for it. However, according to our architecture, all the modules are going to inherit from this language module. So, it's no longer relevant to define it as a module but a internal functionality.

Add a base url in config file.

This means every widgets have to concatenate this variable to their url to ensure the most flexibility

Macro?

cf. #52

Module Api dispatch trigger thanks to Beluga and Api are instanciated in Module, that's why all modules needs Beluga instance at construction.

For the time being we can only bind trigger to static function, if we want to bind trigger to instance we have to configure binding inside haxe code with something like:

Beluga.bind("login", monobject, "function_name");

After a lot of reflexion a didn't find better way.

Covers everything to set up a project

• Installing Beluga
• Set up a new project
• Configure .htaccess

Can you try to create a github.io webstite that is synchronise with belugaDemo repoitory. It would be so cool/kikoo.

@Masadow I reinstall haxe on my computer because of the previous Process.hx error.
Then I got an error I never had before

/home/abrissard/epitech/Eip/BelugaGit/Beluga/beluga/core/module/ModuleBuilder.hx:72: characters 22-38 : String should be haxe.macro.TypePath
/home/abrissard/epitech/Eip/BelugaGit/Beluga/beluga/core/module/ModuleBuilder.hx:72: characters 22-38 : String should be { ?sub : Null, ?params : Array<haxe.macro.TypeParam>, pack : Array, name : String }
/home/abrissard/epitech/Eip/BelugaGit/Beluga/beluga/core/module/ModuleBuilder.hx:72: characters 22-38 : String has no field name
/home/abrissard/epitech/Eip/BelugaGit/Beluga/beluga/core/module/ModuleBuilder.hx:72: characters 22-38 : For function argument 't'
/home/abrissard/epitech/Eip/BelugaGit/Beluga/beluga/core/module/ModuleImpl.hx:14: characters 2-11 : Build failure
/home/abrissard/epitech/Eip/BelugaGit/Beluga/beluga/core/Beluga.hx:19: lines 19-97 : Defined in this class

I changed https://github.com/HaxeBeluga/Beluga/blob/master/beluga/core/module/ModuleBuilder.hx#L721 classname to clazzTypePath and now it compile, but I don't know if it was the rigth ting to do, is it ?

The normal behavior of BelugaException should return file + line + exception_message inside toString() method.

However, since CallStack.callStack() always returns an empty array, we can't locate where the problem happened.

I first thought that the code in toString() method was misplaced and should be inside the constructor. However, the CallStack.callStack() method still returns an empty array.

Maybe some macro tricks are needed but I didn't look deeper actually.