potential for v4?

[dcblogdev]

I know I've been the biggest support on staying v3 but with the constant updates happening I feel it would be better to jump to v4 now and separate the application into app and system to the framework can be updated from a composer update.

thoughts?

[LuckyCyborg]

I was always the biggest partisan of separating the application on app and system, thing of nature to simplify considerable the updating the system by end users.

Also permitting having multiple apps, i.e. a slim bare one, without nothing demos, and one fat and full fledged.

Yet, to note that going on Composer package with system, we need to enclose everything in a common namespace i.e. Nova. And that's a epic API break, then the major version increasing is well justified.

BTW, I suggest you to create two new repository, called app and system, also to register them to packagist, to me playing with.

[dcblogdev]

OK we are in agreement I will add those repos

[dcblogdev]

https://packagist.org/packages/nova-framework/app https://packagist.org/packages/nova-framework/system

both exist both repo's contain a composer will that will need configuring.

[LuckyCyborg]

@daveismyname Roger that! Tomorrow I will start over that.

[dcblogdev]

👍

[jimgwhit]

@daveismyname and @LuckyCyborg

• Will system be moved to vendor
• Will some of the helpers remain out of vendor for customization
• I can see the new API stuff being in vendor, but not the original database helper

[dcblogdev]

Yes system will be moved I should think everything in the system would be moved let's wait and see what can work with this setup of course always interested on your thoughts

[LuckyCyborg]

@jimgwhit Sorry, Jim...

BUT there will not be system folder anymore. Custom Helpers will go to App\Helpers

@daveismyname How about to nuke the legacy support? Your community already learned to use new APIs and some struggle now ORM.

[dcblogdev]

Just to be clear what aspects do you propose to remove? I'll check back in morning

[LuckyCyborg]

@daveismyname

I talk for example, the support for View::render() and View::renderTemplate() and the following Helpers:

Helpers\Csrf Helpers\Database Helpers\Request Helpers\Session

Additionally, those Helpers are just duplication, having better alternatives supported by the new APIs:

Helpers\Cookie Helpers\Encrypter Helpers\FastCache Helpers\Mailer <-- this one require changes on code to work properly (aka its configuration), and on the next update they will be nuked Helpers\Paginator Helpers\Password

Also, the Events API offer now a much powerful support than Helpers\Hooks, and it is well integrated in the new APIs.

Those which will want all those Helpers can simply backport them to App\Helpers.

To note that intervention will be required anyway, because namespace change, .i.e. Nova\Helpers\Database.

Let's do not play the two-two die-harders card... :smirk:

[jimgwhit]

@daveismyname and @LuckyCyborg Helpers\Paginator Helpers\Password Helpers\Database

These 3 Should stay.

The Helpers\Paginator works so great when using / writing regular queries.
And the Helpers\Password is 100% php compliant and very easy to use.
@LuckyCyborg don't muck this up. I use the new api, sessions, rendering, but with original database helper.
In fact I kind of like the new rendering techniques. But I like the complete simplicity and ease-of-use of cases of writing regular queries of the original database helper.
At least explain how to use it in any version if it is removed like where to put it and how to call it.
But would be nice to leave in. And Dave's paginator is one of the best php paginators out there. Even works great with query builder when using skip and take. And works perfect with doctrine dbal if someone want to use that.

[LuckyCyborg]

@jimgwhit Look, I suppose that version four to give (legacy) support to three, not to two-two.

Facts are that Hash Facade give you exactly what offer also Helpers\Password, while for new APIs, Password is something entirely different: Auth's Password Broker.

Also, Database API support long queries, just like Illuminate\Database do.

In other hand, that Helpers\Paginator is hard-coded to Bootstrap3, even it work with QueryBuilder too, while that QueryBuilder give you native pagination support.

If you really want to keep and use those three Helpers, nothing stop you to port them from Nova 3 to namespace App\Helpers.

Alternatively, maybe someone will have the will to create and maintain a Composer package shipping them. Or the two-two die-harders know only to ask for?

BTW, in any chosen variant, there will be the need to change the code, even if we keep them, becoming:

Nova\Helpers\Paginator
Nova\Helpers\Password
Nova\Helpers\Database 

[dcblogdev]

I'm inclined to agree with @LuckyCyborg there are 2 ways to work with quite a few areas, makes sense to reduce that to one, as mentioned the helpers can be added under app/Helpers by the end user.

I could add the classes to separate packages that can be added to composer as the end user desires.

[LuckyCyborg]

@daveismyname BTW, I have direct write access to app and system repositories?

In the initial stage, I guess is better to push directly to, instead to use my own forks.

[dcblogdev]

Yes you have write access to the Nova organisation so that includes all repos.

[LuckyCyborg]

@daveismyname Look there, maybe I miss something:

bash-4.3# git push
Username for 'https://github.com': LuckyCyborg
Password for 'https://LuckyCyborg@github.com': 
remote: Permission to nova-framework/system.git denied to LuckyCyborg.
fatal: unable to access 'https://github.com/nova-framework/system.git/': The requested URL returned error: 403
bash-4.3# 

[dcblogdev]

ah ok 1 minute.

