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
Related
I am currently investigating the possibilities of different CMSs for a company-site.
Done quite a few projects in classical ASP, ASP.NET, Joomla etc..
I would like to use Umbraco 5 for the first time.
For that project we have a SQL-Table with Job-Opportunities:
like: JobName, Department, Description, etc..
These should be listed on a page. In ASP.NET I would use something like a Repeater, etc.. with PageSize option and automatic paging.
In the Backend (Backoffice in Umbraco, I assume) there has to be an Insert/Edit/Delete Page with the corresponding input boxes, which are maintained by the company employees, not by web-developers.
Which route should I look at? I am completely stuck, is there an example anywhere?
Can I use my own data-tables, or could/should I use the Umbraco content tables for this?
Thank you,
Reinhard
Welcome to Umbraco.
If you choose to use a pre-existing database, you're going to need the following pieces:
an ORM to access read/write the data
a custom hive provider for that data to allow for Umbrace to read it as an entity
a custom tree to allow for editing and adding data in the backoffice
a macro to display the content on the frontend.
http://web-matters.blogspot.com/2011/11/umbraco-5-hive-provider-tree-editor.html
is a great place to start.
As you're probably picking up on, this is a lot of work.. so, most importantly: Are you trying to maintain two applications?
If so, do you really need to be able to edit the list in both applications? Your task would be much simpler if you only allowed editing from the other application, and displayed the read-only list using web services.
If not, ditch the custom database. Umbraco 5 is a full EAV/CR system, so unlike some CMS products, you'll be able to represent any rdbs structure you can imagine. The simplest way would be to create a custom document type with those properties to represent a job opportunity, and store those job opportunities on a new node in the content tab.
About document types: http://our.umbraco.org/wiki/how-tos/working-with-document-types
I currently have several web parts:
EmailValidation
PrimaryDetails
AdditionalDetails
These are currently all connected together using similar logic to this and share a common RegistrationViewModel.
The issue is I use an Interface that holds all the values for the registration process and need these to be persisted across the web parts. In version 1 of the registration process I used a set of hidden values to hold the bits of information in between posts. We were hoping to get away from this approach and wondered if you knew of a tidier way to maintain state of an interface throughout the page calls. The issue is that each web part only has a portion of the fields on the form.
The only thing I could think of would be to store it in session data but a colleague didn’t sound keen on this due to the additional setup for that on all the servers.
Is there a way of getting the connections to maintain state across all posts?
EDIT:
My issue with using hidden fields is simply that on all the web parts I need the 15+ fields so if you add or remove anything it makes maintenance a bit annoying.
Maybe you can put that information in a cookie.
The hidden field solution doesn't seem bad, what is the exact problem with that?
EDIT: based on the problem with the Hidden fields solution:
You can have a class with the structure and serialize it into one single hidden field. If you need to add anything you just change the class and it will be replicated to the whole system. This is something similar to how the ViewState is implemented.
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.
I'm a big fan of keeping application logic in the servlet, and keeping the JSP as simple as possible. One of the reasons for this is that any good web designer should be able to expand upon his HTML knowledge to build in a few JSTL tags to do simple iteration, access beans, etc. We also keep the more complex/ajax/js components behind a tag library (similar to displayTag but for our own components).
Most of the time everything works out ok - The servlet does any SQL it needs to, and stores the results in beans for the JSP to access. Where we have a problem is when the records we wish to access are specified by the design.
The clearest example would be the home page - it needs to be eye-catching and effective. It doesn't need to be uniform like rest of the site. There are lots of one-offs or "special cases" here, where we want to query a particular product record, or whatever.
What the designer really wants is a way to get a product bean by the product id so he can access the properties as normal. We obviously don't want to query for all products, and I don't want to query in the presentation.
I'm pretty sure I'm asking the impossible here and that I have to give something up. My question is what?
EDIT
Am I wrong in thinking that all application logic should be complete before calling the JSP? I was under the impression it was considered best practice to do all querying/calculating/processing in the servlet then pass (fairly) dumb beans to a (very) dumb JSP.
There are a couple of methods whereby the actual complexity of the query can be encapsulated in another class (custom tag or bean), and the JSP can call it. This
keeps the JSP simple (goal 1) but the JSP is still "triggering" the query - quite
late in the process.
Have I got this totally wrong and it's fine to do this.
Is it a general rule, but perfectly ok to do this in this instance.
Might I run into problems?
EDIT - Example
I'm hoping this example will help:
The home page isn't a "template" like the category/search pages - it is custom designed to work very well with say a marketing image and a couple of specific product images. It does however have information about those two products which should be obtained dynamically (so the name, and importantly price) stay in sync with the db.
The servlet can't know which products these will be, because if the designer wants to change them/remove them/add more, he should only have to edit the JSP (and possibly XML as one answer suggested).
If I understand correctly, you have logic in the JSP that wants a particular product, but at this point you don't want to query from the DB, and its too late for the servlet to be aware of it.
(A side note, while I respect your will to maintain separation of concerns, the fact that this is an issue clearly shows that your framework has too much logic in the presentation tier...but since we probably can't fix that...moving on).
My recommendation is that your designer creates a configuration XML file that contains whatever special cases it needs for the frontend, and yours servlet can read that, then pass dumb beans back to the JSP.
OR...you break things down into multiple requests using XMLHTTPRequest and call back to the servlet for each individual query, then assemble the page on the client.
It sounds like you need better separation between the display and database code. You should have separate classes that just deal with interacting with the database, and know nothing about display.
Then you just create a method that will look up the product by id and return that bean so the display can pull out the attributes it wants.
You need to create a custom bean which will perform your queries for the front end. Actually, it's probably more like a few beans to get the data for you, according to what you say here.
There's no problem with doing that from a design perspective; it's just that the specific design of the home page has more heterogenous requirements than the rest of your site. Make sure your designer knows that he needs to communicate his needs well to the development team to create the BO for your homepage (or whatever) and thing should go fine.
You are not wrong in thinking that all application logic should be complete before rendering the JSP.
If there is a need to fetch more stuff for displaying in your JSP, it would be another request to the server and another Page cycle. If you are looking for 'interactive' loading experience, you could use AJAX.
In a single page life-cycle, I find it hard to understand why do you have to invoke database calls from a JSP. Hasn't the page been previously posted with all the required form variables to help you find the data in Servlet/Helper classes?
If you could give an example of a case, it would be helpful.
[Edit] Looking at your example, yes your designer (or the admin of the site) should set that information as a configuration, not a part of JSP. Or, you could have a small app/admin page to maintain the information in a database so that it could be changed on the go. When you show your homepage, read the configs and load the appropriate data.
I am not sure what is the question. I f you want to have sql statements out of your jsp pages then you can put them in a property file and just read the property file from the jsp page.
our application wants to be able to create static, searchable pages based on user profile information, which would be linkable to other public profiles.
I am looking at LinkedIn as an example...it seems like they actually auto-generate the page to be a static file that is indexable and searchable.
Can someone suggest how we would do this? I am thinking there would need to be a cron job that runs and writes a the path and file name.
The user may want to keep the whole page private, in which case I imagine it would need to delete it.
There's alot of sub-requirements but that's the general concept and wanted to start getting ideas and feedback.
Thanks.
You can do without the cron job if you generate the static pages in real time whenever the profile information is created/updated or whenever user changed the setting to keep info public/private. This way you are not constantly looping through all users, and do not depend on another component (your cron job) to be running.
One alternative would be to adopt an explicit RESTful information architecture so that a profile resource ("page") is addressable with a permanent URL. The resulting resource could be a static page. Or not. That would be an implementation detail invisible to the search engine crawler and any web browser accessing the resource.
umnik700's answer is fairly dead-on if you're not considering issues related to authentication or who gets to see what. Consider the difference between the profiles you see when you're logged into Facebook versus those same profiles' publicly facing, searchable counterparts. Even MySpace, with a lot less consideration for search engine privacy, has viewability that is dependent on your relationship to the other person, defaulting, for private profiles, to "This profile has been set to private by the user" or something to that extent.
If you're looking to suddenly scale out a social tool where individuals are eliciting their personal information, I would suggest umnik700's answer (dynamically generate the content, but not the URLs, for public versions of the profile) with the following corollary: you need to be able to support privacy preferences varying from extremely strict to completely open, and default to a version that at least errs on the stricter, more private version of the profile. If you're just now pushing out searchable personal content when there never was any way to find it outside the site before, it's important not to abuse information given under different pretenses.
I know this probably requires maybe more scalability and added functionality than you were hoping this project would take, but to do otherwise could be most likely taken as a violation of your user base's tacit trust. Anyway, the best strategy to do this will probably require you to lean on your database more anyway, so it might be time to rework it a bit--including adding some privacy preferences.