Re: Proposed framework changes for 1.4

[Chris Travers <..hidden..>]

On Tue, Oct 18, 2011 at 9:26 AM, John Locke <..hidden..> wrote:
> Hi,
>
> Sounds like a good direction to me. Couple thoughts -- not being that
> active in Perl, don't know if these are realistic or not, but just what
> comes to mind, feel free to disregard.
>
> - Are there really no other date or number libraries available that do
> what we need, to the point we need to create our own? (or are these
> primarily wrappers around something else?)

PGDate is primarily a wrapper around DateTime.  I have some temporary
parsing logic in there now, but would really like to outsource this
somewhere. Just haven't decided where.
PGNumeric is likely to be a light-weight wrapper too, but not sure of what yet.

>
> - Ran across this project recently: http://ledger-cli.org/ - a Perl cli
> app that does double-entry accounting in text files. I wonder if they've
> worked out some good accounting logic we can use, at a minimum -- or
> perhaps incorporate into LSMB? I'm thinking with a little collaboration,
> ledger-cli might be extended to use LSMB as back end storage, while LSMB
> might potentially leverage the work already done in ledger? Have not
> looked at the code, have no idea whether this is practical. But an
> easier CLI interface sounds very useful, if it's not too much of a
> stretch. And might be a good gateway to new users...

I will look into it.

>
> - Regarding extensions, I just had to do some upgrades to some other web
> apps where customizations and extension code was scattered across a
> bunch of libraries. Basically an MVC organization -- but all extension
> code had to be split up, with the M in the M, the V in the V, and the C
> in the C directories.... I just want to express my extreme distaste for
> that file organization, from an ongoing maintenance point of view. Using
> a framework for development is great, as long as we can set it up in a
> way so that if I want to add some sort of custom module to the site, I
> can put all the code for it in one directory.

that's good feedback.

>
> Extending that last point a bit -- might it be possible to re-organize
> the core modules this way, to provide good examples? Instead of having a
> stub in the root, a file in scripts, the class in LedgerSMB, etc --
> might it be possible to have a modules directory with each module in
> it's own subdirectory? modules/AR, modules/AP, modules/HR, etc. And then
> inside those, if necessary, mirror the rest of the file structure for
> MVC -- modules/AR/scripts, modules/AR/LedgerSMB, modules/AR/UI, etc?

Oh, one more proposal:  I have already done this and made it work but
could undo it if necessary.

Moving all the scripts/*.pl files to LedgerSMB/Scripts/*.pm.  Two
justifications here:

1)  It makes inheritance across work for workflow scripts, which means
easier and more robust customization
2)  It means more intuitive reading of the lsmb-handler.pl (and
whatever we do for new code)....
3)  It occurs to me right now, it makes it easier to address your concern above.

>
> And to take it one step further, what Drupal has done brilliantly is
> provided an override mechanism -- if you want to override a core module,
> you can simply copy it to a place that gets checked first, then hack
> away, leaving the original code intact. Then an upgrade won't clobber
> your customizations, and you can much more easily do a simple diff to
> see what's changed. LSMB doesn't need to have the multiple paths that
> Drupal uses (I don't think) but maybe something as simple as a path
> that's checked first for a module - local/ comes to mind. You wanna hack
> AR? Copy modules/AR to local/AR and go to it.

First, a full scale file reorganization of this sort is probably a
long project, one we should aim for around 2.0.  I'd like to suggest a
couple points about this at present:

1) With the move of workflow scripts to LedgerSMB/Scripts, there is a
lot we can do with paths.  We'd still need some sort of hook in the
directory somewhere (probably in LedgerSMB/Scripts), but the rest
could reside in an add-ons directory (the sort of file breakout you
describe is exactly how we store our add-ons in SVN) in a configured
location, and the add-on could grab this configuration option and use
it for both PERLLIB environment variable setting, template location,
etc.

2)  The menu structure actually poses an issue here.  Somehow we have
to be able to identify nodes for add-on/role purposes, so that roles
can be re-applied if necessary.  Maybe we should add some sort of a
unique specified identifier to the menu_node table?

Best Wishes,
Chris Travers