On Sunday 11 June 2006 03:11, Sylvain Beucler wrote: > I guess creating a SVN branch would be ok. Maybe you'll need to > separate the "clean-up" changes and the user interface > improvements. Mathieu, what do you think?
Well I do need to spend quite a bit of time getting to know how Savane works so turning error_reporting to just E_ALL is a great way to get to know the code. Changes picked up from this could easily go into gna.orgs HEAD... if wanted. > I'd personaly welcome a way to click fewer times (namely when browsing > the project administration menus) :) I've got a hierarchical AJAX menu system that is quite simple. I can't wait to see it in place :-) (on my copy anyway) That's for the LHS global menu pane and then "real ajax tabs" on the main page for sub-headings. > A consideration to take into account though: even if the Savane > 'framework' is pretty simple and somewhat limited, it is fast. And arguably faster with what I have in mind. > Heavy frameworks with templates, generic input validation, state > consistency, etc. like in the *nukes are _much_ slower and unsuitable > for Gna! and Savannah - better keep the CPU for vital services such as > CVS/SVN/Mail. Maybe that's not the technology but the way it is used, > though. I'm aware of not over engineering a project as I like to keep things as simple and light as possible too, and I disklike templates systems like Smarty. However, there is one goal I'd like to get to and that is a single front controller which requires restructuring all links... a huge job in itself but the payoff is much simpler to apply multiple sites on a single server (multihosting off single code base, like... 1000s). > I mean that it's possible to have a AJAX-enabled interface as well as > a basic "vanilla-html" one, so that people without AJAX still can > access Savane. Link that to the issues about accessibility, user > preferences, any-browser campains, etc. This is where I would seriously diverge from the current Savane, after a few somewhat compatible changes, as I want a fully AJAX'd interface first and foremost, anything else is a bonus. > For a start, an interface to configure per-project commit > notifications. Ah right, of course, if something like that is not possible then Savane _needs_ hooks management :) > > > but I may help with register_globals clean-up. > > > > There are 731 instances of GLOBALS[] though :-) > > No I mean the php.ini "register_globals" parameter, which needs to be > on at the moment. That parameter automatically creates variables > according to the parameters instead of using _GET and _POST. It's more > secure to have it off. Yes, for sure. My approach, or one approach, is to assign a $_REQUEST to a global object and pass that around. When dealing with a project that still requires register_globals on it's usually no more difficult to encapsulate all config vars versus rewriting them all as $_GET/$_POST. The first approach lends itself to being able to deal with ALL incoming and conf variables in one place rather than spread throughout the whole codebase. Same thing with the front controller concept which can better take advantage of a single config object.. most of "that" stuff can all be handled in one spot in less than 100 lines of code. A good front controller design can reduce the overall size of the codebase by 25% quite easily. For a large project, that can mean an awful lot less code with potential bugs to have to fix. > (SourceForge was started in PHP3 and at the time this good practice > was not in use yet :/) Exactly. That legacy is like a brick wall. > > I'd be interested in porting all the backend scripts to PHP > > too, but I have no idea what that involves yet. > > Is there a reason why everything should be PHP with you? ;) The environment I would be running the code in is all bash/php for all setup and management. But that would be a later stage thing that no one else may want. My servers don't have shell accounts, all services are for virtual user accounts so the backend user account management, for me, has to be rewritten anyway and seeing I already have php CLI libs it would be far more work to "port" the current perl code (I think, haven't looked at it yet). Simplicity.. can't beat bash scripts... and I already HAVE to use PHP for web frontends so sticking to PHP for anything more complex than a shell script can handle helps keeps it all KISS-able. Anything but perl, python or ruby thanks :) > > PHP5 picked up one bug so far... line 33 in include/graphs.php > > was "break;" instead of "return;". > > Hmm, afaics php4 doesn't accept that either. Did you find this error > when using Savane or did you run a php5 verifier on the files? Just using Savane and clicked on stats... popped up straight away. I could have found, fixed and diff'd 50 warnings in the time it took me to write this :-) Do you think that effort would be wanted in the core Savane, or should I just go away and play in my own sandbox ? --markc _______________________________________________ Savane-help mailing list [email protected] https://mail.gna.org/listinfo/savane-help
