We have a project on Silverstripe which has some well defined processes for the /admin/ section:
Do a thing
Then do another thing
Then do a third thing
I was wondering if there's existing functionality in Silverstripe (or a module) that enables this sort of behaviour in the /admin/ section?
ModelAdmin automatically generates an interface for editing/ managing models - but in this case we need to guide the site administrators through the 1-2-3 process, which involves a number of different models.
Any ideas would be appreciated.
Related
I'm very new to symfony, but I'm sure it will help me to develop faster.
So here are my basic problem. I want to develop a application, that can be used by multiple clients. They will all have its own url. Something like this:
http://example.com/customer1
http://example.com/customer2
I see, that this is very easily done by editing the routing.yml - thats very cool stuff
app:
resource: "#AppBundle/Controller/"
prefix: /{customer}/
type: annotation
In the AppBundle, I can build the whole app within the controllers and symfony offer me the framework to do. It will have some editing routes, admin routes and much more.
But what if the any user call http://example.com/unkownCustomer/someSite
If a someSite route is defined it will cause a problem, just because there is no valid customer. Sure I can handle it, on each Action, but that isn't very smart. I was thinking about extending the Controller class from symfony, to add some base funktionality for example extended the render method to add some basic stuff like customer settings for example the customer name to add it automaticaly in the parameters array for twig, that I don't have to do it explicit in every controller. I think some security features also have to be implemented more generally, that one authenticated user that have a role don't have this role on other customer sites or is not authenticated.
But how I can inject some code before I run the action functionality targeting the route? And the big question - what should be the right way to do? Do have to change my mind doing this thing in symfony?
PS: Sorry for my poor english - hope you will understand my problem.
I learned a lot in the last 2 days - and that video completly answer my question in a very good way doing it in a it think right way!
https://knpuniversity.com/screencast/question-answer-day/symfony2-dynamic-subdomains
I'm developing a website which has a public part and a backoffice part. My intention is to have this bundle structure:
Acme/CoreBundle: common entities, repositories, services for both public and private
Acme/BackofficeBundle: controllers, forms, url... etc of the backoffice
Acme/FrontofficeBundle: same for the frontoffice
Then modify the app_kernel so the bundles of one or the other would be load depending on a enviroment variable of the virtual host.
Does this make sense or there is a better approach for this?
Thanks!
I think you should go with a different approach than the one you presented. You don't need to make this clear difference between backend and frontend. You should organize your code using other criterias than "frontend vs backend".
Let's say you have a shopping cart. So you might need some order, customer and product administration. You will have a frontend and a backend. I think the best practice in this case is, if you take the orders, to create an Acme\OrderBundle. Here you will keep everything that is order related. You can keep the frontend controllers in Controller/ and backend controllers in Controller/Backend/. You can create some services for backend area and keep them in Acme\OrderBundle\Backend, but generally your services/forms/etc. should not know about where are they used on, frontend or backend. The controllers should be used to make this distinction. This way you can create a service for order administration that is used on frontend and also on backend, forms that can be used on both ends etc.
I am working on this ASP.NET MVC Project to which i am very new.
I did some worked somehow on normal ASP.NET Web Forms back in days but i am really a beginner in ASP.NET. I developing projects in php for quite time and did never got a chance to try out .NET.
Back To Question:
I want to have two Sections, One for Administrators and One for Front End Users.
I want both Front End Users and Administrator(BackEnd) Users To have Different Themes Different Controller and Different Models.
In Simple PHP i did made base Controller Named My_Controller which extends the main Controller.
And after that i created two more base controllers derived from this my_controllers namely
AdminController
FrontEndController
and moved this based controllers to core directory or library directory.
But How to achieve such a thing in ASP.NET MVC, I am using ASP.NET MVC 5 at the moment.
Currently i just created new project using MVC. and Here below is the Current File Structure for my Project
Also Please Also Share what will be a better approach that making the base controllers for Admin Controller and FrontEnd Controller.
Or having Multiple MVC Projects in a project of a solution. Like HMVC.
But most importantly what is the best approach and how to achieve this admin and frontend file Structure.
Possible Solution 1:
The Good idea might be to use Area Feature of Asp.NET MVC. Area generally used for the purpose of sepration of user base, like in your case Public user and admin user.
Well explained details of area's can be found on following documentation.
http://msdn.microsoft.com/en-us/library/ee671793%28VS.100%29.aspx
Regarding the different themes for Admin and user web app, you can simply use different Layouts. Put two layout inside the View > Shared folder. Then specify layout on each view as below.
For User Views
Layout = "~/Views/Shared/_UserLayout.cshtml";
For Admin Views
Layout = "~/Views/Shared/_AdminLayout.cshtml";
Possible Solution 2:
if your project is big enough to think it will be difficult to handle the Areas later in a single project, you can also split the User and Admin project.
But you should be aware of re-usability of the source code by placing such code (such as Models) in other projects and adding reference.
I hope this solves your problem.
On my symfony app, the time has come to add mailer functionality. Im always aware that that some new functionality justifiably goes into its own bundle. right now i want to add some mailer functionality so a user can check off some options, then send the items to a friend.
thinking ahead, i might also use that functionality in another bundle in this same app, which is a different part of the website.
so im thinking, i might want to put an email controller in its own bundle, but i know the swiftmailer bundle is already doing this, which i will be using.
so in the end im thinking its probably only a few lines of code i will need, and that may be best placed on the controllers of the specific parts of the website i need the email functionality on.
now comes the main reason i thought of making it its own bundle, twig templates for the email body's. do i want these templates dangling around in my other bundles? i guess it would make sense.
any suggestions?
It looks a bit overkill to create a bundle just for a few lines of code.
For your twig template you can put the shared template part inside app/Resources/views, which is shared for all your application. And put domain specific templates in domain specific bundles.
http://symfony.com/doc/current/book/templating.html#template-naming-locations
Whatever your email logic code should be inside a service wrapping swift mailer, like that if you need to switch mailing strategy, for example sending mails using an HTTP API, you just need to change this service, not all your controllers.
If you have some code to share between your bundles, may should you have an {App|Main|Core|...}Bundle containing all your "Single" services, that can be moved later in their own bundle if needed.
Anyway their is many approach for your global question :
You could use a single bundle containing all your business logic and externalize / decouple your technical / generic stuff inside bundles that can be shared between your apps
You could have an opposite approach with one bundle for technical stuff and many bundles for your business logic, may could it be harder to keep it low coupled
Or a mix of both
In my point of view the first approach works nicely for simple applications while second and third can be more domain oriented for bigger apps. The most important is probably to be consistant.
I need to build a system around a concept as follows:
Users have their objects, which are created by managers and by users themselves. Their objects are visible only to themselves. How to do it in broad way? What logic and mechanism I should choose?
I know this question is perhaps too broad but I am quite novice to development.
Your requirements can be easily solved by using the built-in user-folders of Plone.
You need to enable them in the security-part of the controlpanel via yourhost:8080/sitename/##security-controlpanel
(Note: If you are logged in and trying to see the change of the config afterwards, looking for your own urserfolder, you need to logout and login again, because the foldercreation-trigger is the 'first' login).
Every user gets its own folder then, where other users but Managers don't have have access to and additionally have access themselves to items Managers created in their folder, because the ownership of the user-folder belongs to the user.
Preferably set this configuration in your own product (plone-add-on/plugin), to make it reproducable programatically.