I want to divide my app in two namespaces, Cms and Front. Based on that I will have for example scaffold in Front named User which will handle users data of those who register in service. But the thing is, that in Cms I would also like to have acces and be able to manage users like block action, delete, resend invitation, send email etc. .
What would be the best solution for that. Should I make two separate scaffolds one in Cms another in Front and handle with them the same table in DB or should I create some Module to handle common actions for both namespaces ? Of course for each namespace I will have different DB prefix, how to work it around ?
just don't add a namespace for the common stuff. or you could also add a Common namespace to them.
Related
I am trying to create some dynamic forms using Piranha CMS. As far as I managed to learn it is not supported right now, so I'm looking for work arounds or alternatives.
What I want to do now is use the editor from the manager for other users. To be more precise: this is how the editor looks like inside my manager when I want to edit a page
I have a text input and a select, both are Fields and there are many more fields to be used.
I want the sys admin to create a page with a list of inputs like this, which right now are usable only by the admin. BUT make this list of inputs available for edit to other users as well. Is it possible?
I'm not sure how to extract this editor or behavior or even if it is possible. The problem is we really need the admin to be able to configure different form inputs for users as it is the main core of our functionality.
Any help/advice is highly appreciated, thank you!
The components in the management UI is not designed to be reused in the front-end application in any way. The edit models in the manager contains a lot of extra meta data since the UI is completely generic. If you want to build an edit UI in your front end application, and you're using MVC or Razor Pages, the simplest way is to.
Get the generic model instead of your strongly typed model, for example api.Pages.GetById(...) instead of api.Pages.GetById<T>(...).
Loop the available fields in your selected region (a region is an ExpandObject which can be casted to an IDictionary<string, object>).
Use the built in support in Razor by calling #Html.EditorFor(...) for the fields.
Using this approach you can easily create your own EditorTemplates for the different types of fields you use that will match the rendering in your client application.
Best regards
Håkan
I am working on a struts 1.3 web application that has 2 interfaces one for regular staff and another for probationary staff. These can be looked at as 2 modules having some interfaces in common and some others that are different.
Instead of putting authorization rules on the application, I was wondering if I can control access to some resources using multiple configuration files. I need to implement the following behaviour:
For urls like /application/regular/* the application should use the struts-regular-config.xml file to work out the mapping.
For urls like /application/probationary/* it should user the struts-prob-config.xml file to work out the mapping.
So effectively I need the action servlet to work with 2 different config files one each for the 2 url-patterns that I have.
How can this be done? Many thanks in advance.
Try This Approach Instead of creating different/multiple URL pattern and URLs for different users.
Use the same URL for all the users.Divide your Projects into modules and sub modules using AJax tags.
Create one new Class RolePermission which will define Roles and permission for Different Users. For eg, whether User A has access to Module X or not.
Also use this parameter/fields like RoleId, RoleName,isAllowed,securityGroup for defining RolesPermission.
I'm building an API centric web application.
Our frontend will consume the API and after testing our plan is to release the API to the public.
I'm faced however with problems that in a normal MVC application were pretty straight forward but I can't seem to wrap my head around it in a RESTful way.
Take this example for instance:
A company has multiple office sites which point to a specific address
This address can be shared by multiple sites so Company has a one to many relationship with sites and sites has a many to one relationship with Address
When you update an address I'd like to let the user confirm that for that they either want to update the LOCATION (so all companies that share that location through Site will be updated) or they just made a typo and want to create a new Location
How would I go about this in a RESTful way?
I can do a
I first do a GET if there are other companies using that location
Then I give the user a choice either to do POST (create new location) or do a PUT (update location)
In case of POST also create a new Site linking the new location to the Company.
An other example is if what appears a single form for the user will invoke several different backend entities that have to update.
Any examples or ideas?
In REST, you might thing of the remote service as being the database. If you know how to do it in a generic MVC workflow, for fat-client apps it's the same.
You may want to deal with it on a "try default behavior, and raise attention if not possible" way, or with a "check what's possible and then offer possibilities". It's your app, it's your choice.
Personally, I'd go with a "try default and raise error if edge conditions happen". So in this case, assume (in the client) there is no other company with the same address, and use the corresponding endpoint (PUT). If the server detects a possible conflict, then return some error. The client will then prompt to the user what to do, and use whatever endpoint is chosen (POST or PUT, with a flag that enforces the update)
The client I'm working for has a CMS written in Yii. Currently a part of their business is customizing the CMS to meet the specific needs of each customer. About 90% of the code is reused, essentially by copying and pasting from one directory to another. While I've been working on this project, I've had to merge changes in to the shared codebase several times.
All, or most, of these sites are hosted on the same server, and it would seem that it would make more sense to have a single login, that changed what features we showed based on the login. In some case that means overriding whole or partial views (eg, the _form.php might change from customer to customer) including the controller and model. Most of the time, it means adding a new controller for a bit of functionality written just for that client.
I've read about having both a front and backend site here: http://www.yiiframework.com/wiki/63/organize-directories-for-applications-with-front-end-and-back-end-using-webapplicationend-behavior but that doesn't seem to be the right fit (I don't want everyone coming to a different start php file, for instance)
Ideally, I'd have users log in, and get assigned a site id, which will filter data in the shared MVC objects, and will add in the ones specifically for them, or override the ones where necessary
Intuitively it seems like something like this would make sense:
Shared controllers go here:
/protected/controllers
Overrides and additions for client1 go here:
/protected/controllers/client1
or:
/protected/client1/controllers
But I'm not sure how to get Yii to do this in the most efficient and easy to manage way. Is this something that's going to work with Yii, or am I breaking it in ways unintended? If it will work, what's the best way to accomplish it so that it's clear to me six months from now, or some random developer who replaces me?
Do you know RBAM ?
With Role Based access you can profile your application in more-or-less granular way
I'm a new REST convert and I'm trying to design my first RESTful (hopefully) api and here is my question about addressing resources
Some notes first:
The data described here are 3d render
jobs
A user (graphics company) has multiple projects.
A project has multiple render jobs.
A render job has multiple frames.
There is a hierarchy enforced in the data (1 render job
belongs to one project, to one user)
How's this for naming my resourses...?
https:/api.myrenderjobsite.com/
/users/graphicscompany/projects
/users/graphicscompany/projects/112233
/users/graphicscompany/projects/112233/renders/
/users/graphicscompany/projects/112233/renders/889900
/users/graphicscompany/projects/112233/renders/889900/frames/0004
OR a shortened address for renders?
/users/graphicscompany/renders/889900
/users/graphicscompany/renders/889900/frames/0004
OR should I shorten (even more) the address if possible, omitting the user when not needed...?
/projects/112233/
/renders/889900/
/renders/889900/frames/0004
THANK YOU!
Instead of thinking about your api in terms of URLs, try thinking of it more like pages and links
between those pages.
Consider the following:
Will it be reasonable to create a resource for users? Do you have 10, 20 or 50 users? Or do you have 10,000 users? If it is the latter then obviously creating a single resource that represents all users is probably not going too work to well when you do a GET on it.
Is the list of Users a reasonable root url? i.e. The entry point into your service. Should the list of projects that belong to a GraphicsCompany be a separate resource, or should it just be embedded into the Graphics Company resource? You can ask the same question of each of the 1-to-many relationships that exist. Even if you do decide to merge the list of projects into the GraphicsCompany resource, you may still want a distinct resource to exist simple for the purpose of being able to POST to it in order to create a new project for that company.
Using this approach you should be able get a good idea of most of the resources in your API and how they are connected without having to worry about what your URLs look like. In fact if you do the design right, then any client application you right will not need to know anything about the URLs that you create. The only part of the system that cares what the URL looks like is your server, so that it can dispatch the request to the right controller.
The other significant question you need to ask yourself is what media type are you going to use for these resources. How many different clients will need to access these resources? Are you writing the clients, or is someone else? Should you attempt to reuse an existing standard like XHTML and classes/microformats? Could you squeeze most of the information into Atom? Maybe Atom with some extra namespaces like GDATA does it? Or is this only going to be used internally so you can just create your own media types, like application/vnd.YourCompany.Project+xml, application/vnd.YourCompany.Render+xml, etc.
There are many things to think about when designing a REST api, don't get hung up on what your URLs look like and you should really try to avoid doing "design by URL".
Presuming that you authenticate to the service, I would use the 1st option, but remove the user, particularly if the user is the currently logged in user.
If user actually represents something else (like client), I would include it, but not if it simply designates the currently logged in user. Agree with StaxMan, though, don't worry too much about squeezing the paths, as readability is key in RESTful APIs.
Personally I would not try to squeeze path too much, that is, some amount of redundant information is helpful both to quickly see what resource is, and for future expansion.
Generally users won't be typing paths anyway, so verbosity is not all that bad.