[Rt-devel] A new design question

[Lucas F. Rosada]

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 at dextra.com.br

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
>
>
>  
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/rt-devel/attachments/20050322/b7b0cca4/attachment.htm