Need pointers for a Revo app architecture

Hey all, and especially Revo Gurus.

I am in need of your wisdom.

I’ve been doing research and reading Evo docs and forum discussions to try to get a grip on the new MODx. As i mentioned here before i have a project to implement a real estate site with very unique requirements. One of those requirements is extensive cross linking of business entities (properties, areas, attractions, transport points, agents, etc.)in multiple dimensions.

So for example what it means is that a user can see a list of properties that are similar/related to the current property. That a user can see a list of train and bus stations close to the current area. That a user can see schools or shopping centers around the current property.
Each property will have over 20 special attributes most of which will need to be searchable. And of course the urls for each property will need to be friendly.

Initially i though of using TVs for all of the property attributes but after reading on this subject have realized that 2 dozen tvs will produce to many database joins and will slow the site down. There were a couple of discussion on this topic for Evo, which proved to be too cumbersome to implement.

So what do you think would be the best way to implement multi-dimensional relationships between resources while keeping the friendly urls in Revo?
My other alternative is PHPMyDirectory, but i would much rather do this in MODx.

Let the discussion begin.

-Kiril

In general - xpdo is very nice for multi-table relationships. In your case, I would defently go for xpdo, for sure not TVs.
It’ll allow you to quickly develop the custom relationships+queries you’re looking for.

how will these relationships be managed? content editors will put in house+bus-stops+etc.. and link them together via front-end, or what?

For an social network application I just id on revo, i did a ’like’ and ’relationships’ modules, which manage different types of relationships between users and resources. front-end manageable (ajax..) - and with revo/xpdo that was really piece of cake.

Then, in your case - for listing, you could do your own custom stuff, or even simply use ditto (just add your own custom extender and you can filter/sort your data - i can send a sample if needed).


Note - Reading your post, I’m not sure if it’s a good idea to really have a modResource for all types of object. seems a bit too much, as it seems many of your resources are "lean" (i.e. bus stops, etc..). naturally - it’ll work, but, it’s a question of quantity and performance.

good luck

Thanks Oori,

any samples and details are absolutely welcome.

Could you say more about about the editing of these relationships. The great thing about TVs is that they are edited in the context of the document, so all data is together. The relationships will need to be created/maintained by the client’s staff who are not technical.

Could you elaborate more on your last statement? What is the significance of modResource?

-Kiril

I think what oori is saying is that in the CMS world, data is not content and that Resources and Template Variables are meant to represent content for presentation, not data for persistence, storage, reporting, and/or multi-dimensional views into that data. By creating a custom model of your data, you can then utilize it in the presentation layer in various places and ways with a great amount of flexibility and reusability. This is one of the major benefits of an MVC framework, separating the model (custom database tables) from the views (Resources, Template Variables, and other Elements in the CMS) into that model.

In many cases where the amount of data is trivial or organized very simply, the data can be stored as content, but IMO, this is not one of those times.

Could you say more about about the editing of these relationships. The great thing about TVs is that they are edited in the context of the document, so all data is together. The relationships will need to be created/maintained by the client’s staff who are not technical.

In the case of the last application i mentioned - all editing is front-end, the backend modx manager is only for system admins (and is generally not used for any content editing). As a social network - users themselfs manage the resources, relationships, custom tables, etc.. only from the front-end.
Processors in revolution aid this, and are great for ajaxing. as a simple example - take a look at Quip commenting, it’s structure and functionality are simple to understand. never the less, revolution is highly flexible - you don’t really have to work in the quip model, you can make up your own (or look around in the modx svn at other components). (modx Manager itself extensively uses processors, take a look in the core code)
I will publicly publish the relationships/like modules I built, but only after I find the time to clean them and package them, as they contain some code which is not generic - and specific to this customer’s data structure (mainly in the presentaion level).

IMHO, the nicest thing about this, is that you can enjoy both worlds - framework and content management using the same data. You have a lot of "room for game" in your application. Even if you build your own data structure - you can combine/relate it with cms-content (like resources) and it is usable with existing modx components (for example Ditto, which is a great module), templating engine, permissions, etc etc...

