Michal wrote:
Hi,
On Tue, Jan 5, 2010 at 10: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
My aim was to have the URL (/menu) structure to be most appropriate.
Having two separate subfolders for events and galleries, might be
appropriate for some cases (and I have made sites where they are), but
it might not be appropriate for others. Events or galleries might be
specific to some subject, and be "nested" in a bit deeply: It might be
more appropriate to have:
toplevelsubject/sometextpage/
toplevelsubject/mygallery/
toplevelsubject/futureevents/
rather than
textpages/toplevelsubject/sometextpage/
galleries/toplevelsubject/mygallery/
events/toplevelsubject/futureevents/
Hi,
I agree with Felix - this kind of architectural decision has far going
consequences and its best to take it when you have thought out the
entire thing appropriately. Nevertheless, I have always advocated the
notion that Agavi doesn't stand in your way of doing things, so at the
very least what you are looking for should be possible. So when I've
seen your post I've immediately began thinking about scenarios in which
dynamic, personalized URLs can be useful, considering that I've faced
those problems without Agavi in the past. What if you are making a
free-for-all social network web site constructor, or mirror HTML web
sites for other people, for example? Agavi routing callbacks coupled
with how Agavi processes routes allow you to do this without hacking on
the framework itself. The question is cost in terms of performance, a
problem that can be mitigated (or at least forced into linearity when it
comes to scaling up) with caching - Agavi's content caching,
webserver-side proxy caching, perhaps even a custom routing cache in the
application itself - I imagine the latter would be easy to implement,
just slap on a callback at the beginning of the routing table which
talks to your caching backend.
Of course if you want to fully expose the power of Agavi's routing to
your users (that is, allow them to choose what kind of Agavi-specific
idiom - e.g. action or an alias of it - can be matched) then you will
have to sweat out some work. It has to be done safely and securely, and
in a way that will not break your users' pages if you suddenly decide to
renew the main routing map. There is no generic solution to this problem
without inserting hooks into all major parts of routing process, but for
practical purposes Felix is right again and you probably don't need any
of that; so from design perspective, I think, you should consider what
limitations for dynamic routing would be acceptable; knowing exactly
where the limits are you can work out a serious solution that wouldn't
take a month to implement.
_______________________________________________
users mailing list
[email protected]
http://lists.agavi.org/mailman/listinfo/users
