Hi there,
I am gonna tell quick example that explains a little bit of why I see OACS development as a very frustrating, complex and intriguing system to understand and it demands a very good amount of time to learn it
. Nevertheless I also think OACS as the best stuff (in all aspects) I have worked with and I really hope I stay on it.
I am building up a system using OACS framework. I decided to use bugtracker package because it has so many functionalities that i need to use and it would save very much of my time to implement it by myself.
So BT just fits perfectly to what I aimed to build. I meant almost perfect except for one very little detail:
a bug has an attribute called component, which everyone who knows bt pkg is aware of it. (if i can call it as an attribute!)
Then i need to create a new attribute attached to component as sort of dependent of it. So i called subcomponent.
Furthemore, I want to use the whole code already written on BT (TCL pages and its APIs) and just add subcomponent in the respective places.
I tracked down the whole process of adding a new bug in the system. The starting point is at bug-add.tcl, ad_form -name bug,
more specifically in the API:
bug_tracker::bug::new \
-bug_id $bug_id \
-package_id $package_id \
-component_id $component_id \
-subcomponent_id $subcomponent_id \
-found_in_version $found_in_version \
-summary $summary \
-description [template::util::richtext::get_property contents $description] \
-desc_format [template::util::richtext::get_property format $description] \
-keyword_ids $keyword_ids \
-fix_for_version $fix_for_version \
-assign_to $role_resolver
which has its source code at page /tcl/bug-procs.tcl
from this API, another API is called. That is bug_tracker::bug::insert, which is in the same TCL page /tcl/bug-procs.tcl
set bug_id [bug_tracker::bug::insert \
-bug_id $bug_id \
-package_id $package_id \
-component_id $component_id \
-subcomponent_id $subcomponent_id \
-found_in_version $found_in_version \
-summary $summary \
-description $description \
-desc_format $desc_format \
-user_agent $user_agent \
-user_id $user_id \
-ip_address $ip_address \
-item_subtype $item_subtype \
-content_type $content_type \
-fix_for_version $fix_for_version ]
which also calls another API oacs_util::vars_to_ns_set at /tcl/bug-procs.tcl
oacs_util::vars_to_ns_set \
-ns_set $extra_vars \
-var_list { bug_id package_id component_id subcomponent_id found_in_version summary user_agent comment_content comment_format creation_date fix_for_version assign_to}
as you can see i added the new field "subcomponents" at all those APIs as a parameter. As well as all the others parameters that are already there.
then i created the new column on the table bt_bugs :.
alter table bt_bugs add column subcomponent_id integer
I restarted aolserver, plus i have put ns_logs to certify the new parameter was properly passed through
the APIs
After all this, the changes I have made didn't work successfully
So i remove all the stuff I amended and I just created a line of code at bug-add.tcl after the API bug_tracker::bug::new , which is:
db_dml set_subcomponent_id { UPDATE bt_bugs SET subcomponent_id = :subcomponent_id where bug_id = :bug_id }
Although this solution is not even close to be elegant, it worked pretty good as I expected.
I know the issue is much more complex and I am aware that what i have mentioned here in this brief history involves dozens of different subjects and concepts about the theme.
Furthermore it is very much probable that someone will come up with an answer of a simple line of command such as the solution i wrote.
The bottom line is that the best answer is with time and experience (headaches and frustration) on OACS i will figure out those obstacles.
Those were just my reflexive thoughts.
Thanks in advance for reading my relief
