From @FrancisBourre on August 14, 2016 8:1

This is long task, and it has few sub tasks.
The final goal is to reduce the final compiled file size and for doing it we should remove all the unnecessary class dependencies.

I started today by removing all the classes used at compile-time (cf: XmlCompiler)
You can check the commit here

I made a first test, and it's not bad for a 1st iteration. As you can see, it removed around 1500 lines from the final file.
This task should be continued.

The next sub-task (it can be parallel) is a bit trickier. The idea is to make modifications in the framework source code to use the compiler in full DCE. As you can imagine, the main problems are based on injection systems. I got some ideas about how doing it. We could use macros to decide which classes should be compiled or not depending of the architecture of the application.

Copied from original issue: DoclerLabs/hexIoC#5

From @FrancisBourre on August 9, 2016 12:38

AnnotationDataProvider class doesn't use anymore class reference (as metadata name) to deserialize JSON for building injector's value objects.
These value objects are already instantiated @Compile-Time and are retrieved from static property.

var field : InjectorClassVO = Reflect.getProperty( type, "__INJECTION_DATA" );

AnnotationDataProvider (and its dependencies) should be refactored to remove class reference from the constructor.

See code here

Copied from original issue: DoclerLabs/hexInject#1

So, saw the title of your talk in the WWX2016 official mkt site, and couldn't help but Google :)

Would you mind sharing a bit about this framework? Is it a web framework?

Cheers!

Each module has its own AnnotationProvider instance. It can define its providers rules but cannot inherit from top-level/context rules.

So you have to redefine everytime for each module the same rules.
We should introduce a system base on domain inheritance that will allow children domains to get parent rules when they don't have one. It's important as well that they can override at any tine any rule already defined from their parents.

static public function getAnnotationProvider( ?domain : Domain, ?parentDomain : Domain ) : IAnnotationProvider

The tricky part of this implementation is (as you know maybe) provider rules can be defined after instances parsing. It means that inheritance and overriding should take care of these cases in the inherutance chain.

From @FrancisBourre on August 22, 2016 14:2

Lastly, we removed the json serializer/deserializer for setting/getting reflection data from future injected classes, and we gain some significant speed.

There's a last step left to transform our injector in a formula1. We should remove the useless transformation from InjectorClassVO to ClassDescription at runtime (with all the processes/calculations to build sub value objects hierarchy: ConstructorInjectionVO instance, PropertyInjectionVO instances, MethodInjectionVO instances and OrderedInjectionVO instances with all ArgumentInjectionVO instances). This could be handled directly by a macro at compile time.

To achieve that, we need to transform all the value object classes to typedef and extract all the behaviors (that apply injections) to functional static methods with inlining. It's a big/long refactoring, but it's a very valuable one, because it means there won't be anymore the process described above for building reflection data during the 1st access. It will be ready to use directly. And no need to cache anymore as well, because this cache will be directly built at compile time...

Copied from original issue: DoclerLabs/hexInject#5

Somethime, we need to use conditional at runtime.

Something like :

var applicationAssembler = XmlCompiler.readXmlFile( "configuration/InitialConfiguration.xml" ); 
ApplicationXMLParser.parseXml(applicationAssembler, "configuration/context.xml", null, ["useHlsJs" => true]);

Need describe here.

Hi there,

hexMachina looks interesting!

I'm used to modelling my apps around RESTful concepts, and I have a question regarding commands. It seems overkill to create a command per verb for a restful entity provided by a backend API. Let's take the photo gallery example. We have a LoadPhotosCommand to load the photos, which in RESTful terms is basically the index or GET action on the entity itself.

Having a command class per verb method is just overkill in my opinion. I'd rather have controller would provide the right list/search, create, show, update, destroy methods or equivalent?

I'm not sure how this would fit within hexMachina's architecture or if such support is planned soon? Any suggestions appreciated. I'm probably also misunderstanding the architecture of the framework.

Of course, I'm sure I can ditch commands and add my own layer there, but I'd rather check the author's thoughts before proceeding :)