[dcblogdev]

try it now.

[LuckyCyborg]

@daveismyname Yep, worked. Thanks!

Same thing I need to app repository, too.

[dcblogdev]

done it there too

[LuckyCyborg]

@daveismyname Thanks, but looks that there is no propagation on packagist. How much time will be need for?

[dcblogdev]

didn't get it working last night, will look at it again.

[LuckyCyborg]

@daveismyname OK

[dcblogdev]

OK it's updating now.

[LuckyCyborg]

@daveismyname Thanks!

[LuckyCyborg]

@daveismyname We agree on using for System the namespace \Nova\ ?

[dcblogdev]

Yes.

[Amin-stefan]

I think if there was a functions file like system in app for every module or whole framework that would be better

[LuckyCyborg]

@amiroperator There is no need for.

The nova-framework/system ships the framework, after all, while the nova-framework/app will ship the Application, where the end-user have its site.

[AdminUI]

Can i quote a conversation we had the other night @LuckyCyborg : ' The system folder is mine and the app folder is yours' , made perfect sense to me. I moved all my helpers into the App folder and the system is completely untouched from master and it worked well on the following PRs.

[DonWagner]

This sounds like a great development.

What about the demo modules?

At some point these a great, i love them and uses them to read and learn from, but i still think it would be better if these could be ship separate, and not be a part of the mani parts like nova-framework/system and nova-framework/app.

Maybe like before, the smvc homepage had/have a section to addons. This section could get a makeover and the demos could bee added in to this section.

In that case, it would also be nice if the users could se which versions the modules was made for.

[dcblogdev]

there will be a demo repo for this purpose I believe, the addons sections could be utilised for this end too.

[LuckyCyborg]

@daveismyname Right now, I will work on full App tree.

And I suggest nova-framework/app to remain as it is, a full fledged application with all demos and templates.

On future, for those which want a naked app, you could create a nova-framework/bare-app repository which ship no demos, no modules, and no templates; even no Welcome Controller. Nothing (TM).

[dcblogdev]

why? that really makes no sense to bring the demos as part of the main framework, having the main app to essentials only the demos should be elsewhere.

Otherwise 2 repo's need to be kept up to date whilst a demo tree or forget a demo tree having addons modules that a user can add themselves make more sense as they can be maintained seperatly from the framework leaving the choice to the end user to include the demo or not.

[LuckyCyborg]

@daveismyname The main Framework is nova-framework/system, the apps are just apps, nothing more. Shipping a bare one and one full fledged will not differ essentially.

And the demos help me on development. I do not use testing, I just implement everything I need to test.

[dcblogdev]

On install it will still contain demos why?

keeping nova-framework/app free of demo means it can be used right away without having to remove unwanted things that should not be there to start with as they are just demos.

[LuckyCyborg]

And what will differ if we ship the bare app on nova-framework/bare-app ?

Please figure that on version four, the framework will be nova-framework/system, not the apps !!!

[dcblogdev]

I know that! but I know you, you won't be able to leave app alone so the end result is 2 repos will need to be updated constantly instead of 1.

[dcblogdev]

Why do you want demos on the app release?

[LuckyCyborg]

Why do you want demos on the app release?

Helps me on development. AND I literally use those Modules and Templates. :smirk:

Oh, I will update myself those apps, thank you.

The bare one need minimal maintenance. Even that full fledged will not change much.

Facts are that you can ship dozens of apps, after all.

[LuckyCyborg]

you won't be able to leave app alone so the end result is 2 repos will need to be updated constantly instead of 1.

Moving the demos on another repository will result in maintaining two repositories also.

And for me, demos are even the Templates. You can write a RESTful API without them.

[dcblogdev]

When I use composer to install Nova I don't want to have to spent time removing modules and demo code that I may not be using so you want to use something for your company so the answer is to make it more inconvenient for everyone else.

Is there an option when using composer create-project to specify the app repo so either one can be selected I think that would solve this.

Moving the demos on another repository will result in maintaining two repositories also.

Not if the app is left alone once it's setup it should not need to changed frequently otherwise what's the point in separating them if app is going to be edited all the time, that will result in the same upgrade issue we have now.

[LuckyCyborg]

@daveismyname Just trust me in that. Is not first time when I doing that Design.

You have only to prepare that nova-framework/bare-app too, and you will see that there is nothing to maintain if I not touch the Boot Stage. Because there is nothing and it will be ideal for RESTful APIs.

[geomorillo]

So if we return to the upgrade issue after doing your Design can we remove those demos?

[LuckyCyborg]

For full custom application, you will have just to use nova-framework/bare-app instead of nova-framework/app, which ship no demos and no templates.

Nothing will be in the way for you.

[dcblogdev]

You will have just to use nova-framework/bare-app instead of nova-framework/app, which ship no demos and no templates.

How will that install from composer command?

[LuckyCyborg]

composer create-project nova-framework/bare-app foldername -s dev

instead of the full fledged

composer create-project nova-framework/app foldername -s dev

[dcblogdev]

Ok that's easy thank you.

[LuckyCyborg]

See? Then give me also the bare-app repository to play with.

[dcblogdev]

already doing so :)