in our team we started to migrate an very old PHP-newbie project to cakePHP and I'd like you to ask about how to structure some parts of it:
We have:
The cakePHP coreSources seperated in a vendors-directory
The application (app)
So now the question is how to structure addional parts of the application which are seperated due to permissions. But they are related to the application and in the old version much sourcecode is duplicated which we want to avoid.
admin tools panel
payment panel
support panel (lets say kind of help desk)
I'd like to keep them in seperated GIT repositories (as they are written by us and not 3rd party/vendors) and I dont want one huge repo which keeps the application and all of its addional panels.
So the question is: How to build this in cakePHP to avoid duplicate sourcecode? Example: A message written in the app should be visible in the suport panel when its reported as spam or bad words. (Do you understand what I mean?)
Shall we use plugins for the several panels or shall we build completly own cake-apps which will lead again to duplicate sourcecode? Are there other ways to deal with this problem?
Greetz
P.S. Sorry for my bad english.
If I understood you right you want to have modules that can be shared between applications. Plugins are the right choice then. You can manage them in git repos but I would use composer to install them in your apps.
Just putting something in a plugin won't make everything 100% reuseable and extendible make sure you write your code in a way that it can be extended using OOP principles and design patterns on app level if needed.
Related
I'm working on a Restaurant website project and my client wants a Blog section and a complex Reservation System with it.
I use Wordpress to work with blogs and I prefer to use Code Igniter for systems but I don't know if these two can work good together. I have been reading some articles regarding the integration of CI to WP and a lot of it points out that conflicts are inevitable when doing so.
Are there any solutions you can offer me? One that is easy to integrate, no conflicts and helps me keep my code DRY.
As you pointed out, integration is not readily available. If you truly wanted to integrate them, it would be a long road (and not likely worth it). One think you could do is install them separately and just link between the two when necessary (not ideal, but doable). For instance you could install CodeIgniter at example.com/reservations/, and then install your blog at example.com/blog/
You could also utilize subdomains if you wanted. I honestly would go this route if I was faced with the same situation...I definitely would not waste the time in trying to integrate the two if there isn't a lot need (ie, blog posts needing to access information in the reservation system, etc...).
I have seen lots of pages about Yii Boilerplate setup like: http://www.yiiframework.com/wiki/374/yiiboilerplate-setup-a-professional-project-structure-in-seconds/.
Is there any step by step instruction about creating a new basic YiiBoilerPlate app or maybe I am totally wrong about it!?!?!
Just build your app to fit your needs remembering to keep project specific files in separate folders, separate from base application components, like common extensions. I highly recommend using modules. You can have for example user management module with login, logout, profile etc. functionality, and depending on concrete project requirements just drop in more modules.
Mentioned boilerplate is more complex than standard Yii setup. There is one thing i really dont like, is that mudules are in both frontend and backend, and according to yii philosofy, module should be like mini application, so from this boilerplate seems that one should build separate mini apps for frontend and backend... But it is just a taste what you feel better.
If you are new i recommend standard setup, but using modules from beginning. Modules are something like mini app, which can operate on it's own. This way you can build your portfolio of modules, and then when doing some new project you can compose it much quicker and sturdier. A bit more tricki might be interoperability between modules, but thats a whole different story.
You should refer following article.
http://myprogrammingtut.blogspot.in/2013/04/step-by-step-setup-yiiboilerplate.html
which worked for me :)
Hope it'll help you.
I have developed an application and now I would like to hire some programmers to work on several pieces of it to upgrade and tweak it.
I have read other questions/answers here but they are mainly about obfuscating the code which is something I do not want to do (as I need them to read it and tweak it).
What I'm basically asking is, what is the best way to structure my code so I will have to expose only what I have to?
A good example for me is a webapp called RightNow which I'm developing for at work, what they do is they let you play around with all the widgets (you can create/edit/remove any widget) but the core of the application is in folders I do not have permissions to.
After you do your coding on the widgets, you then 'deploy' the application and it goes live. I have no idea what the deployment actually does behind the scenes, but this is one practice (not sure if it's the best) which allows the application owner to have control over the core of the code but still allow development for it.
Is there a better way? what do you think?
First you can use a version control software like SVN for example.
and then you can have copies of the code, one for testing and one for the your programmer. When the programmer is done changes and tweaks, the testing code gets updated first and when the test are done the live application gets updated.
you can obfuscate your core classes(ones that you don't want to expose). and other developers can include and use them at the same project as long as you provide a nice api to your classes.
I'm looking for inputs into how I can manage the upgrade process itself of a homegrown php/mysql application. Meaning, if we have a 'stable' version of our php/mysql application working on our production server, and we now want to upgrade it to the next version that we've worked on - how do we go about doing that elegantly? What practices should I be implementing?
What I was planning to do was just to
Ask the developers to stop
checking in code after all stability
/ functionality tests are done
Take the application offline*** (Q: how should I prevent ppl for logging in / accessing public pages? Best practices for that?) but allow access to developers through a secret login page / url
Log onto the production server and check out the latest version
locally***
Have the developers/testers test their code through the secret access page / url***
After that is done, we restore access to all by removing this secret access page / url, removing the site-under-maintenance page and restoring access to all.
***NOTE: A simple way of doing this would be to rename /myapp/ to /myapp.old/ and put the new application version into /myapp.new/ Developers would access /myapp.new/, test to their satisfaction and then after we're done, we would rename this back to /myapp/ (this is just the basic idea)
This is a huge question, and in many ways it will depend on your specific project. But here are some practices to think about:
Put lots of comments in your code. Things that seem perfectly logical now will be confusing when you go back to make changes in a year or two.
Maintain a development version of the site with its own database. You can test changes to the site before publishing to your production site.
Use a PHP framework (such as CakePHP, CodeIgniter, etc). If you are far along on your project, this may be difficult to do. But it will help you write code in a way that is easy to update, and will include a lot of stable, mature functions that you won't have to write from scratch. Using one of these frameworks (and following its best practices) is probably the best way for a beginner to learn to think about writing modular code that's easy to update. This will also encourage you to develop your database in a way that is consistent with the structure of your site.
Write tests (the framework should help you with this) to programatically check your code for errors.
Use a version control system such as Subversion or Git. This allows you to track changes to the site, and easily roll back changes if/when you realize they are buggy.
Comprehensive unit test coverage would be very helpful, as would small, highly cohesive, low-coupled classes. In addition to the unit tests, good coverage from an integration level would be valuable.
I have a need to create a library of Object Oriented PHP code that will see much reuse and aspires to be highly flexible and modular. Because of its independent nature I would like it to exist as its own SVN project.
I would like to be able to create a new web project, save it in SVN as its own separate project, and include within it the library project code as well. During this process, while coding the web application code and making commits, I may need to add a class to the library. I would like to be able to do so and commit those changes back to the libraries project code.
In light of all this I could manage the code in two ways
Commit the changes to the library back to a branch of its original base project code and make the branch name relevant to the web project I was using it with
Commit the changes to the library back to the original code, growing it in size regardless of any specific references that might exist.
I have two questions
How can I include this library project code into a new project yet not break the subversion functionality, i.e. allowing me to make changes to each project individually?
How I can keep the code synchronized? If I choose the first method of managing the library code I may want to grab changes from another branch and pull it in for use in another.
EDIT - I realize I can simply check out these projects individually and commit/update them individually as well, but then how can I include them together as a single project? To be more clear, how could I create a web project that includes the library code as a unified subversion project in consideration of the points I elaborated on above?
I think you can use svn:externals to achieve what you want. It will pull the library project into your website project and update it whenever you update your working copy. The only thing is you cannot commit back to the library in the same commit as you project as described in this question How do I checkin to local copy AND svn:externals subdirectories in one commit?.
Option #1 looks like the right way to go.
I think you should expect to keep separate branches of the API project for any of your sites that have site-specific modifications to the shared API. Of course, you don't need to create the branch upfront, just checkout the 'trunk' and make sure you branch before you commit any site-specific changes.
There are a couple of articles on branching/merging that I have used in the past that might help you out:
Streamed Lines: Branching Patterns for Parallel Software Development
MSDN Branching and Merging Primer
However, there are some aspects of your 'two questions' that are a bit confusing/concerning. Hopefully I'm misinterpretting what you've said, but keep the following in mind:
With your first question, I think you might be getting caught up on the physical location of the source code on your development machine and how your repositories will be structured (hint: treat the two separately).
In your second question, you mention specific references and it sounds like you might be thinking of making your API in some way dependent on the website source (hint: bad idea for an API).