Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been given a new task from the client which is basically creating a CMS for actors/singers and the like that client will be selling out to them.
It will basically be a package and would work out-of-box pretty much similar to WordPress, you just hand over to whoever buys it but of course this is not going to be a blogging platform. It will allow developers to:
Add plugins/widgets
Add templates/themes
I thought the Observer Pattern may be useful but I am not that sure about it. What you guys could suggest to create such flexible/extensible CMS in terms of:
Ability to add plugins (for example like WordPress)
Ability to add themes/templates (for example like WordPress)
Design Pattern
Any other things
Observer's fine, but you're going to have to consider going beyond the basic pattern. The canonical Observer/Subject pattern only sends the Subject object to the Observer, nothing else, not even why it's being notified.
Initially, the solution might seem like also including the reason for the notification to the Observer, but then you might end up notifying Observers that don't care about certain notifications. A better solution might be requiring Observers to also ask for a list of notifications they'd like to receive.
But that also presents a problem. In order for the Observers to actually attach themselves to Subjects, they have to be instantiated. Every single time. Even if they'd never be needed. That's silly.
So, we've quickly reached one of the canonical PHP implementations of plugins: "hooks". Hooks use the same concept as Observer/Subject, but the implementation is different in a very important way: the actual Observers aren't instantiated in order to Observe Subjects. Instead, Subjects send a notification to some variety of central repository. This repository is configured with a list of all installed and activated plugins (Observers), and contains a list of all of the events that each plugin wants to receive. Each plugin and notified only when the event takes place, often through a static method rather than by creating an instance of the plugin and notifying it. call_user_func_array and a good autoloader makes this incredibly trivial.
You can therefore create a simple Interface for all plugins to implement. Methods that you'll need include but are not limited to:
Something to fetch data about the plugin, such as it's name, author, official website, version, etc. Human-consumable information.
A method returning the events that the plugin wants to subscribe to.
An installation method, for things the plugin needs to do in order to install itself, such as manipulating the database.
An uninstallation method might be handy as well.
The (probably static) method that will receive event notifications and return whatever data is needed.
Depending on how far you take the plugin concept, you could end up with plugins that have user configurable options. You might need to take that into account. Down that road lies madness and configuration systems.
In order to make plugins effective, you're going to need to place hooks everywhere, and frequently work with end-users to add new hooks where they are needed.
Widgets can easily work in a similar way, as plugins that get called prior to page rendering.
Themes/templates, oh my. You probably have two big options.
Smarty, or a similar template engine. Or your own not-PHP template engine.
PHP templates.
This decision will be driven by your end users. Smarty is incredibly limiting, but if you want to make sure that only approved code runs in a template, it might be a viable option. Furthermore, it's not unsafe to allow editing of Smarty templates right in the application itself.
On the other hand, one of the reason Wordpress templates work so well is that they're pure PHP. They can call any method exposed in the Wordpress API, and even do their own interesting logic. If you expect your end users to be technically minded, or at least technically competent, then PHP templates are the way to go. On the other hand, allowing editing of PHP templates within the application can open up a huge potential security hole if a malicious user gets into the admin bits. You probably want to restrict editing to the filesystem.
While this covers HTML creation, you should also take CSS into consideration. Will your end-users be able to manipulate CSS directly? Will they want to? If your default templates include enough semantic classes, they can probably do a great deal of styling with not a lot of effort, if they know what they're doing. On the other hand, your end-users might not know what CSS is, so they might want, oh, say, color pickers and pre-built color schemes, and a color scheme chooser, and other such annoying things to build. It's probably best to think about those horrors now.
Miscellaneous things.
No CMS would be complete without the concept of drafts and publish states. I don't have any advice for you here, other than code this first. If your customer or the end-users want any sort of historical archiving, managerial approval mechanism, or anything else that makes draft/published anything but a simple state field, you need to know very soon. (I've been bitten horribly by this one. We'd designed the entire system around a simple published/not-published model, and got about 9/10ths through spec building and related prototype code when we realized it wouldn't work and we'd have to do something far, far more complex to actually meet customer requirements. Rebuilding the rough plan was the single largest time-sink we encountered so far.)
Will you use an ORM? If not, be sure to use a proper database interface library. PDO, or maybe something from PEAR, or maybe Zend_Db. You'll inevitably have a customer that will insist that the code runs on Oracle or MSSQL. Or SQLite. It'll be nice to tell them it can be done (with some effort). Plugin authors will thank you for the sanity as well. Don't roll your own.
(Then again, with your rep level, I expect that you're already familiar with pretty much everything I've said. Ah, the things I do to distract myself while thinking about my own set of coding problems...)
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
For the past weeks I can't stop thinking about the architecture of a CMS I have to develop shortly. First of all I want to answer to the possible first questions that you could ask me.
Q: Have you read the similar questions on StackOverflow?
A: Yes, I have. Unfortunately none applies to what I have to ask.
Q: Why would you want to code another CMS???
A: Well, this is a bit of a long answer. Long story short: it has to be closed-source and it has to meet the requirements I need (it won't be 100% a CMS, it's a much more delicate subject - any project developed with it will be somewhere between 60-70% CMS and the rest will be custom code for that project's specific needs)
Tools of the trade:
PHP
Zend Framework (my personal choice; I'm very familiar with it and I won't change it for this task whatsoever)
What I need this "CMS" to be
Developer oriented
Since it won't be a pure 100% CMS it has to be developer oriented - easy to maintain, easy to develop against (more like the feeling when developing on an enterprise level framework)
User/Editor oriented
While working on a project like this one, any programmer might find himself going in a wrong way and not thinking the person who'll work as an editor using this CMS is not in fact a very technical person. This is the part where conflicts happen - if it's not simple to use, yet powerful enough, you will have a lot of problems to deal with.
i18n & l10
I'm almost certain it will be kind of a difficult task to code something both developer and user oriented and if I won't achieve this, I would like to give more importance to the developer instead of the editor. I am aware it's not a good deal to ignore the actual user of the software, but this CMS has to be fast to develop against.
Possible architecture patterns
1. General object
The first architectural design that got me thinking was the following:
I define a general object. The user/admin goes in the administration area and defines the data object he needs. Easy one.
The object page (for example) has a title field, a body field and a slug. It was just defined by the user and now he can create content based on this "data structure". Seems pretty neat, but I still didn't solve some of this architecture's problems.
How will those dynamic objects will be stored in the database? Should I use a dataTypes table, an objects table and link them many to many via objectProperties table?
Or maybe should I serialize them and store everything in the objects table?
Should I give the user the possibility to create new dataType properties and add them to its objects?
How will I i18n all of this?
Isn't too complicated to force the user to define its own data structures?
Will it be too messy if it will have a lot of data structures defined, multiple languages? Would it be still manageable?
2. Extreme developer oriented - scaffold data structures
Today I found myself thinking about this possibility. It would be pretty neat to define the data structure of an object in a yaml or ini file and then scaffold it's database table, model and CRUD. Also mention it's relations to other "data structure" objects to get the right CRUD implementation (think about page data structure and category data structure, for example).
Unfortunately this made me also think about several possible problems.
Will I be able to code such a scaffolding tool on top of Zend Framework? (which is known to be lacking scaffolding if we except the 2 or 3 suggestions made by the community, like this one)
Is too stupid to create 2 tables for each object so I can internationalize it?
Would it be too strict on the user if he can't define new data structures without the programmer?
Conclusion
I'm still very confused on how to approach this subject and what architecture to choose. At this very moment both are pretty challenging in terms of development.
My questions are pretty straight-forward.
If you would have to choose one of this approaches, which would it be and why?
Can you maybe suggest a more interesting pattern to follow, considering my needs?
Just some general advice, if you are really trying to manage free-form content then I would stay away from relational databases for storing your data and go with an XML solution. A relational database has too much structure for something that is purely content oriented. Think of a home page... You have info displayed like: welcome notice, about us, who we are. That doesn't really map well to a table / collection of tables especially when you start adding / removing some of those items. Something with a defined structure, like stack overflow, does map well to a relation datbase however.
Take a look at Day CMS, Apache Sling, Java Content Repository for some ideas.
http://www.day.com/day/en.html
http://sling.apache.org/site/index.html
http://en.wikipedia.org/wiki/Content_repository_API_for_Java
From my point of view more options are always a problem. Users are mostly ignorant, when it comes to complex systems. Therefore I'd stick with the developer-oriented solution. Developer will decide what kind of content can be displayed. Optionally I would allow some kind of "open" content - for power users, allowing complex CSS/HTML/JS. Complex content like photo galleries, user profiles, etc. should not be designed by BFUs.
So to sum up - main feature - creating pages that can be dropped anywhere in the structure (that should be very flexible). If they want user profiles, you can create a new type of page. But at the end of the day, BFUs can do anything with enough time. It depends on the price/time scale. If they can pay for it and need it fast, they will make you create a new user profile page type, taht will be easy to fill. If they are kinda poor, they'll choose to setup all by themselves using normal page and WYSIWYG :D
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Me and my friend started working together as partners , we have decided to make Kick-as* website after website.
We have the ideas written down like 100's of them (yes we are choosing best and easy among them first).
My friend does the layout design and arranging things , and my part is coding and server management.
The little problem i am facing is lack of experience in planing a project. What i do is, I just start the code straight away and along with code I make DB, like when i need a table i make it.
I know this is very bad approach for a medium sized project.
Here at stackoverflow i saw lots of experienced coders. Need to learn a lot from you guys :) .
So can you plese help me on how to plan a project and what coding standard/structure/frameworks to be used (I do PHP code).
Thanks in advance.
Start by defining the scope. Write a paragraph to a page and try to describe your website. A top-down approach would be to start thinking of functionality you'd like to implement and refining it by adding more detail.
A top-down approach (is also known as step-wise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is first formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of "black boxes", these make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model.
http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
There are many other approaches, however.
http://en.wikipedia.org/wiki/Software_project_management#Software_development_process
Again, the most important step is to be able to put your idea in words; before you can adequately do that, I wouldn't even consider starting to write one line of code.
Regarding coding standard/structure/frameworks I recommend zend framework coding standard, MVC structure, and Zend Framework.
A brief guide for a MVC architecture. The idea is tho help you remember ideas (while your brain is steaming code) and have documents for future programmers.
Design the database. Make an ER diagram. Put it in a document.
Briefly describe reasons behind the design for the important issues (why you choose a polymorphic relation, why use this view, what selects you expect that are more trickey etc.). This will change as you code (and there is nothing you can do). Document the changes. To cope with the changes, use a versioning system for the database like rails migrations.
Design the structure of your website (sections, pages, links, page-flows etc.). Document it. (like: "the site 2 sections, this section is made of ..." etc.)
Based on this make a document describing your controllers and views. ( "a controller for articles, with a list view, and article view, also edit and create views but just for admins" etc).
Describe how you are going to enforce authentication and authorization (on controller and view level). Who is allowed where.
Describe how you protect against the main web-attacks (xss, csrf) where required. (example: "i escape all my view variables using htmlentities for xss protection and ...")
Design your models and side functionality (sending emails, background jobs etc.). These will be the bulk of code. Document each and describe the main issues (for example how timezones are to be handled, how this certain model is to connect to the currency service, how that model is to parse and manipulate some crone file, what algoritm you shall use to decide top 5 articles, depending on your app.) Describe what libraries you use, how, and for what purposes (example: "we are to use curl to scrap SO and make rss feed")
Describe how you protect against the main web-attacks where required (sql-injection, xss).
As you code, things change. Your knowledge about the discrete works of your system evolves and you start to improve the design based on the new found enlightenment. Document your changes.
A few thoughts from someone who loves abstractions.
Figure out what your websites will have in common. Once you have identified the main commonalities, look for frameworks or libraries that deal with as many of them as possible (besides filling your other criteria), such as the boilerplate DB code.
For the common features that you can't find any ready-to-use code (they always exist in customized websites) you'll have a chance to write a common library to be used across your websites yourself. This could be a template for your markup, a JavaScript library or a reusable server-side component, or all together.
Based on your description it sounds like you are enjoying great freedom in the creative process (versus getting a requirements spec handed to you and asked to implement it). I'd say don't over plan either, "just starting to code right away" is a lot of fun and not all bad. Experience will be your best friend, and by the time you reach website #100, you'll have lots of it. When building your second website, your experiences with the first one will help you avoid making some of the mistakes you made, and you'll discover new similarities that you did not anticipate in the planning phase. Just make sure to take the time, move the common code to a single library, and go back and edit your first website to use it. Do this a few times over and you will have learned lessons that are worth a lot.
This can probably apply to other extensible content management systems, but I've been working with Drupal. Specifically I created an image sharing web application whose functionality relied on more original code than Drupal core code. I used the WebForm module and point its forms at Custom Pages with hard coded php to have nodes created programmatically and other strange voodoo.
Just before I was done I realized I perhaps should have just made my own module, or should I have?
Even in retrospect it's difficult to tell.
What do you use to decide when a new module needs to be written and when the functionality you're seeking can just be kludged together from what's available?
I have a strong opinion on this, which is that all custom coding should be done within custom modules, with only one possible exception (see below):
I discern three cases:
Completely new functionality - this obviously calls for a custom module that encapsulates the new functionality. It makes it reusable and can even turn into an 'official' contributed Drupal module, if the functionality meets popular demand.
Tweaking existing functionality - for every site, I immediately setup a blank, custom module (named after the site). All custom code used for tweaking existing functionality (be it from core or contributed modules) happens within this module. That way, all my customizations are cleanly separated, which makes it much easier to update the core or other modules without constantly having to reapply my customizations to the updated code (of course one has to check if the customizations still work after the update and adjust or remove them as needed).
Fixing bugs/adding missing features - this is the possible exception mentioned above. If my changes are just a bug fix or an addition of an obvious, but missing feature, I might just do that within the original code, submitting my changes as a patch to the original module, hoping that they will get incorporated in a future release, thus making my changes obsolete.
In my experience, the 'overhead' of separating the customizations from the original code isn't really an 'overhead', as the 'one-off' tweaks & fixes usually stick around much longer than anticipated, and have a tendency to grow over the lifetime of a site. Having them separated from the start saves a lot off troubles down the road in maintenance, as applying updates & security fixes, as well as extending the tweaks will be much easier.
Make a new module when you want to share or reuse the functionality easily. There is overhead in doing so, so if it's a one-off it's not worth it.
What i prefer doing is a full-on search on drupal.org for any/all modules that have the functionality that I require. I search drupal.org & groups.drupal.org (& maybe even the forums) with that module(s) name to see what other folks are saying about it. Lastly, I always check drupalmodules.com to see what others in the community are saying about it.
If I can't find exactly what I need, I roll out my own module. Plynx is right also, if you plan to reuse the functionality, create a new module IF it's unique enough to not exist yet.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I know ASP.NET C# very well. I make a lot of stuff like surveys and custom web applications.
I'm having a lot of trouble wrapping my head around Drupal and figuring out how to do 'special' programmatic things, like searching a list of clients, or creating a web application.
1 - I've been reading books and drupal API but I'm still having a lot of trouble getting started with anything at all. Where does custom code go in respect to pages, modules, snippets...? How do I replicate form X that I did in ASP.NET into a new page in drupal? Etc. It is super hard to wrap my head around Drupal, it seems so large and easy and extensible yet also like it is difficult for me to code. What can you recommend for an ASP.NET application programmer to learn to work with/in Drupal?
2 - Sometimes we write complete ASP.NET applications for clients, and these applications are not indended for clients to go editing them. For example, we will have our entire website in drupal, but inside of that website we will have a place for users to use a special search for database information. We don't want simple website editors and content providers trying to edit this specially coded page(s). How do I handle not wanting clients to edit anything in a Drupal application? Is it handled via page/user permissions? Is the best thing to develop and host an application completely outside of drupal? Is the drupal application it's own drupal instance inside of a drupal website (nested drupals?) ?
3 - Lastly, how do I handle databases? I understand Drupal and PHP are set to work best with MySQL. We have MS SQL databases that are used by multiple applications and would like to use them for new applications as we start using Drupal. For example, we have a Staff directory that feeds ASP.NET reporting application, ASP.NET Staff Listing application, and want to make a new Drupal PHP application that also uses (and perhaps inserts/updates more information into) that database. What is the best/easiest way to handle MS SQL databases and/or MySQL databases being used and updated by multiple Drupal and ASP.NET applications? Would it be easier to have all the applications use the MS SQL databases, or maybe to replicate the databases on MySQL for the Drupal/PHP apps and somehow sync the two databases?
I hope it is alright if I ask multiple related questions in a single post.
I'm afraid that I don't have any experience with Drupal so I can't offer any insights into your first or second questions, but on the third question:
What is the best/easiest way to handle
MS SQL databases and/or MySQL
databases being used and updated by
multiple Drupal and ASP.NET
applications?
If you are going to perform CRUD operations from both your ASP.NET applications and your PHP/Drupal applications, then I would recommend against trying to sync data back and forth between MySQL and MSSQL since this will cause latency problems plus you'll then have to deal with the differences between the two database management systems.
Instead, I would recommend that you look at using stored procedures to control all database accesses. This way you can ensure that all of your database CRUD operations conform to same rules and logic.
Using MSSQL in both ASP.NET and PHP shouldn't be a problem, especially not with the very excellent PDO library that provides a standard interface for accessing a number of popular database management systems. It should allow you to quickly and easily connect with and begin using your MSSQL databases within your PHP applications.
It is some good questions you ask. I'll try to answer them to the best of my ability. I haven't any experience with c# of APS.NET, so I don't know exactly where you are coming from. I myself learned Drupal as an inexperienced python/django developer. So in some ways I can understand some of the troubles you are going through trying to learn Drupal. Some of these things will simply require time/experience/experimenting before it will go away.
To really understand Drupal and the Drupal API you will first need a good understanding of PHP. Sometimes Drupal do some complex PHP things, so if you don't understand the syntax or the PHP functions etc, you can easy get lost.
Where do code live?
Drupal is built as a moduler system. Drupal itself is a set of modules, some of which are required for Drupal to work properly. If you want make some custom code, that is you want to do something, that you can't use a module for. There are about 5000 modules developed for Drupal. Often even when being a skilled programmer, the best choice is to find a module that will do what you need or can get you where close. So what you do, it to create a module of your own.
Make a folder with the name of the module
Create a modulename.info inside it which holds some info about the module formatted in a special way. Drupal will need it to fx display the module on the module list page where you activate modules.
Lastly create a modulename.module file where the core of your code for the module will be.
Another thing that is important to understand with Drupal, is that it uses a hook based system. Hooks are like events that fire once certain things happen that you want to hook into and either alter the flow, or do some things of your own. Fx you could record every time a specific form was displayed, or you could alter the form, adding/removing fields.
Forms
Drupal has a FAIP or Form API, that is uses to generate form, this is something that has it's own page in the documentation. The idea is that you create an associative PHP array which holds information about each element of the form, and Drupal will use that to create the form.
Books
There are a lot of good books for Drupal that you can learn from. The book I myself have learned the most from is Pro Drupal Development
First of all, Drupal has a very fine grained role based permission system, that will allow you to setup exactly what your clients are allowed to do. You can create different roles, like moderator, content creator, admin, sysadmin ect, and give different permissions to each role. This is pretty easy and is setup within the Drupal AI. However, you will need to know the permissions as some are super permissions that will give access to a lot of things. Now for integrating your applications, that is something that you probably want to write a custom module for. I don't know exactly how you want to do this. But I think the best result would be gotten by letting Drupal create the pages, forms etc from your application and just send data back and forth. That way the theme = layout of the site would be consistent. That way users wouldn't get the feeling that they left the site, but this simply was yet another feature the site offered.
Drupal is not just set to handle MYSQL best, You will actually need either MYSQL or PSQL as your drupal database backend. The reason is the way Drupal handles queries, that allow you to write non specific queries that will work, no matter on which of the two types you use, or if your tables has a prefix. So for all of the Drupal internals you will need one of the two. PHP can connect to MSSQL and run queries against that database, so you could without much problems write custom code that run queries to your other application's databases and either fetch or update data. Depending on the data, you might want to create a table in your database that you can read and write to, and then sync the databases when needed. It depends a bit on your use case. I have done the latter, in the case where I didn't need to write to the database, but only needed to fetch some product information form a legacy database that was still being used by other systems.
First of all, I think what's important to understand Drupal's limitations, there are things it's not really made for. It's sort of a web application framework but if you're doing a lot of custom work with your own custom datamodelling and stuff, Drupal might not be the most flexible or easily implementable solution to your kinds of problems. A more general framework like for instance Zend Framework might be more suited.
An important lesson in learning Drupal is: don't hack core or other modules. This will make upgrading core or modules very time-consuming. Instead "do like Drupal" and override using hooks. In theming you can also override with hooks, but also in other ways. Overriding is powerful so understand that concept well.
I'd say, pick a way of learning that is your style, screencasts, IRC, hacking, user meetups IRL, books, articles or any combination and look for material on Drupal. Just start mucking around and get a feeling and understanding of how Drupal works. Understanding the jargon is an important part, so what are: nodes, blocks, regions, hooks, modules, themes.
Drupal has a very flexible permission system, and it's probably the best choice to use that instead of making your own. You can write your own modules that add to or alter the behavior of Drupal. So if you want to write a new application that works with Drupal you can write a module performing the functionality the application has to have and make use of all the facilities Drupal offers, including users, the permission system, etc, etc. I don't really understand the last part of your second question "Is the drupal application it's own drupal instance inside of a drupal website (nested drupals?) ?". Drupal is a collection of PHP files on a server that, together with a slew of tables in a database serves request made to it. Multiple Drupal websites (so different PHP files) can reference the same database or parts of it (for example the user table). There's not really an "instance" of a Drupal site, as there's not really an "application". I could of course be too unfamiliar with these terms but I don't think PHP works with "instances" of "applications".
That's a hard problem, afaik Drupal doesn't work with MS SQL, so any connections in that direction you might have to make yourself. I'd also ask around the Drupal forums or on IRC.
Good luck!
rlb,
I've done quite a bit of Drupal and have strong ASP.NET experience. You really need to read up to get your mindset straight. They use layers in an MVC-like fashion that is very foreign to WebForms & ASP.NET MVC developers ... and quite frankly at first seems odd.
Here's a list of things I did to get really, really good quickly:
Get a host like at hostgator for $8 which will let you install Drupal
Get the book Pro Drupal Development for Beginners ... excellent and really covers a lot of areas http://www.amazon.com/Pro-Drupal-Development-Second-Beginning/dp/1430209895/ref=sr_1_2?ie=UTF8&s=books&qid=1257545528&sr=8-2
Get on the Drupal forums
Be ready to contribute. Drupal has a lot of features, but in the end the best way is to be someone who contributes code back
There are a number of IDEs to consider, but to start a text editor should be fine.
Good luck.
Some good answers here, so I'll just fill in some brief items.
1 - Learning Drupal: Pro Drupal Development is the best book for this. Getting into the issue queues and interacting with developers is a way to get familiar with specifics. Your question about forms relates to how Drupal handles forms. The FAPI is pretty robust in Drupal, and protects you from security gaffes. Also api dot Drupal dot org is where the code is documented, though there are docs elsewhere. Google is your friend. (On the Drupal site itself, use the native search to get faceted results.)
2 - This is a user permissions issue. You can limit creation and editing permissions based on content type. For access control (read), you will want to use one of the many modules for access control. It really depends upon your use case.
3 - Drupal has the most community support for MySQL, but people run Drupal on MS SQL as well. In Drupal 7, you will likely see much more support for non-MySQL as this release introduces database abstraction.
Probably the worst thing to do is hack around the margins. It really pays to learn the ins and outs of the Drupal basics -- administration and coding -- so that you can truly leverage the power Drupal brings to the table.
And if you're hunting for modules, http://drupalmodules.com is your friend. ;)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I’m working on a project and have developed the high level user requirements for what the system must do. This project is a php web application built on the CodeIgniter framework. Now I’m trying to take those requirements and break them down further into controllers/actions. What is the best way to do this?
I was thinking of creating a word document with a table that would have four columns. Column one would be the the name of the controller, column two would have the actions, column three would have the name of the view that is specific to the action, and the fourth column would show which users had access to that action. Does this sound like a good idea?
I like the interface first approach to building an application, but realistically, I need to know what views I need before I can create a prototype interface.
Could anyone help me out with how to plan the app and any documentation that might help?
Your breakdown is a good idea, but it's really the second step.
here's what I'd do:
take your requirements, and turn them into a series of scenarios ("use cases", "user stories").
Pick one, and sketch, like on paper, the basics of the user interface you'd want if you were to have the Good Code Fairy deliver the perfect system to you.
separately go through the scenario, and underline all the nouns in the story; those are probably domain objects. Underline all the verbs in a different color. Each verb is a method of one of those domain objects. (In fact the domain object will be the object of the verb. Cool, huh?)
Figure out how you would implement that user interface using those domain objects.
Build it
Show it to your customer, who will invariably say "I like it but"
Put the changes and things you learned inot your requirements, and repeat until the check clears.
Peter Coad wrote what I still think is really the best beginners book on this: Java Design: Building Better Apps and Applets. It's oriented to Java, but the design part is universal.
Your domain objects are the model, the display of your data is (roughly speaking) the view, and the code attached to actions is the controller.
On Use Cases
The "right way" to do use cases or user stories is subject to immense discussion and religious warfare. There are zillions of options, from Cockburn's somewhat complex form, to notes scribbled on index cards.
For the kind of application you're describing, I do two things: I try to keep them to 25 words or less, and I think about the SMART acronym.
Twenty-five words or less helps keep them small. Doing a few small stories is preferable to spending weeks on a big one.
SMART stands for "Specific, Measurable, Agreement with Responsibilities and Tests." (Or at least that's how I interpret it. There are other versions.)
Specific, you have to be comfortable you know what's being asked.
Measurable, you have to have some way of testing or some kind of statement of what will be acceptable
Agreement, because it needs to be something you and the customer can both agree satisfies a need — in other words, the "meeting of minds" of a contract
with Responsibilities, you have to know what you're being given, what the customer or user is responsible for providing, and what you are
and Tests, in other words, you should have an effective procedure that gives you the answer "it is acceptable" or "it's not acceptable."
The form I use has the pattern
User in a particular role
does something
resulting in some benefit
So, in your example, I would write
Administrator (who?)
lists all FAQs (does what?)
to review them for updates. (why?)
The "resulting in some benefit" part is something I emphasize and a lot of other people don't, or don't even mention. It helps a lot later if you need to prioritize them.
The "test" part is a description of an acceptance test: you're answering the question "Is this done?" So the acceptance test might be
A logged in administrator selects "list FAQ". All known FAQs are listed in correct format.
Ideally, you'd set this up so some tool, like expect or a gui test tool, can run this automatically, but especially in a small projects you may end up testing by hand. You want automated testing, because as you build the system, you want to do regression tests; that is, you want to repeat your tests to make sure nothing has been broken by a later change.
What you do is you work user-centered.
You make rough mockups of the screens (use Balsamiq or something), and show them to your client/stakeholder, and walk them through it (as if they were using it). Get them to agree.
Then you code the thing (I'm sure you can figure that part out)
Then you show to your client again (have them actually use it in detail), and agree on changes.
Now you finish it
Good luck!