On Sat, 2006-11-18 at 12:52 +1100, Andrew Donnellan wrote: > On 11/18/06, Michael Davies <michael@msdavies.net> wrote: > > Integration is more about what the user experiences than what > > language/tool the backend is written in/uses. Think like an end-user, > > not a programmer. > > Yes, however integration also includes the admin side of things and so on. (most of) the admin for MemberDB is web based, others still requires SQL statements (patches welcome). There's a set of rules about what everything in the DB means and UI should reflect this. There is currently no way to do this without writing code (or if there is a free way, it's hiding pretty well). > Also the end-user integration is easier when the backend is integrated. No. Please look at how MemberDB does integration with a site look. Isn't it currently acceptable with the current LA site? It's not hard coded to it. > > No matter how "simple" there will be teething problems, and if you do > > this with a membership database responsible for elections on a public > > web server, you want to minimise them (remember the privacy laws in > > this country?) > > That's why you test it somewhere other than your main server first... sure, although generating a similar data set to do full testing is tricky. I would love a bigger test suite for MemberDB - if you know of good automated web application test suites, please let me know (or even better, contribute the tests). > The last time I used MemberDB was for the elections which was ages > ago. My guess is that most people (other than ctte members) probably > use it about once a year or less. There is a fair amount of time to > test it. You're forgetting the human time. > > Member_db spat out the SQL password at one point due to a bug (sorry > > Stewart for bringing that up :-) Anything we can do to make this > > migration simpler should be adopted. > > That *is* a nasty bug; of course that shouldn't cause much of a > problem for LA if the database is configured only to allow from > localhost :) that, of course, was the case - so only people with shell access to the box could have used that password. > > Keeping it a separate application, > > Less maintainable, more difficult to integrate. > > > embedding it's output inside what > > Joomla/Drupal/Plone/Typo3 produces, > > Sometimes that can take more code than rewriting the app... but not shorter than testing it. > > or writing it from scratch - let's > > If we use a non-PHP based system this would definitely be my choice. > If a PHP based system is used it can be integrated as some sort of > module. You don't need to do that - you just need to make it *look* similar. there would be no cross-functionality needed - except authentication. and auth can go directly to the DB and run a SELECT query easily. if anything, we could write a $(favourite fashionable language of the day) authentication module. > > just get away from the NIH[0] attitude and the "XYZ language/tool > > sucks, trust me" mentality and do a proper analysis of the options so > > that we can choose the right tool, technology, and approach that makes > > sense, and not jump in feet first to solve the wrong problem. > > Well yeah, there's no point discussing this until we have any idea > what we will use and why we will use it. We still haven't got an idea > whether we should use Drupal, Joomla, Plone and Zope, a custom written > one, or whatever. i vote anything but a custom one. The world does not need yet another LAMP based CMS. > As I've been looking around Plone is looking more and more attractive > from an admin POV. It appears capable of practically anything except > perhaps the store and memberdb. suggestions on what to use for the store? no reason we have to have everything in 1 software package - modularity is good. -- Stewart Smith (stewart@linux.org.au) Committee Member, Linux Australia
Attachment:
signature.asc
Description: This is a digitally signed message part