I am building a small administrative application, and I want to use Backbone.js on the client.
Now I am having some trouble on understanding how I should model my pages. I will give an example.
Lets say I have 2 pages: products, orders.
Now I understand on the products page I have a products model, collection, and view. Same goes for the orders page. That is pretty straight forward.
The problem I have is with the other sections on the page. My application has authentication, So there is a small section with the details of the user, and logout buttons. There is a small section with messages that the user has, with links to view them.
Besides that I have the menu's of the application, and all the pages also have there own small menu.
Now how do I model such a page. I was thinking of creating a model/view for the page. Or do I create small models like menuModel, currentUserModel, messagesModel.
"The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application" -
Justin Meyer, author JavaScriptMVC (quoted from http://addyosmani.com/largescalejavascript/ )
:)
The point of the quote, in your context, is that you should take the approach that you suggested at the very end of your post.
You should build many small "applications" for your over-all application. Each section of the page that you describe - authorization, menu, messages, main content area - should be it's own small set of code that you encapsulate and separate from the rest of the overall application.
Once you have all of these small pieces in place, there are a handful of ways that you can make them communicate. You can use a mediator, as Addy Osmani suggests in that link. You can use an event aggregator as I typically use and describe here: http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/ And there are still other patterns that can be used, of course.
By taking the approach of building many small applications - one for each of the functional areas of the over-all page that the user is interacting with - you'll create code that is properly decoupled, well organized, and easier to maintain in the long run.
Related
We're getting started on a new application that will run on several platforms (web, mobile, tablets etc). The goal is keep the models and controllers the same for all the platforms. Only the views will be changing. For example, if I have Roles view (and RolesCtrl) and Persons view (and PersonCtrl) on different pages (roles view redirects to persons page with role id as query string or something) on one platform, these two views might be combined into a single page (role id should not transfer to person page but to another view on the same page) on a different platform. I understand I can have separate divs and keeping the controllers intact, but since the UI flow is different for different platforms, how can that be handled? Is it feasible to keep the controllers unchanged?
Is this the right approach? Any help is greatly appreciated.
I would suggest proving this out by creating a small project to implement some piece of functionality backed by a service that AngularJS will communicate with.
It sounds like you might have some behind the scenes complications here. I would suggest that if you do use AngularJS to make sure all of the developers are making their HTTP communications done through AngularJS and not try to go work around it.
From my short experience with AngularJS I think it would work fine and may actually make things simpler because of it's easy single application model.
I've a question for CakePHP about its architecture.
I've an application, which will have only two models(products and categories).
I've to make an online product browser. For me it makes no sens to have one controller "Products" and one controller "Categories", because I will have 20+ actions on the Products and none on the Categories.
I've several key functionnalities, can I have one controller for each of those functionnalities? e.g. One Controller "Search", which have action "SearchResult", "AdvancedSearch", "BasicSearch".
We will be several developers on this project and I don't wish we are always all blocked because one is doing some edit on the product controller(and I really don't like file with 1000+ lines of code).
Second question: What is the mecanism I should use to fragment view in several different sub-view?
E.g. For the view of the details of one product, I've a lot of things to display: Pictures section, description section, similar products, review, ... Is it possible to have sub-part?
Thank you very much
For "sub-views" look into Elements, which are just that. They are snippets of view code that can be included in other views. The proper structuring of elements can create some very elegant view/subview relationships.
http://book.cakephp.org/view/1081/Elements
As for your controller issue, it's one I've grappled with as well. From what I see, it sounds like you're misclassifying your actions. Think about alternative taxonomies for the actions you're doing (mixing all the search functions together into a controller is a great example).
Perhaps you should think about controllers as objects that classify various actions rather than aspects of your site on which various actions can be performed (as it seems you're doing). So rather than a CATEGORY controller on which you can search, list, buy, etc., you might have, the product controller (which handles viewing your products either in an aggregate - perhaps by category - or individually), and perhaps a user controller for your users accounts? It's hard to say without looking at your application specifics. Search would then be an action that would be performed on your product.
One thing that I have made the mistake of doing is picking my controllers based on pages i'll have rather than on models. Think about your data (models) and the actions that can be performed on them (actions in the controller), THEN think about your views.
I wish I could give you more specific help, but without knowing your application's specific needs, I can only give you guidelines on how to break down your controllers. Take a look at this question:
CakePHP - file structure confusion - different controllers, or all in same?
for more discussion on the topic.
Hope that helps!
You don't need a Categories controller if you have no methods/actions associated with it. I assume you may want an admin CRUD for administrating your categories?
Regarding searching; your core search functions should reside in the Products model with the various controllers calling the appropriate methods. Basic or Advanced searching on one model in most cases can be handled by one method, its only a matter of more search fields surely?
If you have several developers and are worried about conflicts on the same file you really need to be considering version control like GIT or SVN rather than approaches contrary to a MVC frameworks core methodology. It will cause you a lot less problems in the future.
I believe you question regarding 'sub views' is solved by using elements, which is in effect reusable sections of views.
good luck
I am going to be creating a work order system with three roles
The "client" - The client can request projects to be completed by the worker. The project must be selected from a list of templates and various sub options all referred to as a campaign (campaign types come and go throughout the year)
The worker - The worker must be able to view work orders and mark them as accepted/rejected, work in progress and completed.
The overlord - He/She needs to see stats concerning the activity of the other two types of users.
So.
This is a web app. But a very simple one in terms of logic. Could something like drupal handle this? Or would I have to write my own modules? The other out of the box aspects of drupal make it attractive (admin, user creation, news feeds, etc...)
I have looked at Views and Webforms. Views seems great for querying and displaying data from the work order database (great for a portion of all three roles), but I am not clear as to how I interface with my work order database when creating and modifying work orders.
Webforms doesn't see to be the answer, I am sure I just missing something right under my nose.
Any hints in which direction to look would be great!
Thanks.
If you use a simpler, less powerful CMS, you may save time with the learning curve but lose time struggling with a less flexible framework. Also: Check how active the developer community is when evaluating Open Source software. You'll need support.
Views and Webforms may be tools that you'll end up using but what you're really talking about is work flow. You could build your own work flow with a combination CCK and views, yes. There are also work flow modules.
Are you and IRC user? See: http://drupal.org/irc
I am pretty certain that you can do this with drupal. I would suggest looking into using an easier CMS than drupal for something simple like this. Using something like MediaWiki for this application might be quicker to develop and have less of a learning curve. If you don't mind putting in the time to learn drupal, I think you will ultimately have more freedom.
First of all, don't underestimate Drupal's learning curve. Especially if your PHP and/or programming skills are relatively new. Drupal does a lot of things in it's own way, and it's good to know that way.
Secondly, Drupal is (imho) made first of all for outward facing sites, it can have a lot of stuff just for the users and not for the public, but a lot of its functionality is made for the CMS part of the system. You might consider using a more framework-style system like Zend Framework, which components are a bit more "loose" but also offers less functionality out of the box.
Thirdly, depending on what a work order is and how it should be treated a custom module could be needed. If a workorder has a really simple datamodel, it could probably be done without programming, but if it is complex you'll have to fire up your favorite editor. Don't worry, making a module sounds scarier than it really is.
I don't know how good your knowledge of drupal is, but to me this has CCK and Views2 and user roles written all over it.
Basically, use CCK to create your content types (remember the user reference field might come in handy to assign a node/record to a particular user)
Then create views for each user group (they could be shared, as you can assign them to more than one role type)
Creating a view where you filter the cck user reference field by the user looking at the screen may also come in handy here.
OKAY, there might be a little bit more to it than that, but what you want is doable.
UPDATE: To protect your site from unwanted eyes, check out the site security module as it puts a security wrapper around all of your website.
Views - Create lists - allow access by user roles
CCK - Define your own content types (add your own fields)
I have a small website for a company that have 40-50 product. The site will be in french and English. Each product will have 2-3 different price (based on shipping)
So the standard approach, will be to do 50 (100 in both language) different web page done with an template engine, maybe pure HTML and css coding
The other solution, make 1 page with PHP, get all the product in database and populate that single page, that will be harder to program, but the page will create itself
So the question : what YOU will do, what is the approach you will take
Take in account that the php-database option is a lot harder to make it work first !, all the time worth to get only that small count of product. I have no doubt if there is 2500 products.
Thanks in advance
Based on the 4 great answer, i will go with a database, let make it the right way, event if it a little bit more complicated
two more question,
what will be the code for the modrewrite
what software (web or mac) to populate/edit the sqllite database
I would definitely make the PHP page. If you have to make changes to the product pages, then all you have to do it do it in one place (in the PHP). It can make maintenance far easier in the future.
I would definitely go the single PHP programming route, but I would do a URL Rewrite so that each page appears to be its own page. This will help for SEO, etc.
So the pages might look like this:
http://www.example.com/products/redcar/
http://www.example.com/products/bluecar/
http://www.example.com/products/greencar/
But they actually point to http://www.example.com/product.php?product=redcar etc
Definitely go with the database and script approach. Adding a row to a db is a lot simpler than creating and managing yet another html file. Even with just 50 products, imagine if you wanted to increase the price of your products by 1.5%: with a db, it's a single query process; with static html you're stuck editing each and every page.
Something else to consider is that with a db, you are not limited in the ways you present your data. So as well as single product pages, you can also generate product category summary pages, search result pages, etc.
If you will be involved with this project in the future, OR if the product line will expand and you want to serve the company most effectively, then you should use the database approach.
If you won't be involved in the future, AND you have no experience with PHP and a database, AND you are used to a template engine that makes all this a snap, then I agree that you have a difficult decision.
I certainly would use the database approach; among other things, it would allow the language variation to be handled very elegantly. But that is a reflection of my experience.
I am currently working within a custom framework that uses the database to setup a Page Object which contains the information about Module, View, Controller, etc which is used by a Front Controller to handle routing and the like within an MVC (obviously) pattern.
The original reason for handling the pages within the database was because we needed to be able to create new landing pages on the fly from within a admin interface and because we also needed to create onLoad and onUnload events to which other dynamic objects could be attached.
However, after reading this post yesterday, it made me wonder if we shouldn't move this handling out of the database and make it all file structure and code driven like other frameworks so that pages can be tested without having the database be a component.
I am currently looking at whether to scrap the custom framework and go with one of the standard frameworks and extend it (which is what's most likely right now), but I'm wondering whether to extend the framework to handle page requests through database like we are now or if we should simply go with whatever routing / handling mechanism comes with the framework?
Usually I'm pretty lenient on what I will allow to go on in a "toy" application, but I think there are some bad habits that should be avoided no matter what. Databases are powerful tools, with reasonably powerful languages via stored procedures for doing whatever you need to have done... but they really should be used for storing and scaling access to data, and enforcing your low level data consistency rules.
Putting business logic in the data layer was common years ago, but separation of concerns really does help with the maintainability of an application over its lifespan.
Note that there is nothing wrong with using a database to store page templates instead of the file system. The line between the two will blur even further in the future and I have one system that all of the templates are in the database because of problems with the low budget hosting and how dynamically generated content need to be saved. As long as your framework can pull out a template as easily from a file or a field and process them, it isn't going to matter much either way.
On the other hand, the post from yesterday was about generating the UI layer elements directly from the database (at least, that's how I read it) and not an unusual storage location for templates. That is a deep concern for the reasons mentioned... the database becomes locked to web apps, and only web apps.
And on the third hand, never take other people's advice too much to heart if you have a system that works well and is easy to extend. Every use-case is slightly different. If your maintainability isn't suffering and it serves the business need, it is good enough.