As reference, take a look at EmberJS's REST Adapter, which makes it very easy to connect Ember to a RESTful API: https://guides.emberjs.com/v1.10.0/models/the-rest-adapter/.

Because Macros have preExecute function, in the _prepare function we cannot use the request parameter, because it will only arrive later.

It should be passed already to the preExecute method

Like in Controller, I want to have access to owner._logger in a model.

Commands can get request parameter 2 diferent ways, depends on if they've called directly, or through Macros:

• once in execute(request:Request) method
• other time in @Inject request;Request property.

It should always be able to pass it in the execute function or never. but no inconsistency

The compiler doesn't show the error of the original line, just refer to the XML where we define the AdapterStrategy.

It should point into the real class to the real line where the error happened.

From @aliokan on August 12, 2016 17:50

Add an operator overloading on MessageType;
To simplified message type fusion :

var newMessage = new MessageType( myMessageOne.name + myMessageTwo.name );

Copied from original issue: DoclerLabs/hexCore#6

Annotation seems not working in Command AsyncCommand added in Macro.

In this example : https://github.com/aliokan/hexSandbox/blob/test/annotation-in-command-from-macro/src/configuration/context.xml

MacroWithAnnotation get Annotation, but CommandWithAnnotation not.

From @FrancisBourre on August 10, 2016 8:58

All the decisions/processes made from ClassType reference should be handled the same way for instances built from factory and/or singleton descriptions.

Copied from original issue: DoclerLabs/hexIoC#2

Now we have to pass everywhere the function scope, but it would be nice, to detect it automatically by the framework:

some examples:



...

new AsyncHandler(this, _onComplete)

From @FrancisBourre on July 22, 2016 5:52

hex.view.viewhelper.ViewHelper unit tests are very basic. They should be extended to cover the whole internal event flow.
This class should be updated.

Copied from original issue: DoclerLabs/hexMVC#3

From @axelmm on December 27, 2015 1:8

After short look at code I think returned values can be wrong in some cases.

CompositeClosureDispatcher::hasEventListener()

• can wrongly return true for empty _dispatchers (won't go false inside loop) and false (for many defined listeners and one dispatcher that doesn't have listener);
• returned value (var b) shouldn't start with true, it should be false;
• then logical OR operator (||) should be used in loop;
• first b resulting true should early return b; (no reason for more looping)

similiar for other places:
addEventListener() and removeEventListener() - shouldn't be false at start and OR in loop for !_sealed condition (w/o early return in this case) ?

isEmpty() returning false if ANY dispatcher isn't empty

• should be early return on first b resulting false (no reason for more looping); - possibly can improve performance

Any reasons (other that testing/debugging) to retun Bool for add-/remove-EventListener() [and false for cached] ? Usually we don't care about this result (f.e removing nonexisting, can be logged), for sure we can check explicitly by isRegistered()/hasEventListener().
Why don't return objects (this) to enable chaining methods (like msignal returning TSlot/SlotList)?

Copied from original issue: DoclerLabs/hexCore#1

I've fucked up an interface accidentally, and it didn't show me the proper message:

I wrote this in the IMyModelListener

function onMyChange(index):Void;

And the message was this:
.haxelib/hexinject/git/src/hex/di/IInjectorContainer.hx:9: characters 2-11 : Fails to retrieve pack for class named 'hex.di.IDependencyInjector'
.haxelib/hexinject/git/src/hex/di/IInjectorContainer.hx:9: characters 2-11 : Error caught: Type required for extern classes and interfaces

It should tell me I didn't give type for the index parameter.

inject-into attribute should be rename injector-creation for better readability.
It should be implemented at compile-time as well for assembler consistent behaviors.

<root name="applicationContext">
    <instance id="instance" type="hex.ioc.parser.xml.mock.MockClassWithInjectedProperty" injector-creation="true"/>
</root>

When you have a request parameter arriving in an MacroAdapterStrategy onAdapt function, and you store it in the this._request parameter, after the Macro preExecute function overwrites it to null.

Solution: It should check if it has been set already.

