I have my own Admin Bundle which is being developed in time. I just put it into new project and use it. If I need a new functionality I add it and use it later in another project. I put it in src/ directory. I don't want to store in on public Git repository.
Now as Symfony 4 is bundle-less, how should I easly put it into src/ dir so that it is decoupled from other App code?
I would like to develop the App as I shoulg but I would like to have an opportunity to easly copy Admin code to use it for another project.
Bundles are still perfectly available and useful in Symfony 4. They aren't suggested to be used for the main program code, as it is a little easier to not need that structure.
3rd party bundles are still incredibly useful though, to easily connect functionality, templates and services to an application. Equally, if you have some code that can be used in multiple applications and most easily added as a bundle, you are perfectly able to write your code as its own bundle. You can initially write it within your src/ directory, and then migrate it out to be an external bundle/library that can be pulled in via Composer when it's useful to do so.
Related
Thanks for your attention, this is a question of organization, I work with PHP and GIT for version control. I use Netbeans IDE to program, GIT integrated (although I am still a rookie).
Normally, I follow the approach that Symfony2 specifies for organize the project files, but I use my own framework for my projects.
The (main) question is: Any component or code part which has its own version control must be located under the /vendor/directory?
For example:
I have my project files in src\Acme\ProjectX\, also the utility package which use all my projects: src\Acme\Util\, and it is under the version control too (GIT).
and now let's remember the basic skeleton of a project based on Symfony or similar:
/app (application related elements)
/src (source code of the project)
/vendor (third party libraries)
/web (front end controller, the web directory, assets resources etc...)
So, Must be 'Acme\Util' included in the vendor directory? And, is necessary to use composer to declare the dependences?
In addition, the Utility package has a lot of classes but only few are used in projects. Must I remove those are not using by the project.
Summarizing, It will be nice if someone can contribute his knowledge for help me to represent an scenario like this.
I hope I could explained...
Thanks in advance!
Vendor directory
It's a good practice to separate external dependencies and the application code. If you are using Composer you can change it to something else.
Unused classes
Unused classes shouldn't matter if they aren't being loaded. They'll just take a bit of extra disc space.
It might be a good idea to separate the Utility package into multiple packages if you find yourself frequently using only a small part of it.
Dependency managers
It isn't necessary to use a dependency manager, but it sure does help. Having to install, configure and maintain everything manually (especially with many dependencies and sub-dependencies) would be a horror.
TL;DR: what is the best way to arrange files, package managers and build tools for Laravel 4 + Zurb Foundation 5 combo (with Compass) as one consistent repository with clean public (static) section?
I wanted to start a fresh project, based on latest Laravel on the backend side and using Foundation for the frontend. I am new to both of these and apparently I missed some of the tooling that was developed meanwhile when I wasn't doing PHP for some time.
My confusion:
Laravel uses Composer for installation and dependency/module management. (Ok, I'm new to Composer)
Foundation is available as a Composer module (but then what?), but generally also as a CLI tool that creates a new project and uses bower for module/dependency management. But then I have two repositories.
Is it required for me to expose all my .scss files, or maybe even put the whole Foundation project into laravel's public dir to make all work?
How do people usually approach using these frameworks together? They shouldn't interfere, but they still have totally different tooling.
Where do I put my foundation files? Keep it as composer module or inside public? How to refer to them? How to have one build everything command?
I have the same issue as using Bootstrap SCSS version for Admin & Foundation SCSS for the frontend. I noticed also that both css frameworks come as composer packages however the issue you have with this approach is that you generally use other Javascript files in a development that will be merged also so using the composer versions just adds to the confusion.
The best solution i found was using either gulp or grunt with bower at the top level of your Laravel build. Rather that go through the configuration for you there is a good article at http://blog.elenakolevska.com/using-grunt-with-laravel-and-bootstrap/ that goes over a bootstrap integration but this can be tweaked for Foundation. This solution is good as grunt has many of the other popular javascript libraries that you may use in your project also..
Alternatively you could use an application like codekit and create a compass project to manage the merging & compiling of your assets into the public folder. As a side note if using git again your would need to exclude additional folders from your project.
If you think of your SCSS framework files as development assets there is no real need for them to be in the project as you only really need one version of Foundation on your development machine.
Your custom SCSS changes can be added to your Laravel project as modules ie a navigation module, via a private composer repo for the project or just added to the Compass project at development time. Your public folder should only be referencing the final merged style.css & java.js files for example. Any images from the framework can then just be copied over to the public folder ie icons etc.. Hope that helps..
Personally I have a "static" directory which houses static files. That is where I use SASS watchers, grunt tasks and basically the entire front-end workflow. The results of that front-end build process gets added to a "production" Laravel public directory after getting built, etc.
A pro of this is that everything (static assets and laravel application) is separate.
A con is that updating Laravel views with any updates in HTML templates you may build in the static directory. If you update the templates, you may also need to update the view files, which becomes more tedious as you add more templating logic around the HTML in the views.
Just one suggestion.
I have directory structure which looks like that
Framework folder is from https://github.com/yiisoft/yii
For now, I'm updating framework folder like that.
Created another folder for Yii framework. Pulling every update and then duplicating framework directory into framework folder.
I want to automate this routine work. Is there anyway to update this framework folder from https://github.com/yiisoft/yii with commands like
cd framework
git pull
It might be wrong of course, but I'm newbie to git.
Any suggestions?
Thanks in advance
I think you should use Git Submodules:
It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.
...
Git addresses this issue using submodules.
Here's a wiki explaining how to manage it in Yii
I have a PHP Platform that I've built.
I use a copy of that project for each project I do.
I add assets and configure each project with it's own content.
Configuring a project changes some of the core files which contain
the configuration defaults.
When I update core files in the library/platform itself and I want to disseminate those changes to all of the other projects using that platform, what would be the best approach?
I think it may be worth noting that I have each project as an SVN project in Eclipse.
UPDATED DETAILS:
The platform is based on AMFPHP 1.9.
AMFPHP has a services folder.
I have to put core services in the services folder as well as
implementation specific services and therefore cannot achieve
complete separation between the "library" and the "application".
Also, the default configuration files need to be in the "platform" folder
so they can be easily distributed with it, but when configuration is
changed, those files become "implementation specific" as well.
Is there a solution that will allow me to designate certain files to update?
Take a look at the use of svn:externals. Configure each secondary project with your core libraries as an external.
Excellent question, here's the way I solved this problem with my own PHP framework.
If you have all the project-specific and core files mixed together, and platform code interspersed with your project code, it's going to be really difficult to update the core code to all of your projects.
The best way to get around this is to make it easier for svn (or git, or any other versioning software) to update your files: if they're all neatly organized, with project and core files in their respective places. Let me give you an example to clarify.
Put all of the core files of your framework in this directory:
/App/FrameworkName
Here you can place core classes, functions, and other code that won't change for all of your different projects.
Then, any project-related content, settings or pages go in:
/App/Project
Here, you have all of the data that your projects use.
With this system, if you add a feature to your platform, all you have to do is svn the latest version of your framework to /App/FrameworkName, and your project will be using up-to-date code.
My programs are usually organised in two parts. the core framework folder, and the addon folders.my framework (in house) does all the initial work then loads the addon for additional functionality.
For example, the framework deals with all the user auth , the addon provide additional crud functions the each project needs.
That way, i can keep them in separate repository. and the framework can be checked out and used for other projects.
I'm working on releasing a PHP framework I have been using for a few years
on github. Been trying to read up on the most correct way a project
should be structured, what extra files such as readme's etc should be
added. Been coming up with blanks on google. Can anyone point me to a
project that's a good example or any good write ups.
Some PHP projects hosted on Git(hub) include:
CakePHP
Gallery3
Garden
PHPUnit
Kohana
I'd just make sure that no temporary files, etc. get in the repository by creating a .gitignore file, and add some readme's etc. to the root of the repository.
Any configuration files should also be ignored, and sample configuration files should be created in the repository.
I'd recommend writing the readme file in a format that Github supports, like Markdown. It'll make your repository front page look better.
You might want to follow some kind of class naming guideline to make things like autoloading easier to implement. For example, the class MyFramework_Controller should be located at directory /lib/MyFramework/Controller.php.
You should just create some kind of basic layout for now - it'll be easier to give suggestions when we can see what you have right now.