I want to create an admin bundle, that somehow detects other bundles and tries to add them to the menu and to the same RBAC context.
Eg:
AdminBundle defines a route /admin/dashboard, that requires authentication and authorization. There you can see 3 items in the menu, eg: dashboard, config (some config stored in the db), and users (CRUD for users, found in the UserBundle)
Then someone adds a ProductBundle, which deals with CRUD for e-commerce products or something. Somehow, without modifying any code in AdminBundle, we have now a new item 'products', available in the menu in /admin/dashboard
Later on, the products CRUD is no longer needed, so we just delete the ProductBundle, and it automagically disappears from the admin dashboard menu.
How would you go about implementing something like this? Is there any native support for a plugin-like design like this in symfony 2?
I don't know about a full plugin solution but my approach would be:
There is one "master backend" call it MasterAdminBundle for the sake of conversation. This bundle contains a base.html.twig which just helps define the navigation bar of the Administration area and a {% block content %}. It also has some kind of MenuService which displays the menu. I'd have my other bundles register with this service an AdminMenu subclass by way of using the Tag System just as a Voter can register with the Security Context (see here).
In the base.html.twig I'd then likely use an Embedded Controller to render the menu.
Now with this sort of framework in place your other bundles can stay encapsulated by keeping their own admin routes and interfaces:
ProductController would now also have ProductAdminController where you can use a route prefix #Route("/admin") on the class definition. Any routes could then render templates from within the bundle since templates are held under the controller name. Acme\ProductBundle\Resources\views\ProductAdmin\edit_products.html.twig as long as they extend the base.html.twig from MasterAdminBundle and put their content into the content block.
For other things like a dashboard that you wanted to plug other bundles into I'd likely just keep going the same way, create a service in the MasterAdminBundle and use tags to load other classes into it with the data required.
Hope that makes sense, maybe others will have a better solution to this, I'm interested to hear also since this is something I'm trying to tackle at the moment also.
Related
What is the best approach to hide general ui options from certain desk users with lower permission roles? I would for example like to block the create workspace feature (and hide the button) for a certain user role:
Ideally I would like to also hide certain options from the following pane for certain user roles.
What would be the best approach for this. I am thinking of writing some javascript code to manipulate the dom here, but I am wondering what the best way would be to inject something like this and if it is possible to selectively inject that code in frappe framework via a custom app.
I'm trying to build a simple content management system based on the Zend Framework 2. The problem is that I don't know how should the folders structure be like.
Until now I have to solutions in mind:
A. Building a general "Admin" module that has multiple controllers like Login Controller, Pages Controller, Posts Controller, each of this controller with his own actions.
B. Building an module for each component, like: Pages Module that has an adminController an an frontendController.
I'm sure that none of the above solution is the corect one, but couldn't find any solid solution or books to provide one. I've taken a look at gotCMS but noticed that this one i.e, saves all the data like layout views in the database, and this is not a solution.
Though it's a very first alpha solution, I work on ensemble which is what I'd rather call a content management framework.
Ensemble's admin runs on ZfcAdmin. So you can drop in a Blog module which just has a admin controller under ZfcAdmin's route. But you can also manage pages (like texts) with a navigational page structure. All content parts (text, blog, etc) are separate modules.
So I'd suggest you take a look at the sample application and you can check out our blog as well, which just hooks in into ensemble. I know currently the documentation is scarce, but if we reach kinda beta stability we will focus more on docs.
The main benefits for "your system B" is you can drop in modules when needed. They all provide their own config, controllers, models and views. It's easy to install them from a developers perspective (load in composer, enable in application config) and you can easily override any view with your own ones.
TL;DR: choose structure B and have a look at Ensemble.
/edit: seeing you comment on Sam's answer: yes you have to do that. In ensemble, you specify a route config for the frontend and create your admin routes as child routes of ZfcAdmin. For both the frontend as the backend you have separate controllers.
There is no right or wrong when it comes to building something new. Personally I'd go with B. I wouldn't even name the Controllers like you did (I'd break them down a lot more, like NewsAddController, NewsEditController, NewsDetailsController, etc...). Then I'd have an AdminModule that would simply display a new Layout with a specific "AdminNavigation". This AdminNavigation can be filled via the other Modules (i.e. NewsModule would inject it's own administrative Routes into the AdminNavigation via module.config.php)
We are developing a CMS. This will have a template system, so for example, if the admin wants to add a news section, then he will have to create a template for that section, and another one for each news, that is, for instance, /news/:int:/:title:/, but that route will be stored at the database... how can I do it?
You could use a common controller as a fallback route so that it catches all routes that the admin might create. This controller then goes on to read the appropriate template and show the data.
I have a website that has related pages. They have links that point back and forth to one another but I have no integrated system, nor do I know what that would mean.
What is the minimum code that a group of web pages must have to be considered a Content Management System (CMS). Is it that all the settings are in the database and the pages are generated somehow? Is there some small snippet that all my pages could share that makes them a CMS, database or not?
Thanks. I was also hoping not to have to study a giant CMS to see what makes it a CMS . After maybe a basic understanding I would know what I was looking for.
edit: here's why I ask about code. Whenever I have looked at a CMS, and maybe they aren't all the same, I saw that to develop a module you always had to inherit from certain classes and had some necessary code. I didn't know if there was some magic model that I just don't get that all cms makers understand.
edit: perhaps my question is more about being extendable or pluggable. What would a minimum look like? Is it possible to show that here?
edit: how about this? Is something a CMS if it is not extendable and/or pluggable?
I think this is really impossible to say. We all manage content. The "system" is just whatever mechanism you use to do so(dragging and dropping in Explorer or committing content changes via a SQL query). To say there is a minimum amount of code needed really isn't indicative. What is indicative is how often you find yourself making mistakes and how easy it is for a given user of a given skill level and knowledge to execute the functions in the designed system. That tells you the quality/degree of what you have in place being worthy of being called a "CMS."
Simply put a CMS is an application that allows the user to publish and edit existing web content.
In response to the edit:
A "good" CMS allows of extensibility. By using inheritence you can extend the functionality of a CMS outside of the core components provided. That's the magic.
About Extensibility:
Depending on the language/framework you want to build your CMS with, you can load pages or controls(ASP.NET) using command built into the framework. Typically what is being done is a parent class/interface is being defined that forces an module that is to be developed to follow some given standards:
Public MustInherit Class CMSModule
'Here you will define properties and functions that need to be global to all modules being developed to extend your CMS.
public property ModuleName as string
End Class
public class PlugInFooCMSPage
inherits CMSModule
end class
Then it's just a matter of simply loading a module dynamically in whatever construct a given language/framework provides.
Ultimately, a CMS is a system that lets you manage content, so it needs an user interface that is dedicated to letting you easily create, edit and delete pages on your website.
However, it's fairly usual to expect from a CMS to provide a browser-based WYSIWYG page editor, file uploading, image resizing, url rewriting, page categories and tags, user accounts (editor, moderator, administrator), and some kind of templae system.
Without dragging you into a theoretical explanation of what a CMS is and what it's not, perhaps some tutorials on the building methodology of a CMS will help you better understand.
http://css-tricks.com/php-for-beginners-building-your-first-simple-cms/
http://www.intranetjournal.com/php-cms/
A Content Management System is a System that Manages Content. :)
So if you got many pages that share the same layout, you can create a system that stores the content into a database and when a page is requested, it gets that content, merges it with a template that contains the page header, menu, etc.. and outputs the result.
The basis idea is that you don't want to copy HTML pages, and have to edit hundreds of them when you want to change your layout.
Such a system can be very complex, featuring wysiwyg editors, toolbars, version control, multiple user publishing and much more, but it could be as simple as a single page behind a standard loging, that contains only an input field for the title and a textarea in which you type the html content.
I'm building a Zend-based Web app that will permit third-party extensions.
Essentially, this application's database will have a generic "content store." Extensions are added to render different pieces of content in different ways.
Think of a rich mail store: When the user asks for a "Calendar" item, I instantiate a Calendar class (or something) and ask it to render the item's content. The same database might contain "Mail" items, which are rendered by a different class (or whatever). So I'm basically defining a base class with the needed methods to handle content items, and then add-ins are written which inherit from that to deal with specific item types.
Each of these add-ins may need to access its own View files, since each of them will obviously have a different visual layout.
I can't foresee all the content renderers that might be used; new ones will be "installed" (in some fashion) so that my application knows "when I see content with a database type column of XYZ, I'll call the XYZ thing to render that."
Likely, what will happen is this: User will visit a URL for the application, thus triggering an action within a Controller. That Controller will use a Model method, telling it which specific content item was requested.
From there, either the Model or the Controller (which?) needs to call something (what?) that gets the item from the database (okay, the Model clearly does that) and renders it using some predetermined View. This would be PART of a larger page that might well include several rendered items (as in, a list of content items).
So two questions:
What's the best way to architect this in Zend Framework? I do want these add-ins to inherit from a base renderer class that I provide, because very simple renderers may simply need to call functionality from that base class, rather than having any of their own code (e.g., a "Note" and a "Memo" might well use the simplified rendering functionality from the base renderer class).
What's the best way to "register" these add-ins with my application? An .ini file, perhaps a database table? The goal is simplified installation steps for whoever is operating the application - e.g., editing an .ini file is often easier than manually querying a database, although I could also provide an admin back-end UI for new content renderers to be registered in.
I'd implement the Visitor Pattern for this.
Each third-party extension should implement an interface that you define, so that you know you can call a specific method, say render() on any object that is an instanceof that interface.
Each extension then implements its own rendering. Perhaps it utilizes a View partial in the Zend Framework architecture. Or else perhaps it uses some totally different code to render itself as a PDF or something (maybe each extension needs to be able to override content-type headers?).
As for how to register it, check out the Zend_Application framework for defining resource plugins.