Application structure proposal

[kevindierkx]

Application structure proposal

[ramunasd]

It's a nice work, well done @kevindierkx :)

Despite of your work, i'd like to switch to symfony 3. Then we could get rid of this "bootstrap" stuff, helpers, global variables and etc...

[kevindierkx]

@ramunasd Thanks for the input! Switching to Symfony 3 would do almost the same as I just did with my proof of concept.
However it doesn't get rid of the 'bootstrap stuff' it just places it in a different place like the app.php in this demo app.

Beside it not being necessary the helpers file would still come in handy when accessing the satis.json or some kind of resource anywhere in the application. I took the idea from laravel/laravel btw.

In the end it depends on which dependencies we require in the application, I don't think a full stack framework is required for adding some entries to a JSON file.

I would like to hear your thoughts about this!

[ramunasd]

Well, yes, it makes sense at some points. From what i see this application is growing to something more than just "adding some entries to a JSON file". It's very clear that we need add "must have" features like

• github/bitbucket hooks
• control of all satis options
• automatic tasks with background workers

We can make all these features and even more with silex. The questions is how fast we can go further with silex? symfony? laravel?

[ramunasd]

https://github.com/terramar-labs/packages is alternative to satisfy, you can get impression on what is important to have in such applications

[kevindierkx]

I agree the application could benefit from a full stack framework. I wouldn't mind using a full stack framework in the near future.

For now the directory structure needs changing anyway if you use Symfony or Laravel they both have a bootstrapping process, the proof of concept mentioned in the issue resembles the booting process of both frameworks. (Minor naming convention stuff left aside)

I would like to make a start with the logging mention in #53 this partly depends on some of the refactoring made in the proof of concept.

Might I suggest making a roadmap/whishlist with the wanted features? We can make an informed decision about what kind of toolkit we need after we decided what we actually want to build.

I'll continue work on the POC making a fully working example, this only needs some code being moved.

[ludofleury]

Hey guys,

Satisfy started really humble, to fill a quick gap. I didn't check the
alternative. But what we could start with is a roadmap of features. Let's
put in a specific issue everything and discuss it then organize a milestone
around it.

The tech choice will follows quickly and match the needs.

On Tue, 9 Feb 2016 at 16:05, Kevin Dierkx [email protected] wrote:

I agree the application could benefit from a full stack framework. I
wouldn't mind using a full stack framework in the near future.

For now the directory structure needs changing anyway if you use Symfony
or Laravel they both have a bootstrapping process, the proof of concept
mentioned in the issue resembles the booting process of both frameworks.
(Minor naming convention stuff left aside)

I would like to make a start with the logging mention in #53
#53 this partly depends on
some of the refactoring made in the proof of concept.

Might I suggest making a roadmap/whishlist with the wanted features? We
can make an informed decision about what kind of toolkit we need after we
decided what we actually want to build.

I'll continue work on the POC making a fully working example, this only
needs some code being moved.

—
Reply to this email directly or view it on GitHub
#54 (comment).

[kevindierkx]

@ramunasd, @ludofleury Alright I've finished the application structure refactor as you can see in #56. If you guys could take a look and let me know what you think that would be greatly appreciated.

[ramunasd]

For me it does not makes sense to move models and forms to another namespace. Form became Forms and Model to Models - is there any serious reason to change this?

Also i'd like to keep sources in src like it was before. I think it is convenient way in php community.

Regarding satis.json. Well, if You want to move it to another place, then this should be documented. Also this creates issues with default values in command bin/satis build. It was very comfortable to rerun build without any arguments.

I think this change is too big and has too much BC. Some parts does not follow common conventions.

[kevindierkx]

The namespace changes are mainly convention (in our company anyway), the folders/namespace contains multiple models therefore I've used the plural form of model/form. This is common practice in most Laravel applications, however I don't mind changing it back to its respective noun.

Regarding the src folder I agree it's widely used in PHP 'components' however in an application it doesn't make any sense and just makes your folder structure more complex. With the introduction of PSR4 you can define the starting point of your namespace perfectly fine. The only reason you would like to keep the src folder structure is for something that doesn't support PSR4.

The satis.json is a core component of the app and should be handled like one, therefore I've moved it to a more prominent and logical place.
You can easily modify the provided bin/satis file to autocomplete those parameters to the applications default ones. This is also needed for the logging I'm planning in #53. This should resolve most BC changes after we've done so.

Regarding documentation, since it's in a proposal stage I haven't spend the time to write documentation for something that could still change. If we agree these changes are acceptable I wouldn't have a problem adding them.