Re: folder structure

Email lists > Mantis developer discussions

Thread: Re: folder structure

Search this list only Search all lists
Re: folder structure
	2007-05-07 02:09:33

Hi Aristedes, Replies inline. On 5/4/07, Aristedes Maniatis < ariish.com.au">ariish.com.au> wrote: In our work to adapt Mantis to our own needs and hopefully return our efforts back to the Mantis project, we are trying to understand the code structure. I'm a bit concerned that there appears to be little organisation within the mantisbt folder. Sure the API files are in /core, but why is view_all_inc.php in the same folder as the web pages? There appears to be no protection from a user trying to execute those pages directly, where if they were in /includes a .htaccess file could restrict direct web access. Ideally we should only have pages that can be accessed directly via the browser in the root, include files should be in core when possible.  Please submit bug reports with patches and I'll get them applied. Secondly, there is confusion about the way pages are built. For example, view.php is one way to view a bug detail page. It is turn passes on the request to a function which ultimately executes either bug_view_page.php or bug_view_advanced_page.php. So these two files are effectively 'included' in the output and not accessed directly. Except that the 'advanced' button takes the user directly to bug_view_advanced_page.php without first being filtered through view.php and the associated scripts. So, why were they there in the first place? This is historical. Originally we have bug_view_page.php and bug_view_advanced_page.php. ; There were some issues with these: 1. The names are big specially when included in text-based emails. 2. The names include the word "bug". 3. The names have the simple/advanced hard-coded in them. The view.php is a shorter one that captures the issue number that we are linking to. It then opens the simple/advanced pages based on the current user's preferences. Also the view page can have a type parameter which can direct it to a bug, project, etc. The default for the type is view. The reason why the bug_view_advanced_page.php and bug_view_page.php were not removed, is for backward compatibility. So if a user clicks a link that used to work before from a website or an email, it will still work. ; We can deprecate them in the future but I don't see it as an important issue. I understand that some coding with Smarty templates is already underway. Is it far enough forward that we should be performing our work within that code? It would certainly make what we are doing simpler. As is, there is considerable mixing of functionality with presentation, making changes somewhat difficult. The CVS branch is EXP_TEMPLATE. It is definately worth starting from where thraxisp has finished.  My only concern is that this branch is a bit out of date, however, at least the infrastructure should be still usable.  In the move to templates, a majoring of the work will be to get rid of print_xxxx() calls and replace them with some other APIs that return logical results that can then be formatted by the template.  At one point in time, I've started core/prepare_api.php for that with the aim that print_xxxx() would map to prepare_xxxx() then format the results. Finally, is there a plan to move to svn? Maintaining several branches of the project is certainly easier there and I know Sourceforge supports both cvs and svn equally? As far as I know maintenance of branches on both CVS and SVN are the same. ; The main difference is that the cost of creating a branch is independent of the project side in SVN. However, this is not a big issue.  I was thinking of moving to SVN, but I wouldn';t put that on the critical path of this work.   We are already wanting to make so many changes to the code that very quickly our version will be very hard to merge with the original should some of our changes be desired by the main project. Lets do it one feature at a time and start by the smaller ones. ; Once we are on the same page, the rework will be much less and I will make sure that whatever you guys are doing can be easily integrated into future Mantis releases. Cheers Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ mantisbt-dev mailing list mantisbt-devlists.sourceforge.net"> mantisbt-devlists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

[1]

about | contact Other archives ( Real Estate discussion Medical topics )

Mailing lists