From @FrancisBourre on August 14, 2016 14:50

MappingConfiguration.addMapping API allows to inject into a mapped value when MappingConfiguration.configure is called.

For now, this feature is not available from the DSL. It should be implemented and be available at runtime and compile-time, like map-name and as-singleton attributes.
This new addition (to be consistent) should respect the same format.

Copied from original issue: DoclerLabs/hexIoC#6

A logger instance is already mapped to each module instance, but applicationContext doesn't have a logger mapped for its own domain.
DomainLogger instance should be created in ContextFactory and mapped to context's domain.

Model should be renamed BasicModel for framework consistency (BasicCommand, BasicView...)

Collections seem to not be available for injection, so for example this doesn't work:

    <collection id="fruits" type="hex.collection.HashMap">
        <item> <key value="0"/> <value ref="fruit0"/></item>
    </collection>

@Inject("fruits")
public var fruits:HashMap<String, MockFruit>;

Tried with a lot of combinations: map-type, setting the generic types in the XML, etc.

Test notifier should be notified when test case is skipped/ignored so those cases don't disappear in a void.

As BasicCommand is designed for a simple usage of the Command pattern, it should have a few changes;

• It should contain IInjectorContainer by default
• The owner property should not point to IModule, because it's irrelevant in the ApplicationContext
• It should always have a logger that is referring to the corresponding domain.

We should have the same changes for AsyncCommand

There should be a trivial naming in ViewHelper, because now it's confusing with dispatcher should be used.

I think the private one should be hidden somehow and mark also just for internal usage

Now till AsyncHandler has been removed from CommandMapping API (see #71), the method names are inconsistent. Plurial should be removed.

function withCompleteHandlers( handler : Function ) : ICommandMapping;
function withFailHandlers( handler : Function ) : ICommandMapping;
function withCancelHandlers( handler : Function ) : ICommandMapping;

From @FrancisBourre on August 16, 2016 8:38

Sometimes, you need to inject into mapped values coming from a mapping configuration and passed to your module. The best and common examples are view instances. Stateful services could be a problem, because they are often used by many modules.

This feature should be added to MappingConfiguration class and to the DSL as well with the existing attribute inject-into

Copied from original issue: DoclerLabs/hexIoC#7

HexUnit should support outputting test results into a file (for platforms where possible) to provide useful test results in CI systems like Jenkins, Bamboo, etc.
For starter JUnit will be enough.

From @grosmar on August 18, 2016 15:12

When we define ExecutionPayload we always need to define the type, even if we want to go for exactly the same one, just for performance reason.

The compiler should fill it out at compile time, and make the second parameter optional, like:

new ExecutionPayload( someClassInstance );

Copied from original issue: DoclerLabs/hexCore#8

I would like to be able to pass runtime objects to the XmlCompiler.readXmlFile function, and register them in the ApplicationContext.

For example initial configuration parameters that i get at runtime.

From @aliokan on August 31, 2016 10:27

BasicView should be align with IView. ;)

Copied from original issue: DoclerLabs/hexMVC#13

From @cambiata on May 30, 2016 15:27

Hi! Cool!

Is it possible to run tests on neko/cpp platforms?
Not implemented yet, as far as I can see in hex.unittest.notifier path...

Jonas

Copied from original issue: DoclerLabs/hexUnit#2

BasicModelTest class is empty for now

From @FrancisBourre on August 9, 2016 13:22

AnnotationReader class should not assign its parsing result (InjectorClassVO instance) to a new static property inside the targeted class.

Reasons:

• Risk of name collision
• Source code (that not belongs to the framework) modified
• Exposing data
• Losing control of the data

See the current implementation below:

fields.push(
{
    name:  "__INJECTION_DATA",
    access:  [ Access.APublic, Access.AStatic ],
    kind: FieldType.FVar(macro:hex.di.annotation.InjectorClassVO, macro $v{ vo } ), 
    pos: Context.currentPos(),
});

As well, AnnotationDataProvider class should be refactored to use a new deserializer behavior.

See code here

