Hi, I was cleaning up my inbox when I stumbled upon this old thread. I'm currently doing something similar to this, where I had to modularize our non-Agavi app into loadable, self-contained units. I may not have used Agavi, but I think what I'm about to share is relevant to your current problem.
What I did was to accompany each module with an XML file (with Agavi, you can extend Module/config/module.xml) and declare relevant info there. I then made a small script to scan the directory, read the data from the XML, and transform the resulting data through XSLT. In your case, you can create a script that would recreate routing.xml with your desired URLs whenever you need to load or unload modules. Also, I've declared the relative sequence of each module because I had to mount them in the correct order. In your case, I think you also need to declare the sequence because some modules may be dependent on other modules. As some have pointed out, you need to take care about the order within routing.xml. Regards, [ simon.cpu ] On Tue, Jan 5, 2010 at 7:07 PM, Guilherme Aiolfi <[email protected]> wrote: > Dynamic URLs would allow some kind of self container modules: modules with > all its actions, views, models, routings. > Something that is not possible today, I guess. The only part that can't be > done by module is its routings that has to be all into routings.xml. > If I want to allow the admin of my site to e.g. load, unload, disable > modules dynamically, how should it be done? > Being able to look for routings in the DB would improve the agavi > flexibility a lot. Is it possible? I mean, using an "unhacked" agavi? > On Tue, Jan 5, 2010 at 8:20 AM, Felix Gilcher > <[email protected]> wrote: >> >> In general, I fail to see the benefit of that. URLs are organized like >> folders, each part can be represented as s sub-folder. How would you >> organize your data: >> >> - Have one big folder and throw in all events and all galleries in the >> same folder, just organized by name >> - Have two subfolders named "events" and "galleries" and organize your >> data in those two folders by name >> >> The first one roughly translates to your static routing example. The >> second approach translates to something like the following (untested) >> routing config >> >> <route pattern="^/galleries" name="gallery" module="Galleries"> >> <route pattern="^/(galname:\S+)" name=".gallery" action="Gallery"> >> <route pattern="^$" name=".index" action=".Index" /> >> </route> >> </route> >> >> <route pattern="^/events" name="events" module="Events"> >> <route pattern="^/(eventname:\S+)" name=".event" action="Event"> >> <route pattern="^$" name=".index" action=".Index" /> >> <route pattern="^edit/$" name=".edit" action=".Edit" /> >> </route> >> </route> >> >> That solves most of your matching problems. It also provides a natural >> place where to hook in a "view all galleries" and "display upcoming events" >> page. And as a bonus, search engines love well structured url schemata. >> >> If you're writing a CMS, you should at any point have a knowledge what >> kind of item you're handling and thus be able to use the proper routes. All >> items should by default use the canonical urls laid out by the routing >> scheme and should always be retrievable by using that url. This provides the >> visitor with a simple scheme of how urls are laid out and how to navigate >> the page. You should also include a <link rel="canonical" ...> element in >> the head of the page pointing to the canonical url for the item. However, >> sometimes the user of the CMS wishes to assign additional shortcut urls to >> specific items of any kind. There's multiple ways of solving that: >> >> - You can provide the user with a way to define a mapping from short url >> to the canonical url and dynamically generate a rewrite config. That's >> probably the fastest way since the webserver does all the rewriting, but its >> technically a bit complex. You need to take extra care that the config is >> valid, since breaking it would break the whole webserver config, you may >> need to restart the webserver after changes were made, ... >> >> - Same as above, but don't generate a rewrite config. Have a catch-all >> route at the end of the routing with a callback that resolves the short url >> and redirect to the long url from there. This is a relatively simple >> solution, however, the url changes for the user and it requires one extra >> roundtrip. >> >> - You can provide the user with an option to map a short url to any >> specified item. Then, in the Error404 Action you can try and recover - look >> up the short url in your mapping and forward to the appropriate action. This >> may involve elaborate logic in the 404 action. No extra roundtrip for the >> redirect, the url does not change. >> >> The last two options may put quite a bit of strain on your database server >> since every false url (as in "does not point to a valid page") will result >> in a database query. You may want to cache the mapping in a memcache server >> or similar to speed things up >> >> Hope that helps >> >> felix >> >> >> On Jan 5, 2010, at 10:39 AM, Michal wrote: >> >> > Hi, >> > >> > Is it possible to have routing determined (more or less) at runtime? >> > I'm thinking that in a CMS-type app, a user might want to choose what >> > a route maps to: say to a gallery action or an events calendar action. >> > Each of these actions could have different sub-routes. Static-ly, I >> > would do it something like (non-working example): >> > >> > <route pattern="^(galname:\S+/" name="gallery" module="gallery"> >> > <route pattern="^$" name=".index" action="Index" /> >> > </route> >> > >> > <route pattern="^(eventname:\S+)/" name="events" module="events"> >> > <route pattern="^$" name=".index" action="Index" /> >> > <route pattern="^edit/$" name=".edit" action="Edit" /> >> > </route> >> > >> > The issue with the above example is that the "gallery" route would >> > always be matched, and the "events" one would not. I need some way to >> > dynamically choose at runtime which one. A few ideas: >> > >> > - Have a callback in each route. The callback would query the database >> > (and possibly cache the result) to see if the current route should >> > match. >> > - Use a modified routing class. I'm not sure quite how to modify it >> > though. >> > - Dynamically generate routing.xml itself. This could either be on >> > every request (somehow?), or just when a user makes a change. >> > - Don't really use routing.xml at all: have a "catch all" route that >> > maps to a "Control" action, that then processes the URL and forwards >> > to the correct action. >> > >> > I'm not sure in which direction to go. Any suggestions? >> > >> > Michal. >> > >> > _______________________________________________ >> > users mailing list >> > [email protected] >> > http://lists.agavi.org/mailman/listinfo/users >> > >> >> -- >> Felix Gilcher >> >> Bitextender GmbH >> Paul-Heyse-Str. 6 >> D-80336 München >> >> T: +49 89 57 08 15 16 >> F: +49 89 57 08 15 17 >> M: +49 172 840 88 28 >> >> [email protected] >> http://www.bitextender.com/ >> >> Amtsgericht München, HRB 174280 >> Geschäftsführer: David Zülke, Florian Clever >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.agavi.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > [email protected] > http://lists.agavi.org/mailman/listinfo/users > > _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
