Site Controller Support #116
Labels
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: joomla/Component-Builder#116
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is just a thought that I had for JCB.
I know that site controllers can currently be added using Component->component name ->settings tab->Files.
While this works, I think it would be good to have optional site controllers available within JCB. That way, the headers and copyright info remains updates and current, and keeps all files in the same area for maintenance.
My thoughts on how to add this, since controllers are more or less specialized, it could almost be like custom codes, where you have System Name, then instead of function name it would be controller name. Lastly, there would be the text area, but rather than custom code, it would be controller code.
Lastly, in Component->Settings, add another repeatable field below Site Views called Site Controllers.
When compiled, using Sermon Distributor as an example, if system name for a controller was Preacher, and the controller name was preacher, JCB would "copy" that code into a preacher.php file in the site/controllers folder with the header, copyright, and version info.
This is just a thought on extending JCB another step forward. This came about from my BIG component project, finally getting released this weekend, that has 10 site controller, and it would be nice having them all in a centralized location for maintaining.
Eventually this might be able to be built out more, but just integrating something basic for starters would be a good step.
Okay so controllers are usually there for forms, and buttons. So we did add ways to add controllers to site-views and to custom-admin-views, and even to extend admin-views. Via the Custom-Buttons tab, when you create a custom button, it opens place to add controller methods, and model methods. This way the controllers used in that view is edited in that view.
That way of adding controller custom script and so adding controllers is actually extremely powerful.
Remember the moment you have any custom script in JCB that you are using over and over, use custom coding area, and then just place the placeholder in the actual view or component's custom script area. This way you do not need to repeat yourself, and yet start forming a consistent improvement to all use cases if improving the custom code in the main custom code area.
This is what I have done, I have basic controller methods for various kind of controller tasks, and just pass the dynamic names to the custom code, and so I can place the code in all views were I need, event if I need a call to a method with this or that kind of value, and so safe my self so much time in typing it, or even coping it if I improve it in one place. I then in turn also have methods that are basically doing the same thing over and over in the models... and so I use the same approach.
Custom Coding is one of the hidden features of JCB that can make your life so much easier if you can start thinking of it as a way to do polymorphism inside JCB.
Okay I am getting a little of point here. But I hope you see that we already have a very dynamic, building centralized (in views) controller building concept. That you may over look, if you have not played with the custom buttons area.
You don't need to actually add a button to use the custom scripting areas. But the site and custom admin view actually allows you to add the buttons to your "Default View" area via a place holder called
[[[SITE_TOOLBAR]]]
But if you write the buttons yourself, that target the controller... you can still add the custom controller methods in those PHP areas under the buttons modal.
You do realize that you can call any controller from any other view... so you could use just one view to handle all your controller calls... instead of 10 controllers you can have one. Call the site view API, and then name the methods what you would like to do with your API, and if cross site posting should be checked, if must be a registered use of the site. so lets say I have a method in your controller.
Now the link to this Controller will all around the site will look like this:
<a href="/index.php?option=com_[[[component]]]&task=api.backup">Backup</a>
I am sure you know this, but just for any other that my stumble upon this post.
I saw the custom buttons options, but hadn't really dug into it. Since I'm FINALLY 99% complete on the component (and companion modules), I think I will start experimenting and "playing" with the custom buttons after I have released this. Who knows, once I start digging through my controllers, I might find some code that can be condensed. This main component is HUGE, and even another guy I brought in to write some javascript, said it's a monster of a component, at currently just over 120,000 lines of code, but he did say that it's some of the cleanest code that he's had the pleasure to work with (although he just created some js files for me).