A good point to start with.
As a more complex solution later maybe one should try to store a hash of
applications ($c) with all surrounding stuff. And make independent component
which will decide which application (i.e. $c) the request is to be
dispatched to.
Ahh, unfortunately im not familiar enough with catalyst's internals to
advice somethin.
2007/5/8, Matt S Trout <[EMAIL PROTECTED]>:
On Tue, May 08, 2007 at 06:13:29PM +0400, Oleg Pronin wrote:
> I think it would be better if it does not.
> Because AppA don't know and don't want to know the templates and models
of
> AppB. They communicate through controllers only.
How about, after setup_components, injcting AppB's ->controllers into
AppA's ->_components hash under 'AppA::Controller::AppB::<whatever>' and
then
having a tweak in 'sub dispatch' in AppA that, if it sees an AppB::*
controller, reblesses $c into AppB, fiddles req->base and req->path
appropriately, and then calls AppB's ->dispatch.
Bit insane but probably the quickest path to implement this, and without
doing it and seeing what goes wrong I'm not sure we can figure out the
'correct' approach.
--
Matt S Trout Need help with your Catalyst or DBIx::Class
project?
Technical Director Want a managed development or deployment platform?
Shadowcat Systems Ltd. Contact mst (at) shadowcatsystems.co.uk for a
quote
http://chainsawblues.vox.com/
http://www.shadowcatsystems.co.uk/
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
