Sorry, I did "reply-to", instead of "reply to all" ---------- Message transmis ----------
Subject: Re: [Savane-help] PHP5 + AJAX Date: Dimanche 11 Juin 2006 17:02 From: "Mathieu Roy" <[EMAIL PROTECTED]> To: "Mark Constable" <[EMAIL PROTECTED]> Hello Mark, Le 10/6/2006, "Mark Constable" <[EMAIL PROTECTED]> a écrit: >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? I have nothing against the idea of opening a branch, but I'm very doubtful of the feasibily of such approach. In my experience, forking and merging over a long period of time is simply something that does not work. The merge cost more time than just doing everything from scratch. >> 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. The current SVN version got already a different menu system. This SVN version should be release someday, there only a few things to test regarding the "wiki-like" markup stuff (see related tasks). >> 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). Actually, I can already tell you todo that restructuring all links would probably never make it in a release. Most important promoters of Savane are structure like CERN that definitely cannot afford to have changing links and this kind of things. Dont try to convince me, it is just a no-go and it is not up to me. I'm surely very happy whenever we clean up how Savane works. But the user-base cares more about keeping something that properly works it used too than having brand new stuff. >> 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. As said before, in places where Savane is actually used, you have plenty of configurations used (not speaking about a few MSIE and GNU/Linux, really plenty, and some very very old crappy things), and for the next coming years, javascript simply cannot be required to perform a task, because it is simply not reliable. >> > > 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, [...] Actually, the current approach is already documented, and works properly I think. Plenty of pages now area actually working with register global off. But not everything, and what matters is definitely that everything works - because that's what matter to the user-base. >> > 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). That would surely not make it into mainstream release. Ask me and I'll tell you PHP is total crap, most of the recurrent problems into Savane are caused because this a very very dumb langage, and all these register globals stuff exists only to fix problems that does exists in first place with a decent langage like perl (and I do not even talk about how list/hashes work in PHP, without mentioning the very unconsistent function naming policy). The only good thing into PHP are the docs. Apart from being not very smart, it is slow and it is very doubtful that PHP would be able to do what the backend do in a decent time. But the thing is not simply that PHP is a pain in the ass, the fact is Savane requires a real system, not a ftp account, to work properly for usages like providing CVS, download area, etc, because the point is to provide developer-level tools based on SSH. And if you can have SSH, you definitely can have perl. So servers without shell accounts are not really a good place to install Savane, unless you really only want the trackers (bugs, tasks). In this case, most scripts are anyway useless. You would just have to rewrite sv_aliases, I guess. >Simplicity.. can't beat bash scripts... Bash is slower than perl to do anything complicated, it has not strict mode, lists are way more limited, it is unsecure in many way, it has not direct interface to access database, etc. Bash is good for two lines stuff, but if you ever need to access database and deals with big lists, there's no match. >> > 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 ? Fixing code errors are definitely wanted. :) Regards, ------------------------------------------------------- _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