Hi OpenGeek,

Theoretically i understand your point. The pure MVC will indeed require a clean separation like that. But then there’s the issue of time and resources to implement a bunch of new management screens for the non-technical users to be able to manage the data in custom tables. And it is at this point where i begin to wonder if it’s really worth the trouble.

MODx offers an excellent and flexible set of tools and additional plugins to manage site content. It also offers a versatile customization mechanism with TVs. Modules like YAMS extend that mechanism to allow a very robust way to create multi-lingual sites. It all fits together and makes sense,even though it might be muddying the MVC waters a bit. But if the content is not coming from some external transactional system but needs to be manually entered and managed then i don’t see a point of reinventing the management interface.

So I’ve been going back and forth as i was thinking about the architecture of this project. I read through all of the forum discussions on the subject. It seems that Revo with xpdo is the proper way to go as they provide a very powerful platform for implementation of about anything. But it also feels that is more like a pure PHP framework (like Cake or Symphony) rather than a CMS framework. It feels that it will require creation of CRUD screens for the custom data and recreation of a lot of other CMS functionality. Not being a PHP master this looks to be very time intensive and prone to error on my part. Additionally the number of available snippets, plugins, and modules for Revo is rather limited right now.

The alternative is to use Evo with all of its limitations and employ TVs to capture custom attributes and relationships with the help of Quill. The upside is that the content editing is simple and contextual. Many extras are available for the stable code base, and experience/support are deeper. The downside is the suboptimal performance due to the many TVs. But it seems that with a proper use of caching the performance issue can be handled since we’re not going to have millions of records.

Please let me know if my reasoning is erroneous in any way.

Best,

-Kiril

Hi OpenGeek,

I’m still thinking about this architecture and got a fundamental question.

If i were to setup custom tables for the data and use MODx for display purposes only who would i ensure friendly urls for every logical entity that is being dynamically retrieved from the database?

Thanks.

If i were to setup custom tables for the data and use MODx for display purposes only who would i ensure friendly urls for every logical entity that is being dynamically retrieved from the database?

I’m not sure why a bus stop needs a friendly url, or did i get you wrong? reading your initial post it looks like you need a ’house’ with friendly url. that’s your base unit which contains meta-data related to it (bus stops, similar hours, etc...)

You could implement this in various way, I’d recommend you to use a resource for each house, then all the rest of the data in custom tables. It’ll be the easiest for you, as you’ll enjoy much of the modx capabilities as cms (build-in friendlyurl,cache,manager interface,etc..). Then use xpdo for the rest of your data. You’ll be able to define multiple and complex relationships and have well ordered database that is dynamic and searchable (unlike a hack to put an json array in a tv or something like that..). From this point to complex front-end features based on this data - is a short way in revolution. ajaxing each component is "almost built-in"...


BTW, in case you need friendly urls for bus stops also, you could always add a mod_rewrite rule (in .htaccess) to change /busstops/nyc/strname/23 --> /busstops.html?&city=nyc&street=strname&number=23
Then have a single resource "busstops" in your modx - that’s it.
Naturally, you can apply the same method also to ’houses’, but seems to me you’re better of with the first option.

Quote from: outre99 at Feb 09, 2010, 12:14 PM

If i were to setup custom tables for the data and use MODx for display purposes only who would i ensure friendly urls for every logical entity that is being dynamically retrieved from the database?

I do this by a) creating a function on my xPDO-generated class that is responsible for building the link for rendering purposes and b) creating a plugin OnPageNotFound that breaks the URI up into pieces and handles the custom FURLs according to the pattern I am rendering them with.

Related threads:
http://modxcms.com/forums/index.php/topic,41502.msg249684.html#msg249684
http://modxcms.com/forums/index.php/topic,44683.msg266663.html#msg266663

Excellent.
This makes perfect sense to me.
Onwards and upwards.