With our little developer team, we are currently working on a web project quite sensitive. We use Git as version control system.
Also, we're using the MVC pattern, so our files are separated into 3 parts (views, models, controllers). We are using the laravel framework so our views is a combination of PHP, HTML, Javascript and CSS code.
For some views, the Javascript and CSS code are directly into the view.
Now, the project is growing and we need someone to help us to do some beautiful pages with CSS. But his objective it's only to deal with CSS and nothing else.
Regarding tools that we are using, is there a way (or some best practices to apply) to give him an access to do correctly his job without give him all of our sources?
I'm thinking of tools, code refactoring, or anything else that can help us to keep our business logic away of external people.
If you want to only give him access to part of the project, but still have his updates automatically reflected on your build, you could go for a solution using get submodules.
If he will really be dealing with CSS only, then make the public folder as a separate repository, and have it included in yours as a submodule. If he needs to have access to the HTML as well, which is very likely, make another for the views folder. While he still gets access to the view logic, that's probably not a big problem.
Use git and make a new repository for static pages and give the external people access of only static pages repository
Related
I have an existing website running on PHP, MySQL CSS, JS and Ajax.
For future projects, I would like to use the Laravel framework to create new pages or functionality to the existing website... let's say a blog, for instance.
Is this possible?
Is the Laravel framework compatible with an existing website that is not set up using the MVC framework?
The reason is that I would like to make my work easier and more efficient and the use of a framework would be helpful.
Please let me know if you need any other info, I know the question is a little broad.
Thanks,
Justin
yes it's possible but of course maybe with difficulties.
you should put your web files in /views directory, convert your php files to controllers or library files and put your assets in /public directory.
then you can assign routes to your controller and call it form outside of the application.
main job is put your code into controller or libraries. is it possible to split your code into separate logical units? and extract model logic (as php mvc says) from your main code.
so if you have a clean code with good design and minimum dependencies you can think more about it. this could be a good challenge if you go through it cautiously. be careful to not fail and waste your time.
I have write permission issues on my hosting account. Would it be ok to add script and link tags in the Layout file instead of using AssetBundle or registerJs?
What are the advantages and disadvantages?
EDIT:
I'm using Google App Engine, without cloud storage access. Registering an Asset Bundle creates new directories which is not allowed on App Engine. I know the advantages of Asset Bundle, but my focus is on finding out if there's anything WRONG with the <script> tags, the accepted answer is perfect answer to my question.
Separating frontend logic (js scripts) from layout have several benefits from my point of view.
Reusability. You dont need to copy-paste your scripts, just add them as dependency in AssetBundles.
Ease of modification and expansion. If asset dependency changed somehow, you dont need to make changes across all views, just do it in one place.
Automation. You can't use tools like Gulp, Grunt, Webpack with inline scripts.
Maintenance. Managing dependencies in one place and having all frontend code in one centralized location is much more convenient.
Caching. Scripts injected directly in html code are never cached.
The documentation don't affirm that the direct assign of script or link tag is wrong .. the doc affirm is preferred and that is often preferable .. This because the assetManagement make these assigmenent indirectly and the indipendent by specific position and location .. The single asset
allows you to keep all the necessary dependencies neatly organized on the same side configuration ..
Another possibility is the use of registering script (see..)
I'm interested in cleaning up my codeigniter applications folder (just to clean up the clutter). I've seen a few applications that only include the important folder (ex. controllers, models, views, config) and do away with alot of the other stuff (like logs, hooks etc.)
Does someone know which folders can be deleted and which are required?
Thanks
Consider that this "clean up" won't bring you this great advantages, apart from your personal feelings. Since Codeigniter tries to look into application folders which are named like the system ones (libraries, core..) before going to search for those folders inside the "system", I don't think it will be painless to remove them; you might try, though, and just keep those which, very likely, contain somethin: config,controllers,errors,models,views.
Another thing you could do, and which will free more "space" (are you worried about file count?), is deleting unused/unwanted helpers and libraries (from the system folder); the ones you are damn sure you don't use and never will in the future (like the javascript library, for ex, plainly useless, or the smiley helper...You got the point).
All in all, apart from the feeling of "having cleaned up your workspace", I don't really see what benefit this will bring you. But, if you really, really feel so strongly inclined to, make a back-up copy and start deleting, you can always put them back if CI yells at you.
Each file and folder in the CodeIgniter Application folder is an extension of the whole CodeIgniter framework in one form or another, and should not be tampered with. CodeIgniter is a light, fast framework, and should not need any other "modifications". If you'd like to play around with CodeIgniter though to try out any "improvements"; I'd check out their page on GitHub, view some commits that may be related to your question, and play around with it yourself on your own machine.
The framework is setup so you can develop your applications and update to new versions of code igniter without breaking said applications. You don't want to start messing with the actual framework that's just asking for random errors.
if you are trying to make it as lite as possible just auto load the libraries and helpers that you require directly into the controller where they are needed.
-L
I have a little specific concern, I hope you can help me, I have to develop an application in PHP that doesn't need to be linked to the exclusive use of its installation and could be used or "included" in other projects of PHP, I mean, to develop a web application (such as generation of a graph according to certain parameters passed) that can be used on different pages created for example in phpBB, Drupal, Dreamweaver or PHP Frameworks like CodeIgniter and Zend.
The best example of what I mean is "Google Charts Tools", you just print in the browser the access to the tool with the parameters and the tool does the rest, and this does not depend on the type of framework with which the home page was created.
In short, I'm looking for a framework or lightweight framework with which I can develop an application that simply could be called in an include() or require() on the destination page and can be used, a framework that can somehow "export" the project or application and could be used on one page without having to reinstall the framework on the target server, even the libraries could be included in the target page so you can run the application.
Was working with Codeigniter and tried to attach to a Joomla page but i couldn't because Codeigniter is linked to the URL of the page and I dont want to use Iframes.
Is there something like that?
First of all; I believe you would need some custimization, as frameworks just aren't build that way. But it isn't impossible. In Kohana for example (also codeigniter, but kohana is more flexible), you can build internal requests with Request::factory($uri). If you can find out a way to bypass direct access to index.php, or build a wrapper after which you can do stuff in the Kohana 'environment' you could do it. I don't have a ready-to-use solution, but if you try something and post the code we might be able to help you out some more!
Sounds to me like you want to write a library or class that can do certain things and which can be reused in other code. You can then build an example application around it, using a framework, which uses this library.
If you start with a whole framework, this often makes it really hard to reuse any part of the code, since the framework has certain assumptions or requirements which may not always be true for other projects. As a general rule: a framework is already a complete standalone application. What you want is something smaller than that.
Of course, you can have a look at a framework like Zend, which is basically just a loose collection of individual classes. Together they form a framework, but each part of it is individually usable. Something like CI is on the other end of the spectrum, much more heavily coupled and interdependent.
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).