Re: A new design question

Todd,

    I'm not criticizing RT structure, quite to the contrary, it was the best on which I developed! But I think that the model of code into the database, although to be practical when developing scrips, templates, etc into the web interface, it is more usual develop code inside an IDE or any other editor.
    A second problem consist in the maintenance of the quoted resources (scripts, etc): for each code that lives into the database you want to change, you have to wait the webserver response and, when the page arrives, there isn't any practicity to alter the code.
    Another benefit to us, developers: we could keep our customizations fully into a CVS repository!

    RT is an success system for its users but, on the other hand, there is few confort to the developer to extend it and give continuity to the project.

    The RT idealizers may think: "Oh, God! This guy is trying to change the way RT do the thinks!", but, because it's an free software and it is always in develpment and perfectioning state, threat these thread as one informal conversation about software structure and how could apply these techniches and improvements to RT, making it each time better!

Regards,

-- 
Lucas F. Rosada
lucas@xxxxxxxxxxxxx

Dextra Sistemas
+55 (19) 3256 6722
http://www.dextra.com.br

Todd Chapman wrote:

On Mon, Mar 21, 2005 at 03:28:44PM -0300, Lucas F. Rosada wrote:
  

   What is the possibility and the impact of developing a new kind of 
customization system to RT, where each queue or other bigger unit is a 
directory and, inside each directory, we have sub-directories for custom 
fields, scripts, templates, etc.
   Doing the thing in this way the database will be really a data 
repository and the code will be only into the files.

Follow an example direcotry structure:

+ Customizations
+ Queues
 - DelegatedRights.cfg
 + Scrips
  - scrip1.scp
  - scrip2.scp ...
 + Templates
  - template1.tmpl
  - template2.tmpl ...
 + Custom Fields
  - CF1.cf
  - CF2.cf
+ Global
 - DelegatedRights.cfg
 + Scrips
  - scrip1.scp
  - scrip2.scp ...
 + Templates
  - template1.tmpl
  - template2.tmpl ...
 + Custom Fields
  - CF1.cf
  - CF2.cf
 + Users
  - user1.usr
  - user2.usr
  - user3.usr
 + Groups
  - group1.grp
  - group2.grp

This is a little idea. I felt the dificult of transport the code (local 
directory) and the scrips, etc from the development server to the 
production server, where I had to dump the database without touching the 
tickets and other vital data of the customer. Maybe leaving the code in 
the files, inside the RT directory structure, would be a nice start.

Does anyone have an idea of the impact or how to refine this scructure?
    

The only problem you mention with the current system is the work
it takes to move customizations from development to production.

I think it would be better to develop code that uses the API to
make this easier than to redesign RT.

-Todd


  

_______________________________________________
Rt-devel mailing list
Rt-devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel