tag:blogger.com,1999:blog-36345871.post7178415077466739501..comments2023-07-11T05:39:57.966-07:00Comments on Perl Alchemy - notes of a programmer: Drupal like architecturezbyhttp://www.blogger.com/profile/04636763782334128869noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-36345871.post-12654305827594765162011-03-28T03:31:31.158-07:002011-03-28T03:31:31.158-07:00@Ranguard - you know that the first link in my pos...@Ranguard - you know that the first link in my post is to your to your article? Ad interoperability - I need to play a bit more with that - but in general I like how the Plack middlewares usually provide a callback interface instead of exposing some 'setup' method that would connect the state storage directly. For Plack::Middleware::Auth::Form - this was enough - it does not need to know much about the thing that stores the users and their passwords it just needs a callback that would check if a given pair is OK.zbyhttps://www.blogger.com/profile/04636763782334128869noreply@blogger.comtag:blogger.com,1999:blog-36345871.post-84477783802121853072011-03-28T03:25:00.931-07:002011-03-28T03:25:00.931-07:00@cezio - thanks for the comment and the link. I a...@cezio - thanks for the comment and the link. I am adding js/css assembling to the list. I can agree that whole idea is risky - but I would still like to play with it :)zbyhttps://www.blogger.com/profile/04636763782334128869noreply@blogger.comtag:blogger.com,1999:blog-36345871.post-47148793369870829442011-03-27T15:44:34.584-07:002011-03-27T15:44:34.584-07:00Embedding html content from 'external' app...Embedding html content from 'external' applications is an error-prone and risky task. Conceptually it seems to be ok: you have host and embedded application, remove unnecessary content from embedded and you're in home. But, the flaw is that html apps are self-sufficient, and when mixed, they might fight for resources: css/js/markup structure/processing paths. Html is not designed for embedding. Once merged, both markups are equal. Well, maybe with exception for iframes, but this only shows how this model is broken here.<br /><br />General reflection is that PSGI (as well as any other WSGI-like interface) is not designated for component approach to web applications. This is interface just for serving, all the rest is up to served application. <br /><br />As for Drupal, it is an example for quite distinctive architecture - OOP without OOP: concepts are object oriented, but the code is functional. There is of course good rationale for such approach - to overcome limitations/flaws of OOP model in PHP ( http://drupal.org/node/547518 )ceziohttps://www.blogger.com/profile/09177597152318113154noreply@blogger.comtag:blogger.com,1999:blog-36345871.post-25898479991471857812011-03-26T09:09:15.037-07:002011-03-26T09:09:15.037-07:00http://blogs.perl.org/users/leo_lapworth/2011/02/p...http://blogs.perl.org/users/leo_lapworth/2011/02/portable-plugin-apps.html<br /><br />I was thinking the same.<br /><br />For 'interoperability' I was wondering about setting up roles for requirements, e.g. your $user_obj can be anything as long as it provides $user_role method, same for $cache, $db etc<br /><br />But just a musing rather than something I have time for.Ranguardhttps://www.blogger.com/profile/08208601603517603574noreply@blogger.com