The owner of a site that I am working on has asked me to make the About Us page editable (by her, through a web interface). In fact, there are 5 pages in total that she wants to make editable - About Us, Terms of Service, and so on.
In the old implementation, when these pages were static view files, I had all the URLs coded into routes.rb
scope :controller => :home do
get :about
get :terms
# etc ...
end
Now that these different actions are fetching data from the DB (or wherever) it seems like the standard RESTful approach might be to make a Pages resource and consolidate all the views into a show action.
That doesn't feel quite right. Individual resources aren't usually hardwired into the site the way an About Us page is - the contents of the page might change, but the page itself isn't going anywhere, and there are links to it in the footer, in some of our emails, etc.
Specifically, factoring out the individual routes from the PagesController would raise the following problems:
I couldn't used named route helpers like about_path
The routes for permanent pages on the site would be stored in the database, which means that...
maintenance would probably be a headache, since that is not the normal place to keep routes.
So currently I think that the best approach is to leave these URLs coded into routes.rb, and have separate controller actions, each of which would fetch its own page from the DB.
Can anyone share some insight? How do you deal with data that's not totally static but still needs to be hard-wired into the site?
If you are going to allow markdown, I like the idea of a Pages controller and model. If your layout feels like all 5 pages should have a similar feel, then I'd go with one template that populates with the user generated content and appropriate navigation.
My choice would be to set the routes, make the views (including routing), and populate the views with the user generated markdown.
Without knowing more about your site, it's hard to say, but my preference is not to allow users to generate pages that reflect the site identity (About, terms, etc.) unless that's what they are paying for.
Related
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 have my Pages model, views, and controller in the Admin namespace. However, I would like to display the pages at a root level. Instead of admin/pages/[:id], I would like the routes for showing pages to be /[:id]. Is it possible to do this without creating multiple controllers and models for Pages and while still keeping Pages in the admin namespace? If so, what is the best approach and how would you have to write your routes?
As far as I know, and as far as I've tried, I don't think theres a way to change the routes for showing pages to be /:id instead of admin/pages/[:id] without creating multiple controllers for Pages and while still keeping Pages in the admin namespace. Referring "without creating multiple controllers and models for Pages and while still keeping Pages in the admin namespace", I don't understand creating a new model. Creating a new controller will suffice.
For a non-nested resource, changing the route to a root route is relatively an easy task, i.e. say /:id instead of foo/:id
p.s. initially, I did not give your question a deep thought, and skipped the admin namespace part. But, trying this turned out to be fun. I'd really want to see someone post an answer to this (this is one answer where I'd love to be downvoted and pointed towards the correct answer).
I'd like to add a CMS and blog to a web app. One that won't get in the way. There's not a lot of content, but enough that we want non-devs to be able to revise pages and probably add and remove them too.
We have a substantial app that can't be touched by the CMS, not a site that we're migrating.
How have you dealt with this situation?
Would you advise:
Running two apps (a content app and the 'app' app)
Plugging in a light weight CMS
Rolling our own using gems/plugins for WYSIWYG
Details
We'll be adding a bug ticketing and support system later too. Probably built into the app.
We'd like the users of the app to be able to comment on pages and blog posts, file tickets, etc. all from their main account, so it seems to make sense to build it into our app, rather than as an extra app. Love to hear war stories on this.
Should be:
Unobtrusive (Shouldn't interfere with the existing app)
Must not mess with Devise, DeclarativeAuthorization, or Omniauth. We've got extensive user accounts, permissions, authentication mechanisms and groups setup. These must stay.
Lightweight (prefer something dev friendly than feature loaded)
Desired Features:
Basic WYSIWYG for content editors
Lets us handle accounts (with Devise)
and maybe even permissions (with DeclarativeAuthorization)
I've read this similar question, but the author seems willing to have something a bit more intrusive.
Simple Rails 3 CMS Gem/Plugin?
Options Found
Refinery seems to have a lot of features, but at a cursory look it needs a lot of control over what's going on: http://refinerycms.com/guides/attaching-refinery-cms-to-an-existing-rails-application It says it's modular, but it seems like there's a big chunk of non optional stuff in there.
Radiant seems a bit monolithic as well
http://groups.google.com/group/radiantcms/browse_thread/thread/b691cf9ab644a8b2
ComfortableMexicanSofa seems a bit closer to what I want: https://github.com/twg/comfortable-mexican-sofa
Adva-Cms has the right philosophy but appears to be dead. Adva-Cms2 isn't ready
http://adva-cms.org/
Governor seems good, but maybe a bit too young and lean
https://github.com/carpeliam/governor
Conclusion
So far rolling our own, or using ComfortableMexicanSofa seems like the bet, but I'd like your thoughts before I spend a few days messing around with it.
I am now rolling my own blog app and I am kind of newbie to Rails 3. Even like that, in 1 week i have a blog with tags, comments, authentication with omniauth, etc.. my advise is: roll your own. I was having the same doubt and looking for pre-made solutions and I decided to start it from zero and just look for plugins for anything i need.
It goes pretty fast if you know already some rails programming and you use the right plugins. This is what i used:
Omniauth to let users be able to autenticate with facebook, twitter etc.. and leave you comments.
rails_admin: it allows you to manage your blog by going to yourapp.com/admin. It uses devise to create an Admin user (you can specify a diferent model name than user to not to mix it with the users from omniauth or from your other app) and if you have the right models and associations between them you can from there create your posts, assign them tags or categories and also delete comments etc.. its all done in an easy way. For the Text Area that you use to introduce the content of your posts you can associate it with the ckeditor just by adding to the rails_admin initializer something like:
config.model Post do
edit do
field :body, :text do
ckeditor true
end
end
end
And with the ckeditor you can introduce pictures, attach videos, format text, and so on.
Use kaminari for pagination, or you can use will_paginate if you are more used to that.
Using the blueprint framework for styling with css you will save time and have a more standar styling.
Use few jquery lines to insert/delete comments graciously.
And that's all I can remember now. And if it shouldn't interfere with the main app, i would just assign a subdomain for it. So if you go to blog.myapp.com you access to the blog and if you go to myapp.com you access to the app. And you want users from the app to interact with the blog so you should use just one app and have this 2 subdomains pointing at differents parts of the same a app.. take a look at: rails 3 - one app, multiple domains, how implement a different 'root' route for one of the domains?
That's all i can think now! let me know if i can help you in anything else.
rails_admin: it allows you to manage your blog by going to yourapp.com/admin. It uses devise to create an Admin user (you can specify a diferent model name than user to not to mix it with the users from omniauth or from your other app) and if you have the right models and associations between them you can from there create your posts, assign them tags or categories and also delete comments etc.. its all done in an easy way. For the Text Area that you use to introduce the content of your posts you can associate it with the ckeditor just by adding to the rails_admin initializer something like:
config.model Post do
edit do
field :body, :text do
ckeditor true
end
end
end
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.