I am using Yii2 advanced template and trying to move my existing Yii-1 app inside a Yii-2 app. My goal is that Yii-1 runs as it is, without any changes. Then I can move individual functionality from my Yii-1 app into Yii-2. Thus I can selectively migrate from Yii-1 to Yii-2
Is this a viable approach?
Is there any other way to move from Yii-1 to Yii-2, in parts?
For reference, this article describes the opposite of what I want to do i.e. put Yii-2 in Yii-1
Have thought about this as well. Think there are issues with combining the two though. For example user authentication. Will the models and controllers pickup the authentication from one framework and be able to use it in the other. Have not really seen any documentation on these types of questions.
Related
So this past year I have dived into professional web development using laravel, and the journey has been amazing, with stackoverflow helping me tremendously. This question is more of an opinion rather than me asking how to do it. So, I'll break it down with an example.
Suppose I am creating an articles website. For the articles, I create a migration, model, controller and then views. For migration and model, it only requires one set of it because only one table exists for it. For views I have separate folders for admin panel for backend and frontend. Usually in the routes I'll create a group for backend with prefix of admin and auth guard which comes built in with laravel, though in the newer versions of laravel you gotta do composer require laravel/ui. Now, because I have different routes for both backend and frontend, logically what I do is create a completely different Controller for the backend with all the CRUD functionality, and for the frontend I make a separate controller and put index and show function in it.
Is this the best way to deal with it, or is there a more efficient way of handling the backend and the frontend? Also, is the basic workflow of development usually the same as I have mentioned, or do you people have a different take on how to do these things. Please let me know.
Cheers :)
In most projects, frontend and backend, are two different environments with different needs, so using the same controllers would be inappropriate as it might lead in complex - no-clean code.
What works for me best, is to separate the controllers in the following groups:
Frontend
Backend
API
In some cases you might also need a group for the controllers handling the ajax/async requests, i.e. Async group.
I want to build a project with 3 section: API, Admin, and User.
I will build the API using Laravel, Admin and User will using ReactJs (SPA) with this route:
api.example.com (api)
admin.example.com (admin)
example.com (user)
I need a solution about project management.
Is it better to separate those 3 or should I combine it into one
project (laravel)?.
What about teamwork if I combine or not?
Any drawback if I combine or separate those?
Thanks!
Unless you have overlapping functionalities, I would suggest that you separate the three with three different projects.
The benefits are:
One project breakdown will not affect the other
You can have separate developers working on different sections and they won't have to worry about conflicts/commits not pertaining to their code
It will help you create separate documentation for the three, which will be easier for someone new to the project
From a security perspective as well, if one application gets compromised, the others won't be
However these also get influenced by personal experiences, and specific project requirements. Experience is the best teacher.
We are building a intranet web application in PHP with CakePHP.
However we have barely experience with CakePHP
Our Intranet will have two user portals.
Employee portal
Client portal
Both portals will use the same data but have their own user interface.
Employees can see other data than clients and vice versa.
We want to build a central core for both portals. For example, a single authentication system, a contact form, a notification functionality, same footer information, etc. We want to use this central core as much as possible so we don't have to rewrite code.
We use Git to manage our code. We want to make a branch for both portals and one for the shared core.
We hope you can give us some advise about how setting this up with CakePHP.
Is building multiple app's a good idea?
Or should we just run CakePHP and our core on two web servers? (one for each portal)
Or should we use plug-ins for the core functionalities?
Or should we use single controllers with multiple views (one for employee and one for client?)
Or something totally different?
Thanks for any advice
Eventually, you'll start noticing similarities between the 2 portals, and the code-base. If they are sharing same data, why don't you have a single code-base and have permissions around what users can see based on roles? We had to do this recently when we merged 3 pages into 1. 1 page was for admin, and the other 2 was for other roles. Then users started requesting features on page 2 that page 1 already has etc etc. it became a mess and we decided to consolidate these pages into 1, and have permissions around what each users can see based on their roles. Also read more about helpers as it will come handy, so you dont make your view bloated.
In my experience a portal is typically a very thin layer on top of some CRUD framework. I think the opportunity for code sharing between these two applications is very limited. You can share the authorization and authentication .. and that's about it and I don't know if sharing this part is a good idea (probably not).
If most of your code goes into building the HTML views you'll likely end up with two completely separate views for employee and client.
As Ayo mentioned... the permissions alone will separate the two user groups and you can take advantage of CakePHP's layout or the themes feature to give a totally two different look for each user group.
You may also want to take a look at CakePHP plugins feature. It allows you to easily add new functionalists to an existing app, without messing with the existing code base.
I am looking at suitable architecture for a Codeigniter based application , the requirement is such that end of the program I must be able to reuse certain modules , completely.
I was looking at a solution like HMVC.
I need to know if this is the best solution for my problem.
To build a set of independent modules that can be reused with minimal changes.
Regards,
Gayan
At what level do you want to reuse "modules"? For example, the models that you create could be reused on a different web application, since they will simply be an interface between your web application and the back-end database.
If you create REST web methods using a framework such as CodeIgniter REST Server, those methods might also be at a suitable level of generality that they could be re-used as well.
I suppose the next question is, do you need and entire 'module' of code that can be copied out of this app and pasted into another one? If that is what you are looking for, then HMVC would be the final piece of the puzzle that you can use to tie everything together - just create this general code within one or more modules.
Does that help at all?
This might be an obvious thing to you but - even after reading through a lot of manuals and blogs - I'm still not sure what exactly should a bundle in Symfony2 represent in a webpage. And it's hard to guess it from the simple demo applications.
For example: I have a site which is divided into two parts (one is just a 2nd level domain like example.com and another is dom2.example.com). Each of these two parts has some sections of it's own - sometimes the same (like news) sometimes different.
What would the correct representation of this in symfony2? Should I have
a MySite\site1 and MySite\site2 bundle and do the different sections via different controllers, or
bundles Site1\News and Site2\News, or
bundles MySite\Site1News and MySite\Site2News etc.
...or am I getting all wrong at this?
I am also new to Symfony and will follow the results of this question with interest, but for what it's worth, my take on it is:
A bundle is just that: a group of files, assets, PHP classes and methods, tests, etc. The logic of the grouping can be anything you like. In some cases, it's really obvious what the grouping is and why it's been done -- for instance, if I wrote a blog system for Symfony2 and wanted to release it, I'd make it into a bundle. That's the sort of example used most in the documentation.
But you'd also use bundles for anything you wanted to release as one little feature. Say for instance, this bundle which creates default routes for all your controllers. It's not a fully developed plugin/feature like a blog or forum, but it's a bit of code that I can easily import into my project, it stays totally separate from everything else, it's a bundle.
Finally, you'd also use bundles internally to your project, in absolutely any way which makes sense to you.
My take on your specific situation:
Quick and easy:
MySite\MyCode -- gets the job done, and maybe you don't have any logical way to break up the code you're going to write.
If there's some more unique features between the two sites and you want to separate them out for clarity:
MySite\SharedFeatures
MySite\Site1Features
MySite\Site2Features
If you really like everything in its place, or if you have a complex project, maybe:
MySite\MySiteMain (shared features and catch-all miscellany that doesn't deserve its own bundle)
MySite\News
MySite\Site1FeatureSomethingOrOther
MySite\Site2FeatureSomethingOrOther
I definitely think you want to stick to logical groups of code -- so I think your example "bundles Site1\News and Site2\News" and "MySite\Site1News and MySite\Site2News" wouldn't be the best way to go. Site1 and Site2 are implementations, so making a separate bundle for each site's news page would seem to be counterproductive to me; you'd want to make one news component and build it to be used in two different ways.
As for your two-domains question, you can either point both domains at the same code, and test within your code for what domain is being requested, or you can check out two copies of the same code and change the configuration files slightly (this doesn't necessarily violate the idea of DRY because you'd still edit the code in one place, then update both copies.)
The way I understand a bundle is that it is similar to what CMS like e.g. Typo3 or Drupal call a "plugin". So it should be ideally self-contained and written in a way that it can be used on other projects too.
E.g. in your case I'd create a "staticHtmlBundle" that contains all the static pages of your website, divided within by site.com and dom2.site.com.
Then I would create a "newsBundle" that contains all the news-articles, maybe even database-driven with a little admin-section where you can edit them and assign them to different channels (in your case that is site.com, dom2.site.com). A static page from within staticHtmlBundle would call newsBundle and display its data (like e.g. a listView of the news or a detailView and so on).
If you keep everything as abstract and reusable as possible then you could even publish the newsBunde in the Symfony 2 Bundle repository and share it with the community!
The way I perceive Symfony2 bundles is that they are provide a modular system which allows you to not only extend and override the php code, but also any resources they may or may not include.
Having said that, consider you have an API and you would like to transfer an object.
How would you do that?
Of course, you can do that manually, but wouldn't it be nice if Symfony can do it for you?
My way of doing this would include 3 bundles, JMSSerializerBundle and FosRestBundle.
One bundle for the client side - MyCompany/ClientBundle
One bundle for the server side - MyCompany/ServerBundle
One bundle housing all the data transfer objects I would like to be able to transfer - MyCompany/CommonBundle.
Inside my MyCompany/CommonBundle I would have the classes I would use for my data transfer objects along with the serialization rules I would have to provide the JMSSerializerBundle with. They may be in the form of xml, yml or php annotations.
Once you have an object filled up with the data, you can just use return and FosRestBundle would serialize it for you. Serialization would depend on the routing, so you can have the object serialized in XML for one system and in JSON for another. Key point is you have different serialization formats and versioning you can utilise at later point.
On the client side, you can use simple param converter to convert the received JSON or XML to an object right in the controller with no additional hassle. You can also type in some validation rules, so you can verify if the object is populated as you expect it to be.
In my example, the MyCompany/CommonBundle has objects that would be used by multiple applications and would be identical. Having that as a separate bundle helps you avoid code duplication and makes long term maintenance a lot easier.
I hope I managed to explain this. Any questions?
Ask in the comments. Will update the answer accordingly.