On Wed, Mar 17, 2010 at 3:45 AM, Ed W <li...@wildgooses.com> wrote: > On 09/03/2010 21:11, Chris Travers wrote: >> Hi all; >> >> I have spent some time looking at Catalyst to see what would be >> required to make LedgerSMB run according to current development >> approaches (close to the db, etc) and the result isn't easy. >> Basically, at a minimum, the following would need to be ported: >> > > Caveat I have only looked at Catalyst and not hacked in it... > > However, to a large extent you should be able to drop "code" into > catalyst and use nothing more than the CGI handlers, plus the big blob > of code which is sql-ledger? The conversion to MVC is simply something > which is highly desirable, but we had this discussion in the past and > there is no reason you need to use any fancy ORMs or even anything other > than "thick controllers" if you really don't want anything else?
Here's some more material that has come up since: 1) Recent versions of Moose are not available on all major distros without compiling from CPAN. This makes packaging of Catalyst a bit of a problem. Consequently I don't think we can just push that problem off to the packagers. I don't want to give up on trying to get into distros, so I think Catalyst is out as far as the primary implementation. I am open to other ideas though, and I have no problem providing a separate port of many of our concepts to Catalyst so that these concepts could be re-used by other developers as well. (Dropping it into Catalyst wouldn't be too hard.) 2) Currently there are some additional modules we would have to do for things like views and auth. More on this below. > > Also I'm not familiar with catalysts view rendering, but were I doing > the views in rails (say) then not much would need to change to make it > integrate the Latex stuff, I would just render the template to a file > and stream the file. The answer I got from folks in the Catalyst community is that Template::LaTeX works out of the box. However, that's not the whole issue regarding views. The basic issue is that we want to autoescape all data going to a template for security reasons. While Template::Stash::Autoescape has been suggested as a solution, the current core team has concerns about the maturity of that module and are not sure that such would be the appropriate solution for our project to rely upon. Consequently we would have to subclass the view modules in order to do this escaping ourselves. > In rails I use some views which are stored in a > database, some from flat files and some generated from a composition of > templated templates which are composed hierarchically from other > templates... I would be highly surprised to find that there is not at > least the same level of flexibility to do the same in Catalyst? The basic issue here is just that of ensuring that every variable is escaped in every template. This is to avoid things like persistent XSS, and exploiting certain LaTeX configurations in order to execute arbitrary shell commands on the server (all kinds of bad stuff....). While it is true that a bad template can mess with your data, asking template designers to assess the security implications of escaping some data strikes me as asking for trouble. > Unless you are a rails genius it might not help much, but there is an > interesting Admin Site generator called ActiveScaffold which is worth > picking ideas from. They use an approach which builds templates from > sub templates going down quite a few levels and making it very easy to > override parts of the generic templates, customise the language, etc. > The application is very different, but some of the basic ideas would > translate very nicely and be useful The second issue has to do with authentication and sessions, and the fact that we are using these things in ways which are somewhat atypical. Most web auth stuff is assumed to work against a persistent password store which the application accesses. This is not what we do. We actually pass the credentials onto a third party (in this case PostgreSQL) to check against it's password store. A successful authentication attempt will create a database connection which is then available to the application to use. Also, for this to work, we have to remove database connections after each request. While this can be done, it just means that we have to come up with a way of gracefully doing this in a way which is fairly native to the Catalyst framework (I am aware we don't actually have to do that, but if we are going to support Catalyst, I would rather support it all the way, not just use it as a wrapper for mod_perl). Similarly, regarding sessions, these are not just flat representations of application session data. These are fairly complex objects which interface with the web application and database in a variety of ways. Disclosure of session data is security critical and so it is one of the few tables which will probably long-term be "security-definer only" for access. I don't think this would be too bad to port (would probably be the easiest of the three areas)..... Best Wishes, Chris Travers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
