[Ledger-smb-devel] Request handling using routes, containers, (internal) services
Hi Chris, John, In the other thread, John mentioned the structure that web apps are growing to in general to have these components to facilitate growth beyond a certain size: So... the patterns we're discussing I'm seeing put in widespread use. I'd say those 3 things are crucial for us to define/decide how we're going to implement (and perhaps find some Perl framework to assist if those we're currently using are insufficient): * Request routing * Service container to make it easy to register and load services * Response object (which needs to include the definition of how to return exceptions). So, I'm now thinking how we can apply these concepts to LedgerSMB with or without the context of using Plack and/or Starman. I'm imagining that we will have to handle a certain amount of it ourselves internally and that we possibly could hand off some of it to Plack's middleware modules. What I've been thinking about for some time now is that we might want to virtualize our current module names 'aa.pl' etc. into routes. For aa.pl, there really are physical files, but for other routes, we may not want to handle the route processing the same way. Is this something that we need to address now (as in: design it asap and simply continue working on the code base, but use this as a paradigm for all code that's being (re)written)? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Request handling using routes, containers, (internal) services
On 06/22/2015 02:53 PM, Erik Huelsmann wrote: Hi Chris, John, In the other thread, John mentioned the structure that web apps are growing to in general to have these components to facilitate growth beyond a certain size: So... the patterns we're discussing I'm seeing put in widespread use. I'd say those 3 things are crucial for us to define/decide how we're going to implement (and perhaps find some Perl framework to assist if those we're currently using are insufficient): * Request routing * Service container to make it easy to register and load services * Response object (which needs to include the definition of how to return exceptions). So, I'm now thinking how we can apply these concepts to LedgerSMB with or without the context of using Plack and/or Starman. I'm imagining that we will have to handle a certain amount of it ourselves internally and that we possibly could hand off some of it to Plack's middleware modules. What I've been thinking about for some time now is that we might want to virtualize our current module names 'aa.pl http://aa.pl' etc. into routes. For aa.pl http://aa.pl, there really are physical files, but for other routes, we may not want to handle the route processing the same way. Is this something that we need to address now (as in: design it asap and simply continue working on the code base, but use this as a paradigm for all code that's being (re)written)? I don't have an answer to that specific question... But most webapps I've worked with have a single endpoint that receives all requests. The webserver reroutes any paths that don't exist on the disk to that endpoint. Given that all of those little module name endpoints we currently have are copies of one of two different actual endpoints, it does seem like we should be able to pretty easily eliminate those... and just make the single remaining endpoint smart enough to know which way to handle the request... I would assume Starman could handle something like that? For Drupal, Apache first looks for a file on the disk... if it doesn't exist, it rewrites the path to /index.php?q= (and then adds the original path). This is done internally, not as a redirect, so the browser never knows... -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Request handling using routes, containers, (internal) services
On Mon, Jun 22, 2015 at 2:53 PM, Erik Huelsmann ehu...@gmail.com wrote: Hi Chris, John, In the other thread, John mentioned the structure that web apps are growing to in general to have these components to facilitate growth beyond a certain size: So... the patterns we're discussing I'm seeing put in widespread use. I'd say those 3 things are crucial for us to define/decide how we're going to implement (and perhaps find some Perl framework to assist if those we're currently using are insufficient): * Request routing * Service container to make it easy to register and load services * Response object (which needs to include the definition of how to return exceptions). Request routing is what Dancer would give us. Same with a service container. However, I don't think it really uses response objects as such. In fact i havent seen Perl frameworks usually exposing the response objects to the developer as such. With Catalyst and Mojolicious usually you get a controller object which can be told to render a response. Dancer makes these into modules which get called where needed, so no controller object. Speaking of which I need to finish up the remaining issues in the Dancer-based admin tool :-D Here's what I have in progress there. Feedback is welcome https://github.com/ledgersmb/App-LedgerSMB-Admin-Web/blob/master/lib/App/LedgerSMB/Admin/Web/Database.pm But that's the paradigm that we'd get. For auth and http errors see https://github.com/ledgersmb/App-LedgerSMB-Admin-Web/blob/master/lib/App/LedgerSMB/Admin/Web/Auth.pm So, I'm now thinking how we can apply these concepts to LedgerSMB with or without the context of using Plack and/or Starman. I'm imagining that we will have to handle a certain amount of it ourselves internally and that we possibly could hand off some of it to Plack's middleware modules. In 1.5 we always use Plack. CGI will even be wrapped in Plack. But that is good, since Dancer and Catalyst also wrap Plack. What I've been thinking about for some time now is that we might want to virtualize our current module names 'aa.pl' etc. into routes. For aa.pl, there really are physical files, but for other routes, we may not want to handle the route processing the same way. Is this something that we need to address now (as in: design it asap and simply continue working on the code base, but use this as a paradigm for all code that's being (re)written)? The hard part is formalizing routes, i.e. design. The easy part is programming. The question as always is the dependency question but I don't think that is too much of a problem to be honest. Best Wishes, Chris Travers -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
