Discuss: Approach to Administrative Functions for Dynamic Websites



  • We support a ton of smaller websites, and for each we tend to do a lot of custom web applications.  Simple things like WYSIWYG textareas so that they can update their page content to calendar applications so that clients can update appointment times, etc online. For the most part, nothing special - stuff that I'm sure all of you web developers have done a thousand times before.  It's an admin page (or set of pages) to CRUD (create, read, update, and delete) database records and then a view page to display that information to site visitors. 

     Here's the question, how do you organize your code?  Do you create functional modules or do you create all front end pages as one piece and the administrative tool as another?

    The modular approach would be to create a module (Let's say 'PAGES') and to put all of the code (to both perform CRUD actions and to display for site visitors) into that one block.  The admin / view approach puts all CRUD code into an ADMIN directory and then puts all of the VIEW code into it's own set of functions.

     Any thoughts?  I've always used the ADMIN / VIEW method but lately I'm switching to the modular approach due to scalability and reusability.  I'd be interested in what you guys think so that coders that follow me aren't posting excerts of my code as WTF's.
     



  • Our typical approach is to have a DAO "module" (Data access object) which handles the CRUD operations at an API level.  The front end is its own webapp, which imports the DAO and uses it for read operations.  The tool is also usually a webapp, and imports the same DAO (or an extended one) and uses it for all the CRUD operations.

     Edit:

    Oh, and if the front end needs to create/update/delete (such as forum software) it would probably have a seperate DAO specifically for that purpose.  Forum data is different than Content data. Content data should only be editable by the tool, so only the tool uses the content dao r/w.  Forum data needs to be editable by both, so both the front-end and back-end use the forum dao r/w.

     

     



  • http://en.wikipedia.org/wiki/Model-view-controller

     Have you seen this before? This is the 'generally-accepted' way of doing things. That means that you'd write one script that knows how to modify the data, and then two 'view' pages, one that only displays data, and one that allows modification.

    The views should contain (most of) the HTML code, and the controller has the functionality that modifies, generates, displays data. The goal is to separate HTML from code, and share the code between all the views.

     So, keep the admin and view pages, but move all the code (most of which will be duplicate) to a common controller class.

     
    I hope that somewhat answers your question.. ;-)

     



  • [quote user="Nandurius"]

     So, keep the admin and view pages, but move all the code (most of which will be duplicate) to a common controller class.

    [/quote]

    Actually, the controllers would probably be quite different, its the MODEL that is shared, and therefor the data access layer/DAO.

    A controller for a tool is VERY different than a controller for a front-end webapp, but the data access is very similar.
     

     



  • I'm familiar with MVS, worked with Struts (java), Fusebox (Cold Fusion), and am currently having some fun with CakePHP (umm... well that one's obvious).  Please understand that when I say 'view' I am referring to the visitors version of the website as opposed to the administrators.

     For instance, create a website that pulls database data for the Visitor View using MVC.  You can seperate the layout code from the code that pulls the data etc and stick to the MVC model and then you can have your administrative tool work in a similar fashion - but using a completely different controller.

    I guess to put it another way, one method approaches the different controllers as their own entities and the other approaches the Visitor and Administrative pieces as seperate projects.  The method that you outline would be to combine all functionality (both administrative and viewer related) into single modules.

     I'm really just interested in how the rest of the community approaches this and if any thought has gone into one method vs another.
     



  • It sounds like you need separate controllers and views, but it depends on how different they are and how much code you can reuse. It's best to avoid things like "if (user.isAdmin) /a bunch of code/ else /another bunch of code/". You could put the common parts in base controller classes, and have subclasses for admin- and visitor-specific behaviour, which in turn render specific views.



  • [quote user="technites"]It sounds like you need separate controllers and views, but it depends on how different they are and how much code you can reuse. It's best to avoid things like "if (user.isAdmin) /*a bunch of code*/ else /*another bunch of code*/". You could put the common parts in base controller classes, and have subclasses for admin- and visitor-specific behaviour, which in turn render specific views.[/quote]

    I agree.  If you can factor out common behavior, and make the views specific to their purpose, that would probably be the most flexible. 

     

    Edit: If you're using JSP's, look into Tiles. 


Log in to reply