Copied from original issue: DoclerLabs/hexInject#2

It would be nice if I could create new objects in DSL that are referencing subemelents of an existing object.

<constant id="myProperty" ref="refId.somethig"/>

Hi. I need to pass an Array as an argument. Can you please implement?
It should be something like this in xml:

<collection id="windowList" type="Array#com.mvc.vo.window.IWindowVO">
        .
        .
        .
</collection>

When using guards inside commands it's most times needed to have dependencies from the context injected, sadly this is not working at the moment.

Request should be directly available in Macro.prepare method call

From @FrancisBourre on August 24, 2016 6:58

At this time, FastAnnotationReader need useless extra steps to generate ClassDescription expression.

It transforms ClassAnnotationData in an InjectorClassVO with all its internal dependencies (InjectorMethodVO, InjectorPropertyVO and InjectorArgumentVO), before generating the final AST.

The goal is to remove all the extra processes, and gain some compilation speed and better readability.

Copied from original issue: DoclerLabs/hexInject#7

From @FrancisBourre on August 18, 2016 3:19

It would be nice to have an assertion that ensures another assertion throws an error.
For now, we have to use nasty/boilerplate code for this kind of test:

try { Assert.equals( 45.31, this._lex( "45.a" ).getFloat(), "" ); }
catch ( e : InvalidSyntaxException ) { Assert.revertFailure(); }
catch ( e : Dynamic )
{
        Assert.fail( "assertion failed", "'45.a' value should throw an 'InvalidSyntaxException'" );
}

It would be nicer to have something like this:

Assert.assertionThrows(
    Assert.equals( 45.31, this._lex( "45.a" ).getFloat() ), 
    InvalidSyntaxException,
    "'45.a' value should throw an 'InvalidSyntaxException'" );

Copied from original issue: DoclerLabs/hexCore#7

From @grosmar on August 18, 2016 15:24

We have inconsistent usage of the followings:

function withPayloads( payloads : Array<ExecutionPayload> ) : ICommandMapping;
function withCompleteHandlers( handler : AsyncHandler ) : ICommandMapping;

As you see the withPayloads waits for an array of ExecutionPayload, and the withCompleteHandlers waits only for one AsyncHandler.

It should wait arrays or single ones all the time

Copied from original issue: DoclerLabs/hexMVC#4

Currently the _getRuntimeDependencies( ) method on the Module interface does not support the runtime checking of named dependencies.

Please add support for named dependencies as well.

From @FrancisBourre on August 9, 2016 7:30

The example below will get a reference of static property MockBrowser.document and will call querySelector method to retrieve an instance.

<root name="applicationContext">
    <div id="div" type="hex.ioc.parser.xml.mock.MockBrowser" static-ref="document" factory="querySelector">
        <argument value="#test"/>
    </div>
</root>

This feature is already implemented at compile-time:
See unit test
It should have the same behavior at runtime.

Copied from original issue: DoclerLabs/hexIoC#1

ApplicationContext just have name for now, but it should use its name as a domain. It's important, because it has its own execution context (injector, provider...), so it should definitely have defined domain for flagging officially all its internal components, like modules already do by default.

CompositeDispatcher class is not tested, it's one of the stateful services layer cornerstones, it should be tested.

From @FrancisBourre on August 15, 2016 9:42

Sometimes it can be a bit blurry if you don't have any experience with the @trigger metadata to understand the required steps to generate automatically an ITrigger instance.
The problem comes mainly from

• You need to implement the right interface to trigger @:autoBuild
• You should not forget to put the right metadata. Do we really need to use metadata? Maybe, just implement the interface would be enough and less error prone. But it could consume more performances, because it would have to inspect all class properties.

We should benchmark it and find the best transparent system for generating ITrigger implementations automatically.

From @cambiata on May 30, 2016 15:27

Hi! Cool!

Is it possible to run tests on neko/cpp platforms?
Not implemented yet, as far as I can see in hex.unittest.notifier path...

Jonas

Copied from original issue: DoclerLabs/hexUnit#2