I can suggest to avoid chaining Magnolia with other legacy apps. It is better another approach, e.g.: mapping the other filter chain on another extension (*.old) or to separate both context. Anyway, this is only my point of view.
I understand perfectly your point of view, but in some cases we developed a different approach: if it's not possible to replace the legacy app as a whole or in a reasonable time (which happens almost always), our idea is to use Magnolia as a proxy for the app: if the content is already migrated or inserted directly in Magnolia, Magnolia will serve it, if it's not available in Magnolia then system should fall back to the old app. This at least until every part of the old system is migrated and the old app dismissed.
But in this case, why not you integrate you legacy system with Magnolia at filter level? Place a filter (tune the position in filter chain) and forward the call for certain pages, stopping the chain before reach the CMS. In this case Magnolia CMS is the last filter and you can serve legacy pages / systems integrating them, for instance, with Magnolia authentication.
My goal is to have the legacy as a fallback, so the question is: is there a smart and quick (computationally speaking) way to check if a request will be served correctly (i.e. not a 404) by rendering filter without actually going to render it? Maybe it's there and I simply missed it... If such a way is possible I can easily write a filter/bypass that before going to the rendering filter switches to the legacy.
Regards, Danilo. ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
