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
