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
Related
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 8 years ago.
Improve this question
Greetings,
I would really love to hear about your broad knowledge about application design on this one!
I'm new to Phalcon, and now building my first MySQL & RESTful-API based application with it, but encountering some challenges along the way.
First, about my application design, the concept is as follows:
An API as a core for the application, wrapped by a "UI shell" of pages and views that utilize it.
The API is supposed to be composed of a set of Phalcon models that represent the DB and business logic, and over them, a component that acts as a layer that makes those models accessible as "HTTP services" - generally by translating requests to model names, and the HTTP verb to the appropriate model action (e.g: GET => $account->find()/findFirst(), PUT => $account->update([params]), etc.).
I was sure that the Phalcon models are gonna rid me of having to write most of my SQL, however, soon I came across some pretty common scenarios that the models couldn't handle the way I would expect:
You have entities like messages for example, and you wish to query them using a column of some other, related entity (like the FIRST NAME of the user that owns those messages). A model can't do this in a single operation.
I want to show a list of messages, each attached with the details of the user that sent it. In Phalcon, the first thought that comes to mind is taking advantage of the model relations feature, but thinking further I came to realize that will perform a full query for every message rendered, which is a disaster performance-wise, rather than retrieving them all together with their user details in some single, JOINed query.
I want to show a list of users, each with a total messages count. Found no other way to achieve that rather than a full query that includes a COUNT() field & GROUP BY or a sub-query.
I tried to look up such use cases and others, for most of them there hasn't seemed to be any elegant solution.
The Point:
What I want to achieve is a API-based architecture that makes sense, scalable and easily customizable to real world scenarios (being able to handle obvious situations like demonstrated above).
What would you do in Phalcon to handle the problems I encounter?
What do you think about the design concept I took? Is it somewhat standard and makes sense?
Most importantly, how would you design a full & flexible API without repeating cumbersome SQL queries everywhere, if at all?
Do you have any references or examples of known companies' approach on this?
That's a big question and any help will be huge!
Thanks!
Dor.
Little disclaimer first: There's no straightforward answer for this question(s), so Stackoverflow isn't the place for them. But since you have put it nicely I'll try to help :)
Almost any modern CMS API has a very similar approach that is very successful and flexible, you can follow their guidelines to implement your own API. I'd recommend storageroom and contentful documentation pages, they have a series of gotchas and patterns that I've successfully added to my own projects eventually.
Phalcon is a good choice for a RESTfull API and a proof of that is the PhalconEye project, a cms built using Phalcon. Once you have designed your API, go check the PhalconEye source code to get some samples on how to implement such things with Phalcon.
Good luck!
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 8 years ago.
Improve this question
I'm trying to understand advanced PHP OOP principles, having programmed procedural Php for years. I wondered if there is a rule of thumb for how best to group functions in to classes and how to plan which classes to abstract / extend? If not, could you recommend any advanced reading that might help.
I have read a few (self-defined) 'advanced' OOP tutorials. The examples have taught me the basics for how to create very loosely coupled objects with very minimal attributes defined in heavily abstracted classes. I've also read other (bad) tutorials which basically turn functions in to methods and encapsulate them in classes - and I know they are not written well so don't want to emulate them.
However, I'm not clear how to decide which classes to build my project around - I'm not sure if I should think first about the macro features of an application or about the frequently carried out actions.
Take for example a website in which:
- Users can sign up and have different privileges depending on user
levels
- Users can edit their user details, upload photos, sign up to a mailing list and join groups with other users
- Admins can create new sections in the site within 5 different module areas
- Users can post articles and comments within these different distinct sections
1) If admins can create a sections within 5 different module areas (single, double and triple level blogs, forum, poll) should I think in terms of 1 class per module?
OR 2) should I generate a new 'class' for every new section an admin creates?
OR 3) Users are the central focus of the entire site - Users interact with the modules and the sections - so do I create a large user class containing insert, edit, delete methods?
Following on from that, where is best to put the methods?
a) I'm going to need to freuently use an SQL insert clause - I'll need to insert to the user table when someone signs up, insert to the groups table when someone makes or joins a group, or posts an article, comment or IM - so I'll use a method like the following... but should this be nested inside all of the other classes, or repeated in each of the module classes?
// runs a sql query
public function runQuery($qry) {
$result = $this->mysqli->query($qry);
return $result;
}
Likewise things like emailing the user multiple times - when they sign up to activate their account, when they join a mailing list, if they forget their password... So I imagine I would need a method for that.
As you can see, I'm confused as to to which class I should I put my methods in, and which classes to build my site around.
I'm fairly sure that I shouldn't need to think through 'all' my features before I start, as that wouldn't work well with an Agile development environment where users might suggest new features, so I'm hoping there is a relatively simple bit of guidance you might be able to offer me.
This is just one of many examples of sites I've previously coded procedurally and now want to start thinking about in OOP terms, so any pointers would be hugely appreciated!
Thanks
It's very difficult to come with proper solution without understanding what do you really want. When you are facing a problem/feature request you have to design application. Everything depends on feature/issue.
There are many different solutions, and each one is good for specific case. I cannot answer your question without deep understanding what do you want to tackle. The only think that I can advice :
- KISS - Keep it simple Stupid
- SOLID Principles, especially Single Responsibility Rule - each class should be responsible for only one thing. For example if you have User object, you should have at least three classes. UserEntity or UserDomain - simple representation of object, Repository/Storage for that user that brings you the basic operations on given user (CRUD - Create,Read,Update,Delete), and then you should have a module,service that handles the interactions, (for example between different users). The less one class know the better.
The good way to start is reading at least a little bit about design patterns, SOLID, maybe about DDD (Domain Driven Design). Also I can suggest watching CleanCoders. Uncle bob has very good (in my opinion) video tutorials about software development.
I used to say, that if you want to do something correctly, you have to do it twice. At first approach you don't know what you can expect, you cannot come with best solution without deep understanding what you're facing.
When I'm writing a piece of code, for example a class, I'm always writing it at least two times. Almost each part of class is refactored during development in order to remove duplicated code, improve perfomance. It's very rare when developer comes with perfect solution at first time.
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 6 years ago.
Improve this question
I'm rewriting a big website, that needs very solid architecture, here are my few questions, and pardon me for mixing apples and oranges and probably kiwi too:) I did a lot of research and ended up totally confused.
Main question: Which approach would you take in building a big website expected to grow in every way?
Single entry point, pages data in the database, pulled by associating GET variable with database entry (?pageid=whatever)
Single entry point, pages data in separate files, included based on GET variable (?pageid=whatever would include whatever.php)
MVC (Alright guys, I'm all for it, but can't grasp the concept besides checking all tutorials and frameworks out there, do they store "view" in database? Seems to me from examples that if you have 1000 pages of same kind they can be shaped by 1 model, but I'll still need to have 1000 "views" files?)
PAC - this sounds even more logical to me, but didn't find much resources - if this is a good way to go, can you recommend any books or links?
DAL/DAO/DDD - i learned about these terms by diligently reading through stack overflow before posting question. Not sure if it belongs to this list
Sit down and create my own architecture (likely to do if nobody enlightens me here:)
Something not mentioned...
Thanks.
Scalability/availability (iow. high-traffic) for websites is best addressed by none of the items you mention. Especially points 1 and 2; storing the page definitions in a database is an absolute no-no. MVC and other similar patterns are more for code clarity and maintenance, not for scalability.
An important piece of missing information is what kind of concurrent hits/sec are you expecting? Sometimes, people who haven't built high-traffic websites are surprised at the hit rates that actually constitute a "scalability nightmare".
There are books on how to design scalable architectures, so an SO post will not be able to the topic justice, but some very top-level concepts, in no particular order, are:
Scalability is best handled first by looking at hardware-based solutions. A beefy server with an array of SSD disks can go a long way.
Make static anything that can be static. Serve as much as you can from the web server, not the DB. For example, a lot of pages on websites dynamically generate data lists out of databases from data stores that very rarely or never really change.
Cache output that changes infrequently, and tune the cache refresh.
Build dynamic pages to be stateless or asynchronous. Look into CQRS and Event Sourcing for patterns that favor/facilitate scaling.
Tune your queries. The DB is usually the big bottleneck since it is a shared resource. Lots of web app builders use ORMs that create poor queries.
Tune your database engine. Backups, replication, sweeping, logging, all of these require just a little bit of resource from your engine. Tuning it can lead to a faster DB that buys you time from a scale-out.
Reduce the number of HTTP requests from clients. Each HTTP connect has overhead. Check your pages and see if you can increase the payload in each request so as to reduce the overall number of individual requests.
At this point, you've optimized the behavior on one server, and you have to "scale out". Now, things get very complicated very fast. Load-balancing scenarios of various types (sharding, DNS-driven, dumb balancing, etc), separating read data from write data on different DBs, going to a virtualization solution like Google Apps, offload static content to a big CDN service, use a language like Erlang or Scala and parallelize your app, etc...
Single entry point, pages data in the
database, pulled by associating GET
variable with database entry
(?pageid=whatever)
Potential nightmare for maintenance. And also for development if you have team of more than 2-3 people. You would need to create a set of strict rules for everyone to adhere to - effort that would be much better spent if using MVC. Same goes for 2.
MVC (Alright guys, I'm all for it, but
can't grasp the concept besides
checking all tutorials and frameworks
out there, do they store "view" in
database? Seems to me from examples
that if you have 1000 pages of same
kind they can be shaped by 1 model,
but I'll still need to have 1000
"views" files?)
It depends how many page layouts are there. Most MVC frameworks allow you to work with structured views (i.e. main page views, sub-views). Think of a view as HTML template for the web page. How many templates and sub-templates inside you need is exactly how many view's you'll have. I believe most websites can get away with up to 50 main views and up to 100 subviews - but those are very large sites. Looking at some sites I run, it's more like 50 views in total.
DAL/DAO/DDD - i learned about these
terms by diligently reading through
stack overflow before posting
question. Not sure if it belongs to
this list
It does. DDD is great if you need meta-views or meta-models. Say, if all your models are quite similar in structure, but differ only in database tables used and your views almost map 1:1 to models. In that case, it is a good time for DDD. A good example is some ERP software where you don't need a separate design for all the database tables, you can use some uniform way to do all the CRUD operations. In this case you could probably get away with one model and a couple of views - all generated dynamically at run-time using meta-model that maps database columns, types and rules to logic of programming language. But, please note that it does take some time and effort to build a quality DDD engine so that your application doesn't look like hacked-up MS Access program.
Sit down and create my own
architecture (likely to do if nobody
enlightens me here:)
If you're building a public-facing website, you're most likely going to do it well with MVC. A very good starting point is to look at CodeIgniter video tutorials. It helped me understand what MVC really is and how to use it way better than any HOWTO or manual I read. And they only take 29minutes altogether:
http://codeigniter.com/tutorials/
Enjoy.
I'm a fan of MVC because I've found it easier to scale your team when everything has a place and is nice and compartmentalized. It takes some getting used to, but the easiest way to get a handle on it is to dive in.
That said definitely check your local library to see if they have the O'Reilley book on scaling: http://oreilly.com/catalog/9780596102357 which is a good place to start.
If you're creating a "big" website and don't fully grasp MVC or a web framework then a CMS might be a better route since you can expand it with plugins as you see fit. With this route you can worry more about the content and page structure rather than the platform. As long as you pick the appropriate CMS.
I would suggest to create a mock app with some of the web mvc frameworks in the wild and pick one, with which your development was smooth enough. Establishing your code on a solid basis is fundamental, if you want to grasp concepts of mvc and be ready to add new functionality to your web easily.
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.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I have a problem about structures of the complex applications. Because my knowledge background does not come from education, I have always had a problem understanding an application's layers, design patterns, and programing structures. First of all, I can do whatever I want with PHP, because I know common functions and I have experience with it, but I want to create bigger and more complicated applications than I did before, so I always ask questions myself while I am writing code: Is this best place to do this? Is this the best way to do this? Do people use this way to do the same thing?
To answer these questions correctly, I created my own small MVC PHP framework which really looks like Zend Framework. I did this because I want to clarify all parts of the application. I know that there are lots of design crimes in my framework and all my applications, and I think that the main problem is the border between Controller and Model.
I asked lots of questions about this on SO, but still it is not clear for me. Therefore, I will explain what I know and what I do, and please show my mistakes, and correct them, or just explain some information about design patterns, or just explain what my problem is.
What I know
I know active record pattern. For example, we have user class, we use same class to save data to database, and we use same class as a object. So object is active we can create one then if we change it we can save it with same class ( $user = new user('Oguz'); $user->save();)
I know factory pattern . We have to classes for one object (User_Factory and User). We use user_factory class to access database for example get user or delete user. And user class is the object it self.
My problem starts when there is a connection between objects (not like many-to-many or belongs-to). For example, we have a video website which has a favorite system. The process of adding favorite consists of these steps (1-check the video with this id, check the user with this id. validating steps). While we are just adding or updating just one object we user other objects too (User factory and video factory). Generally I can do all this things in controller. But I fell that this is not the best place to do this. Because I call these steps as a process (adding favorite process). So this process should not go in controller because we may want to use same process as an API in another controller-action. So I feel like there should be another place which includes this processes for example process library. I do not even know which programing problem I am talking about.
The connection between object does not just exist in validation step.For example think about search process. when user search a string first we have to create new search row (for latest searches stuff), then we have to search YouTube, if we can not find we have to search other video sites et cetera. So this action is a process search process, I think putting the all logic in controller is a correct way to to this. we use lots of classes and objects so I can not put this process in search objects class.
I think one of the best things you can do is dig in and understand, really understand how things work. In the arena of web development, we are typically isolated from the details of TCP, packets, transports, protocols, etc... But sometimes, it is so isolated, that we forget to learn how it works, and as a result, stick ourselves in a little box.
I've been programming PHP professionally for nearly 10 years. I've never used an MVC framework. I've always separated user interface from application logic from database access.
We don't need a bunch of "patterns". We need true understanding of the problem, and the vision to create an elegant solution, re-using other work as much as possible.
So I guess I am suggesting that you switch your focus from trying to make your application fit into a pattern, and re-consider the logic needed to successfully complete your application. Many times, it is very simple, but we tend to over-complicate it.
Throw off the handcuffs of MVC and patterns... (and then watch me get downvoted for ranting against the status quo).
Good luck with everything. And by the way, you will learn far more about programming in 4 years of doing it, than 4 years of college. Not to say you should or should not go to college, but just be aware that in many cases, you already know more than your professors will about real-world programming.
MVC is a fashion blooming 20 years late. If you feel it pushes you into "wrong" code, it's because that's just what it does. Do things from the first principles. And... The community is not a shrine of divine wisdom. We're just a bunch of loud code monkeys. Use your own brain. And... MVC is a fashion blooming 20 years late. If you feel it pushes you into "wrong" code, it's because that's just what it does. Do things from the first principles. And...
Good luck, and enjoy your endeavors!