Let me preface this by saying that I am normally not a PHP developer, and am a complete beginner when it comes to Symfony2. I was kind of thrown into this project, and we are on a pretty tight deadline.
With that out of the way, here is my problem:
At my company, we have a PHP library for an internal API which is old; it doesn't use namespaces and it doesn't really follow any standard naming convention such as PSR-0 or PEAR. However, I need to use this in our Symfony2 project. Symfony2 obviously relies on namespaces a lot. Am I completely screwed if I don't update the library to follow the "new" conventions, or can I somehow use it anyway? The thing is, it is a pretty huge library, and we simply don't have time to do that right now (someone should have done it ages ago, but that is another topic...).
Theoretically, could I just place the lib under vendor/ and use good old old requires/includes in my bundles? Will this even work? Will I get a mob of angry Symfony/PHP developers after me by doing this?
Or, is there a better way that I'm not aware of?
You can do what you suggested, and you can even use the MapClassLoader, and give it a static map between your classes and your files, so that you don't even need to require files from your library. You don't have to write this map by hand, you can generate it with the class map generator
Related
I have recently started learning about Alfresco Content Service.
I have some questions:
My understanding is that the standard way to add customization is to create AMP's.
Why create an amps for each customization instead of adding it directly to the configurations of ACS? Are there some benefits like not having to restart the service or something?
If apply_amps adds all custom amps to the alfresco server (.war files), won't there be a risk of customizations writing over each other?
E.g if two different amps change the same standard button in the share service.
I have found that there are 2 ways to add these customizations as well:
Add dependency to the pom file. (works only for .jar)
Actually compile the .amp and move it to the correct folder and run apply_amps.sh.
From the documentation it seems to my like AMP-files used to be the standard way of adding customization but that there have now been a move away from this in favor of using regular jar files and eventually in 7.1 and forward use JSON instead.
Yet other tutorials I find mentions things like "always use .amp". Which then seems strange if it contradicts the information on the official documentation.
Also I found something about adding amps through the share interface? Or must they always be added when building the server (.war)?
Could someone provide me with a thorough explanation of the best practice for applying customizations to the alfresco content service? Preferably with details regarding a live production setting.
Thanks for helping me make some of this clearer.
I'll try to give you helpful answers:
Making app packages (APMs or JARs) is much better than changing config manually. It's good for versioning, portability (TEST vs PROD or between projects), composition (you can add some addons witch are often very useful)... It is standard and good way how to build a web app.
About conflict of customizations, I'm not sure how it works. Is good practise always use own namespace for every AMP.
If AMPs write to the same file, result is always append (share-config-custom.xml can get be very big).
Problem about JARs and AMPs is simple. Old version of Alfresco supports more AMPs than JARs. Now it does not matter with way you use. Try to look inside these packages they look very similarly.
I never heard about adding AMPs through the share interface. Have you some source? Only thing which is similar is creating content model through Model manager (https://docs.alfresco.com/content-services/latest/tutorial/model/)
I use for PROD combination of AMPs and JARs. I have a lot of legacy code and addons in AMPs and new things in JARs. Alfresco work with them same...
I have a basic question about Foundation5 setup, and associated publishing workflow. I'm on a learning curve towards creating a better local dev-to-publish workflow, so bear with me please...
Currently, I create F5 Compass projects; straightforward, but lacks programatic minification, concatenation, (CSS) cleaning, etc. LibSass projects, and a process like this, seem to readily offer these capabilities.
My question, essentially, if this is correct, and if not, how such capabilities can be added to a Compass project? I ask this simply because I have existing Compass projects under development that could use the aforementioned utilities and, also as mentioned, I want to build a better approach in general.
Conceivably, I could migrate existing Compass projects (local instances of ModX) to LibSass, but I'm sure this would come with complications.
Thanks in advance for your input.
I was going through the Symfony2 best practices and got confused on two things:
1 - Annotation usage - It says that for Routing and Cache we should use Annotations. But, I prefer to use annotations for ORM & Validation and YAML for Routing (one single file for all routes). How it is a bad practice?
http://symfony.com/doc/current/best_practices/controllers.html#routing-configuration
2 - For reusable bundle (never created one), if I wish to include any JS library like jQuery then it's not a good practice? Confused.
http://symfony.com/doc/current/cookbook/bundles/best_practices.html#vendors
Please note that "Best Practice" doesn't mean that doing anything different from what's suggested is wrong. Instead, anything is perfect if you know why you're doing it. The Best Practice guide is designed to take away some decisions for beginners. They already have a hard time learning the framework, having to make decisions like where to put code and which format to use would make things infinitely more difficult.
With that in mind, the reasons for the best practices you mentioned:
1 - Annotation usage - It says that for Routing n Cache we should use Annotations. But, I prefer to use annotations for ORM & Validation and YAML for Routing (one single file for all routes). How it is a bad practice? http://symfony.com/doc/current/best_practices/controllers.html#routing-configuration
Having less files makes it easier to follow what's going on. Imagine having a route, controller, an entity and some validation. This means that one has to learn the following locations: app/config/routing.yml, src/AppBundle/Controller/StaticController.php, src/AppBundle/Entity/SomeEntity.php, src/AppBundle/config/validation.yml and src/AppBundle/config/doctrine/SomeEntity.orm.yml. That's quite a big list to get familair with.
If Symfony recommends to use annotations for everything, you end up with the following list: src/AppBundle/Controller/StaticController.php, src/AppBundle/Entity/SomeEntity.php. That's quite an improvement. This is the reason that Symfony recommends to use annotations if you're starting to learn the framework. If you're familiar with Symfony, you probably make your own choices and decide which format you like and which you don't like (some people like annotations, others hate them and prefer XML or YAML).
2 - For reusable bundle (never created one), if I wish to include any JS library like jQuery then it's not a good practice? Confused. http://symfony.com/doc/current/cookbook/bundles/best_practices.html#vendors
It's often not very great to commit dependencies. For that reason, Composer was created. For front-end dependencies, Bower/BowerPHP was created. Using something like that means your code is easier to share.
Of course, as Symfony is a back-end framework, it's perfectly fine to use jQuery or whatever library you like.
1.that say:
Make your controller extend the FrameworkBundle base controller and use annotations to configure routing, caching and security whenever possible.
for that you have thin controller and you can only have routing & caching & security in your controller as annotaion.
orm mapping & validation are in entities no in controller
and that say:
In addition, using annotations for routing, caching and security simplifies configuration. You don't need to browse tens of files created with different formats (YAML, XML, PHP): all the configuration is just where you need it and it only uses one format.
because, routing & security & caching are related to a controller, but orm mapping & validation are diffrence and can use in onther places(controllers, repositories, services and ...)
2.
For reusable bundle (never created one), if I wish to include any JS library like JQuery then it is not good practice
and if you will use third-party bundles, that is better that you use a depedency manager as composer or bower.
see sonata admin bundle that is a good & big project that use bower for third-party bundles as jquery, bootstrap & ...
I'm currently working on a PHP project using CodeIgniter as my framework. I took a look at a few templating systems I could probably use - Strogen's Templating System (currently used in PyroCMS - if I'm not wrong), Twig, Smarty etc.
But I have decided to go on my own to build one from scratch. Since I have experience dealing with Wordpress templates, I was thinking of creating something similar.
To give you a run down of how wordpress themes work - Wordpress has a set of functions (Theme functions) that help gather data. I was wondering if following the same would be a good idea for my project as well?
If I did create such template functions which I would be calling within my views, would it work against the MVC principles? And would it affect the performance in any way?
Well, with MVC, models do the db interactions, views display the data, and controllers are the go-between. If you created your "template functions" in the controllers, I suppose you would be complying with MVC. If you wanted to say, create a library or helpers to do the gathering of/manipulation of data, you would not be complying with MVC convention. AFAIK, it's a matter of preference which way you choose. As far as performance, you could use profiling to test which is better.
However, if your aim is to build a templating system for CI that is similar to WP just because you are familiar with the way WP templating works, I'd proffer that it would likely take you substantially less time to learn a new one than build your own. I'd also imagine it would take much less time to learn the new one than it did to learn the WP one.
Also, I think pyro uses a combination of Phil's templating and smarty, but not positive. Phil has a templating system available for CI here: https://github.com/philsturgeon/codeigniter-template May be worth checking out.
cheers.
Let's say I have a Visual Studio solution with a Web project, a BLL project, and a DAL project. I'm trying to follow the repository pattern keeping my SQL code in the DAL with an interface that is referenced by the BLL.
I have a handful of common solutions for things such as error handling, usage logging, and other things that can be considered utility functions (i.e. not in the business spec). I'm keeping these in a Common project.
Here are a few ideas I've had with regards to structuring the Common project...
Bundle SQL with logic in a given class
Create a layered solution within the Common project
Discard the Common project and put utility functions in with BLL/DAL
Is one of these ideas better/worse than the other? Does anyone have a better solution?
It's worth noting that these utility functions will be reused in a variety of other applications.
Instead of creating a Utilities project which will be used have you thought about creating something that can provide a service? You might want to look at Aspect Oriented Programming. Red flags went up when I saw you listing off your examples error handling, logging, etc. Those scream AOP.
But if you want to stick with your layout.
I think I would go with 2, assuming that means restructuring the utilities project to be more Cohesive.
I don't understand (please clarify and I will edit my post)
Bundle SQL with logic in a given class
As for:
Discard the Common project and put utility functions in with BLL/DAL
I would be against doing so. If this logic is truly going to be repeated there is no need to push it back into your projects. This will lead to duplicate code and increased maintenance.
Side Note:
Just as a lessons learned, the only way Utilities projects work, are if you are the only developer or it is well documented and well designed. Sometimes utilities are too programmer specific, or are written in a way that only benefits a particular coders style.
I have seen countless times people rework their infrastructure pulling out all kinds of utilities, only to see their utilities project never get used. Make sure the "utilities" you are creating are truly useful to other people.