Title: Architechture for larger database driven sites Post by: hesten on August 30, 2010, 07:31:35 Hi all
I've been wondering for a while how others architect database driven websites. My current approach is to have the backend output a site tree where the nodes represent the pages in the site. Each node then specifies: An id - obviously an unique id for the page (for searching the tree), I normally use the path to the node in the site tree and use this for SWFAddress as well (for example: id="clothes/shirts/blue-shirt") A template - the view that is needed to render page data. A data url - the data for the page (the template will know how to render this) (and an optional "includeInMenu" attribute) Every time an url is entered the template specified view is then instanciated and the data for the view is loaded and off we go. This approach works fine for most cases but it doesn't scale very well, and the very concept of loading the entire site map seems wrong since a user never really visits the entire site. So how do you guys handle dynamic sites? (deeplinking to states is required) Title: Re: Architechture for larger database driven sites Post by: hesten on August 30, 2010, 10:52:28 Another disadvantage of the above mentioned approach is that isn't very "service oriented", and replacing clients would force them to use the site tree "protocol" instead of a more generic webservice defined interface.
Title: Re: Architechture for larger database driven sites Post by: puremvc on September 01, 2010, 08:41:40 For a re-entrant site where each page is bookmarkable (and represents either a playlist or an item in a playlist, though that could easily be a store section and item) you can take a look at the Sea of Arrows site[1]
I used Flex's builtin BrowserManager rather than SWFAddress, and I read a single 'sitemap' XML to figure out where to get the info I need for the 'page' you land on. That data could always come from a database call, of course. The key is in the NavigationVO that is populated either from the inbound URL or from a user action that triggers a navigation away from the current URL. This is also a Multicore site using the StateMachine, so it's a tad more involved than a Standard version demo. HTH, -=Cliff> [1]Sea of Arrows Player: http://seaofarrows.com/ Source http://seaofarrows.com/srcview Title: Re: Architechture for larger database driven sites Post by: hesten on September 03, 2010, 01:55:54 Thanks Cliff
From what I can tell that's pretty much the approach I am using now (and what I think a lot of others are as well?). But I was wondering if a routing approach like NET MVC where the url kan be translated to a state without knowing the entire site tree was feasible (site maps can become rather large, and often the server needs to generate them, giving overhead). Something like: {command}/{view}/{id} Then all you would need to load would be a service mapping of some sort, and not a description of the whole site. (obviously you'd need a command and view map as well). And the services could be used from other clients without them having to know some arbitrary xml site map. I'm just not smart enough to figure out if it would work and be generic enough. So I ask you guys if you have a smarter approach :) Title: Re: Architechture for larger database driven sites Post by: puremvc on September 07, 2010, 07:45:23 Sure, this is absolutely possible. You need to be able to handle mangled URLS that are either malformed, or don't point to actual data. For instance if the URL was 'show/gallery/item-12' then you could easily translate that into a state for your app, but you need to handle the user modifying the URL to say item-13 which doesn't exist.
Before launching off into the code, I'd work out the protocol of this URL so that I knew all the possible states, and quite possibly use that to create an FSM for use with the StateMachine utility which is perfect for that sort of thing. -=Cliff> Title: Re: Architechture for larger database driven sites Post by: hesten on September 15, 2010, 12:32:09 Thanks again Cliff
Yeah the hard part is figuring out the mapping of the url to a specific application state. One thing I forgot about using the site tree approach is the possibility for the application state to know about the states context in the tree - which you'd need to think into a url routing routine if you'd need to facilitate this. So far I'm not sure I'll give up the site tree/site map approach, I think the routing approach still needs some thinking. I think I was hoping someone already had come up with a scheme for it :) Maybe I'm just talking nonsens? :) (Doesn't the StateMachine utility depend on Flex?) Title: Re: Architechture for larger database driven sites Post by: puremvc on September 15, 2010, 04:16:05 No State Machine doesn't rely on Flex. Pure AS.
-=Cliff> |